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: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
References: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
Message-ID: <KXxX3bA18fxCsZIvqaynBCt3ooeC3OxqzGXkvNBuN80=.f8016d8d-3a0d-446e-98c7-4a76cefd5623@github.com>

On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> 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 <T1 extends Comparable, T2 extends Comparable> int compareTo(Tuple<R<T1>, R<T2>> o) {
>         return switch (o) {
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R2<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> fst, R2<T2> 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<T1> _`. 
> 
> 
> 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: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
References: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
Message-ID: <niSEjQFFxNc7w051F_TwS9SRCiyo8QIR7L5rmJ3ek6A=.3581758e-2a7c-4915-b39d-98c1984ac73d@github.com>

On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> 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 <T1 extends Comparable, T2 extends Comparable> int compareTo(Tuple<R<T1>, R<T2>> o) {
>         return switch (o) {
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R2<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> fst, R2<T2> 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<T1> _`. 
> 
> 
> 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 <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
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: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>

-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: <QybYBA62jfc_GW8nXAXVt6fKWtHGmOW16n_UdVQlufU=.c43a87fa-2055-4be4-b314-4d84443ce6c6@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/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: <x35WSkl9gKfcAP6Q1rgFDbDlnFXrVi8OfCj95YsgYlE=.6d96495f-68c0-44bc-a95f-4d9f80c46cbf@github.com>

> 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: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
Message-ID: <xDchaB5PpaOnlndTfDoPmBzYaJmLE30_p_JsZ2UYQko=.d384c84f-dfbf-46cc-a7a0-23118772dcf8@github.com>

On Wed, 25 Oct 2023 11:02:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@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.

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

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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@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 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: <Mh3lJsDaEK5B-J9HIpb8KDKWugzk0ynAsuTCO6nhIUo=.2276b475-05fa-4068-8d05-8dcfe560cde1@github.com>

> 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: <nRBgu9dk7b8wHCbvxL0SmPLLcWX5gDEGGyjGHBvTx9M=.26c63ca7-f0d5-4f5a-9d96-2711fb57a294@github.com>

> 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: <QBs3SfCg1RhSVfoMUvRwTnJLY4ilbPdt9LxTtgkqG6o=.d69807a0-156c-4bec-b62a-de16c44821ef@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>
 <QBs3SfCg1RhSVfoMUvRwTnJLY4ilbPdt9LxTtgkqG6o=.d69807a0-156c-4bec-b62a-de16c44821ef@github.com>
Message-ID: <FBQUzONwslyRMZ-sdhHFZcFdrjpqZTrqRsSIab_z-ME=.2d880d91-fb99-4483-b640-1baed17ecd8b@github.com>

On Mon, 30 Oct 2023 23:46:40 GMT, Vicente Romero <vromero at openjdk.org> 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<T extends Inner100<@TB(100) T>> {
     }
+
+    // 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: <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
Message-ID: <pzJ0L6-ONSU48SVgKR89dtQVA39GyJjG5KnyIWuZpXI=.f4c08586-a792-496d-a0ba-af61cc6c4ba4@github.com>

On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>

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: <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
Message-ID: <RKRSzuJ_nuCewsMrJKdCVagSUwkqDvnnY99rSRqWjus=.28fe571a-2aa2-4db8-b840-449b406b516a@github.com>

On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
Message-ID: <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>

On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
Message-ID: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>

On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <jJdlYHFLeg0y5lGMlP4WzvB9LIUBnH1-URhdLUgiiww=.089e607e-75a3-4765-bcde-c6423f31da49@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 .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: <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
Message-ID: <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>

On Thu, 2 Nov 2023 11:12:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <jJdlYHFLeg0y5lGMlP4WzvB9LIUBnH1-URhdLUgiiww=.089e607e-75a3-4765-bcde-c6423f31da49@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <jJdlYHFLeg0y5lGMlP4WzvB9LIUBnH1-URhdLUgiiww=.089e607e-75a3-4765-bcde-c6423f31da49@github.com>
Message-ID: <JtUEUQuQ7tmnQI1HMYKLAT4rKFeyvW5FZn7NPJMwe8I=.cd84b778-aa95-447a-9f4f-45bf4c9271ef@github.com>

On Thu, 2 Nov 2023 11:39:19 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>
Message-ID: <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>

On Thu, 2 Nov 2023 11:18:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
Message-ID: <9g7BSn0mYpRLBVI_MNp0tpHI_DggkE_rs1KPrTBRGm0=.50c46c99-8257-4c32-8a44-f3f6a77d463b@github.com>

On Thu, 2 Nov 2023 11:55:17 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>
 <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>
Message-ID: <jq_YZlfJQR-HoXn8CbNBmWts64gTo9dWLcz8xq8KldM=.8e617fc5-23d6-47c0-a0fd-f9db7048357a@github.com>

On Thu, 2 Nov 2023 11:57:09 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
Message-ID: <nIdOYEEQeqjqsrKi3eB11-HYUTEvdDmyt-YCpU4FlU8=.85edb423-d2cf-4e01-899f-70856d974bda@github.com>

On Thu, 2 Nov 2023 11:53:09 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <nIdOYEEQeqjqsrKi3eB11-HYUTEvdDmyt-YCpU4FlU8=.85edb423-d2cf-4e01-899f-70856d974bda@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
 <nIdOYEEQeqjqsrKi3eB11-HYUTEvdDmyt-YCpU4FlU8=.85edb423-d2cf-4e01-899f-70856d974bda@github.com>
Message-ID: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com>

On Thu, 2 Nov 2023 12:11:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@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 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: <jq_YZlfJQR-HoXn8CbNBmWts64gTo9dWLcz8xq8KldM=.8e617fc5-23d6-47c0-a0fd-f9db7048357a@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>
 <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>
 <jq_YZlfJQR-HoXn8CbNBmWts64gTo9dWLcz8xq8KldM=.8e617fc5-23d6-47c0-a0fd-f9db7048357a@github.com>
Message-ID: <F4t36Sw1QHXWKJ-GFF7iTSDL7Q9DB2Hy3BiAUi9_tDo=.5b131c8e-3d3a-42d4-9bd0-7d08caa594e0@github.com>

On Thu, 2 Nov 2023 12:04:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>

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: <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
Message-ID: <yHfoNAIeSlHYlEk_FzIvoduIZHHKBUomO1lJWjLxCik=.fa7d70a5-3c29-4999-9a37-77829e8de4c9@github.com>

On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
Message-ID: <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>

On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <c-QyAwZMYfF2-WOzkaoZ9iyEiRupk363RUHk6jrhWg0=.f82efb5f-d79c-4ea7-8f28-8e1b771b53cf@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:

  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: <yHfoNAIeSlHYlEk_FzIvoduIZHHKBUomO1lJWjLxCik=.fa7d70a5-3c29-4999-9a37-77829e8de4c9@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <yHfoNAIeSlHYlEk_FzIvoduIZHHKBUomO1lJWjLxCik=.fa7d70a5-3c29-4999-9a37-77829e8de4c9@github.com>
Message-ID: <upZa58wEY8ivPwEfYPQPn7FwMGOEFrFFyirmShOD_Y8=.13bcfa7a-3ef3-4522-b7c8-d7c4d11bebae@github.com>

On Thu, 2 Nov 2023 13:53:02 GMT, Alan Bateman <alanb at openjdk.org> 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: <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
Message-ID: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com>

On Thu, 2 Nov 2023 14:38:06 GMT, Alan Bateman <alanb at openjdk.org> 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: <F4t36Sw1QHXWKJ-GFF7iTSDL7Q9DB2Hy3BiAUi9_tDo=.5b131c8e-3d3a-42d4-9bd0-7d08caa594e0@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>
 <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>
 <jq_YZlfJQR-HoXn8CbNBmWts64gTo9dWLcz8xq8KldM=.8e617fc5-23d6-47c0-a0fd-f9db7048357a@github.com>
 <F4t36Sw1QHXWKJ-GFF7iTSDL7Q9DB2Hy3BiAUi9_tDo=.5b131c8e-3d3a-42d4-9bd0-7d08caa594e0@github.com>
Message-ID: <vpdxvCR3ch06TCbv39dkRBpT-yPy6O2Ug_x2IxghkCY=.95f35a04-a355-4ee0-98dd-2166cb09dd37@github.com>

On Thu, 2 Nov 2023 12:34:49 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <J3cuRHXc8OSxib3WZtp_ppR3hMK8io1-YeyMFab1I1A=.aa90e8b2-8195-49a0-9f13-5e66380fc791@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
 <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 <jlaskey at openjdk.org> 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: <vpdxvCR3ch06TCbv39dkRBpT-yPy6O2Ug_x2IxghkCY=.95f35a04-a355-4ee0-98dd-2166cb09dd37@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com>
 <O1YvtYk0wDeMFoxIj1lM2bsxcXtW2Ym9lQuIvFmzaY8=.40dba7d1-a263-48c3-9767-f63c56e00e8e@github.com>
 <jq_YZlfJQR-HoXn8CbNBmWts64gTo9dWLcz8xq8KldM=.8e617fc5-23d6-47c0-a0fd-f9db7048357a@github.com>
 <F4t36Sw1QHXWKJ-GFF7iTSDL7Q9DB2Hy3BiAUi9_tDo=.5b131c8e-3d3a-42d4-9bd0-7d08caa594e0@github.com>
 <vpdxvCR3ch06TCbv39dkRBpT-yPy6O2Ug_x2IxghkCY=.95f35a04-a355-4ee0-98dd-2166cb09dd37@github.com>
Message-ID: <iQEZjk7zyfRfrkqPpMy1l9M9usES0sIaPf8WODD8V5o=.9d776908-5cb3-4c3b-84ef-5c6e82f0654f@github.com>

On Thu, 2 Nov 2023 15:33:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <uIRUI--CjIpJ9oBfh-1cT5uREtYb9G6oWcB2p-2aEag=.2aef493b-a7cc-460e-b4ed-d5c989cb4b44@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:

  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: <uIRUI--CjIpJ9oBfh-1cT5uREtYb9G6oWcB2p-2aEag=.2aef493b-a7cc-460e-b4ed-d5c989cb4b44@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <uIRUI--CjIpJ9oBfh-1cT5uREtYb9G6oWcB2p-2aEag=.2aef493b-a7cc-460e-b4ed-d5c989cb4b44@github.com>
Message-ID: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com>

On Thu, 2 Nov 2023 16:19:07 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <upZa58wEY8ivPwEfYPQPn7FwMGOEFrFFyirmShOD_Y8=.13bcfa7a-3ef3-4522-b7c8-d7c4d11bebae@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <yHfoNAIeSlHYlEk_FzIvoduIZHHKBUomO1lJWjLxCik=.fa7d70a5-3c29-4999-9a37-77829e8de4c9@github.com>
 <upZa58wEY8ivPwEfYPQPn7FwMGOEFrFFyirmShOD_Y8=.13bcfa7a-3ef3-4522-b7c8-d7c4d11bebae@github.com>
Message-ID: <F0ZCdhofkayrCNma17mQaFC5SthmZp0qAq_kI1lOIhM=.ea76872e-e1e7-4cb8-83b6-a3fad2d1efff@github.com>

On Thu, 2 Nov 2023 14:52:46 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
Message-ID: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com>

On Thu, 2 Nov 2023 11:55:50 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <F0ZCdhofkayrCNma17mQaFC5SthmZp0qAq_kI1lOIhM=.ea76872e-e1e7-4cb8-83b6-a3fad2d1efff@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <yHfoNAIeSlHYlEk_FzIvoduIZHHKBUomO1lJWjLxCik=.fa7d70a5-3c29-4999-9a37-77829e8de4c9@github.com>
 <upZa58wEY8ivPwEfYPQPn7FwMGOEFrFFyirmShOD_Y8=.13bcfa7a-3ef3-4522-b7c8-d7c4d11bebae@github.com>
 <F0ZCdhofkayrCNma17mQaFC5SthmZp0qAq_kI1lOIhM=.ea76872e-e1e7-4cb8-83b6-a3fad2d1efff@github.com>
Message-ID: <0Rm3u8y7eDy1QVUSco7BRq9HAT_P9ZusKALEKCiWFLg=.a3400dc4-88d1-43eb-86a8-92447ae127c0@github.com>

On Thu, 2 Nov 2023 17:30:40 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <uIRUI--CjIpJ9oBfh-1cT5uREtYb9G6oWcB2p-2aEag=.2aef493b-a7cc-460e-b4ed-d5c989cb4b44@github.com>
 <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com>
Message-ID: <aTJY0_X4AEAlSrzRgwaz3X9_Mrospw1RANFFDG_x-ms=.f5d47ae7-088e-40e7-9d7c-5587205afa8e@github.com>

On Thu, 2 Nov 2023 17:17:42 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
 <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com>
 <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com>
Message-ID: <lGgJTjpuCrRgM4z664mKQFVJjKOeEG3hRKyKJ_tm-2Y=.3a3049c6-10d0-4f64-a886-3e0ca2bc32fe@github.com>

On Thu, 2 Nov 2023 15:45:03 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
 <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com>
Message-ID: <FIkaduUczNE0cX9dLjrBN6RoMjDU7QzOkf0_UeZ4nKY=.54c19477-afaa-466a-8f2a-3fae964cc78d@github.com>

On Thu, 2 Nov 2023 17:21:02 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <lGgJTjpuCrRgM4z664mKQFVJjKOeEG3hRKyKJ_tm-2Y=.3a3049c6-10d0-4f64-a886-3e0ca2bc32fe@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
 <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com>
 <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com>
 <lGgJTjpuCrRgM4z664mKQFVJjKOeEG3hRKyKJ_tm-2Y=.3a3049c6-10d0-4f64-a886-3e0ca2bc32fe@github.com>
Message-ID: <inYGoP3P5OqmHIZObT7wJnRola9C-6EuyNNx-_i8RqQ=.e421e023-9882-4ace-a415-d622410f417f@github.com>

On Thu, 2 Nov 2023 17:45:51 GMT, Alan Bateman <alanb at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <uIRUI--CjIpJ9oBfh-1cT5uREtYb9G6oWcB2p-2aEag=.2aef493b-a7cc-460e-b4ed-d5c989cb4b44@github.com>
 <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com>
Message-ID: <AQo2MFJUZEyS0Ijc_n0HcPKz2LijnWZ_bxSaemJCYpM=.eb471024-beb1-4896-8bb6-1a8152e9a52f@github.com>

On Thu, 2 Nov 2023 17:26:19 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@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.

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

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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
 <nIdOYEEQeqjqsrKi3eB11-HYUTEvdDmyt-YCpU4FlU8=.85edb423-d2cf-4e01-899f-70856d974bda@github.com>
 <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com>
Message-ID: <LNJXFAFFDuy9huDy_37Ld6tK14Xr_p-yPBIBYTLBy2U=.ee44a79f-ff59-4e02-bba0-e2abda5b4bd6@github.com>

On Thu, 2 Nov 2023 12:24:31 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <inYGoP3P5OqmHIZObT7wJnRola9C-6EuyNNx-_i8RqQ=.e421e023-9882-4ace-a415-d622410f417f@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <AaCmIwZC-x1Pi51imXEHpaIi9UTqXt7nYkvY3XJ5yTk=.a7495c61-839b-43d3-8418-fe6580ac107e@github.com>
 <u0bNSap7kqLdaSoctZV85hfF5_s6TPDa02Rr4nRZFqw=.b5f664a7-61e4-4a95-92ee-8f18bd776462@github.com>
 <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com>
 <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com>
 <lGgJTjpuCrRgM4z664mKQFVJjKOeEG3hRKyKJ_tm-2Y=.3a3049c6-10d0-4f64-a886-3e0ca2bc32fe@github.com>
 <inYGoP3P5OqmHIZObT7wJnRola9C-6EuyNNx-_i8RqQ=.e421e023-9882-4ace-a415-d622410f417f@github.com>
Message-ID: <EXCo49YKmvx4u9wHP6x0HcMzbrNbaD0bcZf4FgPRPpE=.1c8b5ec5-70af-4cc8-b423-ff5cdf5b3007@github.com>

On Thu, 2 Nov 2023 17:53:12 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <babx45QDhZOMPHRTgeRMOKhKV0L--qG3Q8P8Dne44Nk=.d5c9260d-9ad9-4b2a-a1b9-ad63161e9eb7@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <babx45QDhZOMPHRTgeRMOKhKV0L--qG3Q8P8Dne44Nk=.d5c9260d-9ad9-4b2a-a1b9-ad63161e9eb7@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
 <babx45QDhZOMPHRTgeRMOKhKV0L--qG3Q8P8Dne44Nk=.d5c9260d-9ad9-4b2a-a1b9-ad63161e9eb7@github.com>
Message-ID: <xhZAYorZuFKj3m5-p9R5YAThrSW2QvYMAwZd55JGjiQ=.b32972b8-ccd5-425e-b555-073ff840ba88@github.com>

On Thu, 2 Nov 2023 19:36:19 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <S6pw4v0Zp44Y6iP5SI-H54f0aHGAxg-8gvJvyFfaIbM=.9c3f5914-42e5-403f-98c9-ae72775d8d9c@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com>
Message-ID: <NRDv6roKFQGYrpxekvm3mCWLRq3fwvlIV89JBO83tEI=.3cb2de58-0776-4183-9fcd-df20ee1fa9b3@github.com>

On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <xhZAYorZuFKj3m5-p9R5YAThrSW2QvYMAwZd55JGjiQ=.b32972b8-ccd5-425e-b555-073ff840ba88@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
 <babx45QDhZOMPHRTgeRMOKhKV0L--qG3Q8P8Dne44Nk=.d5c9260d-9ad9-4b2a-a1b9-ad63161e9eb7@github.com>
 <xhZAYorZuFKj3m5-p9R5YAThrSW2QvYMAwZd55JGjiQ=.b32972b8-ccd5-425e-b555-073ff840ba88@github.com>
Message-ID: <LhZ0qdGGLnkzprBnAgRFE99grWKcxoxXT4hKmBlu4KY=.a9d120ab-490f-4a29-87fd-2339e419ac4f@github.com>

On Fri, 3 Nov 2023 00:18:33 GMT, Chen Liang <liach at openjdk.org> 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: <PnKYcyKKC335POwvPajyb4J9E_0tz-7Dy9nmjWgn7yw=.096e9de8-cfbc-41b8-8cca-7e0c580453a7@github.com>

> 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: <FBQUzONwslyRMZ-sdhHFZcFdrjpqZTrqRsSIab_z-ME=.2d880d91-fb99-4483-b640-1baed17ecd8b@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>
 <QBs3SfCg1RhSVfoMUvRwTnJLY4ilbPdt9LxTtgkqG6o=.d69807a0-156c-4bec-b62a-de16c44821ef@github.com>
 <FBQUzONwslyRMZ-sdhHFZcFdrjpqZTrqRsSIab_z-ME=.2d880d91-fb99-4483-b640-1baed17ecd8b@github.com>
Message-ID: <YQCP6mKgMQluaQBTr8eSxilv_NFkwDIh1XRJi8AnRfE=.6fe94fec-06b4-4cea-903f-0674744f94ca@github.com>

On Wed, 1 Nov 2023 19:23:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com>
Message-ID: <Qf2QWLih3k5wCWYqNj4OmYfOzJimu_LarfJfoEdImp8=.3e7408ac-1083-428e-9540-12b1643531d4@github.com>

On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
References: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
Message-ID: <awfZ_jlHUMamn0awWL61ZBYrp6z-MGsgU5146YLg5f0=.ed13b308-e789-4eef-873d-5a1218550f24@github.com>

> 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: <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@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 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: <NRDv6roKFQGYrpxekvm3mCWLRq3fwvlIV89JBO83tEI=.3cb2de58-0776-4183-9fcd-df20ee1fa9b3@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com>
 <NRDv6roKFQGYrpxekvm3mCWLRq3fwvlIV89JBO83tEI=.3cb2de58-0776-4183-9fcd-df20ee1fa9b3@github.com>
Message-ID: <m8ZAQzXA075JZkVTjg8IpYQbhCB-8mdw1d0cdRBR1J8=.a50d4099-193b-4340-aa58-a08db4fcabe9@github.com>

On Fri, 3 Nov 2023 01:06:56 GMT, Mandy Chung <mchung at openjdk.org> 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: <Qf2QWLih3k5wCWYqNj4OmYfOzJimu_LarfJfoEdImp8=.3e7408ac-1083-428e-9540-12b1643531d4@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com>
 <Qf2QWLih3k5wCWYqNj4OmYfOzJimu_LarfJfoEdImp8=.3e7408ac-1083-428e-9540-12b1643531d4@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 <vromero at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <LNJXFAFFDuy9huDy_37Ld6tK14Xr_p-yPBIBYTLBy2U=.ee44a79f-ff59-4e02-bba0-e2abda5b4bd6@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
 <nIdOYEEQeqjqsrKi3eB11-HYUTEvdDmyt-YCpU4FlU8=.85edb423-d2cf-4e01-899f-70856d974bda@github.com>
 <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com>
 <LNJXFAFFDuy9huDy_37Ld6tK14Xr_p-yPBIBYTLBy2U=.ee44a79f-ff59-4e02-bba0-e2abda5b4bd6@github.com>
Message-ID: <ATI-O8TNVdU0ZBqTxPVF9rUggD0cVsdLYaIkMP119eU=.5206209a-4780-4250-9feb-e76d0234fa52@github.com>

On Thu, 2 Nov 2023 18:10:27 GMT, R?mi Forax <forax at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@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 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: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
Message-ID: <SqGZ_DMA9TOhd3K6m5kgTc-nDYGD7oS8X7KsS9uQ4wk=.4ffce517-cc68-4076-99b1-ce4a5b7f76a8@github.com>

On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>
Message-ID: <MYDQfxFlX5XdsSWlIlcTdA7UZh3Cs95OLPqKV6ilwWE=.29eee829-fbe5-44a7-a91e-005933f0c28f@github.com>

On Tue, 17 Oct 2023 16:03:25 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <SqGZ_DMA9TOhd3K6m5kgTc-nDYGD7oS8X7KsS9uQ4wk=.4ffce517-cc68-4076-99b1-ce4a5b7f76a8@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
 <SqGZ_DMA9TOhd3K6m5kgTc-nDYGD7oS8X7KsS9uQ4wk=.4ffce517-cc68-4076-99b1-ce4a5b7f76a8@github.com>
Message-ID: <Ngcj_eJgrE_sJHx5yDj3myJ7HYeAeDb19SQz4t0CTzs=.26f41655-fe09-452d-b692-14091446241d@github.com>

On Fri, 3 Nov 2023 14:26:29 GMT, Vicente Romero <vromero at openjdk.org> 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: <YQCP6mKgMQluaQBTr8eSxilv_NFkwDIh1XRJi8AnRfE=.6fe94fec-06b4-4cea-903f-0674744f94ca@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>
 <QBs3SfCg1RhSVfoMUvRwTnJLY4ilbPdt9LxTtgkqG6o=.d69807a0-156c-4bec-b62a-de16c44821ef@github.com>
 <FBQUzONwslyRMZ-sdhHFZcFdrjpqZTrqRsSIab_z-ME=.2d880d91-fb99-4483-b640-1baed17ecd8b@github.com>
 <YQCP6mKgMQluaQBTr8eSxilv_NFkwDIh1XRJi8AnRfE=.6fe94fec-06b4-4cea-903f-0674744f94ca@github.com>
Message-ID: <WfKPQYc5hLETnV9ghTZ4_kr36CPvPS-9Y1CQwloKrDA=.f4c86aba-78fc-4cdb-8e5c-5f16013120eb@github.com>

On Fri, 3 Nov 2023 01:27:18 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <Ngcj_eJgrE_sJHx5yDj3myJ7HYeAeDb19SQz4t0CTzs=.26f41655-fe09-452d-b692-14091446241d@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
 <SqGZ_DMA9TOhd3K6m5kgTc-nDYGD7oS8X7KsS9uQ4wk=.4ffce517-cc68-4076-99b1-ce4a5b7f76a8@github.com>
 <Ngcj_eJgrE_sJHx5yDj3myJ7HYeAeDb19SQz4t0CTzs=.26f41655-fe09-452d-b692-14091446241d@github.com>
Message-ID: <IBZbux_QBFaOEm_S23sgG1w1Rbk40t8y0WTIT0ZCmog=.22024edd-f554-46a8-b925-4256f61a8fe4@github.com>

On Fri, 3 Nov 2023 15:00:41 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@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 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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>

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: <v4eBV6J_fsvTSM34nhCnxpbkCdaEwyCiRRGwJ9cTEUw=.d5db6275-4aee-4865-82aa-bf1438095d0f@github.com>

On Fri, 27 Oct 2023 21:01:54 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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 <cushon at openjdk.org>
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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
Message-ID: <Ak-4-YuJ0h7jbsGSwn23APPyiCCTDRm3mlbaeu4IgD8=.94e09680-cab5-4d36-ba4a-ce26f64ccc45@github.com>

On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <Wdgnq86avkY1gG7wftu9L3Re6NMlgj1Fj5rm_CyBDs0=.9750e179-c776-44b5-9198-02aa337ebbf9@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 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: <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
Message-ID: <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>

On Fri, 3 Nov 2023 15:29:25 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
 <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>
Message-ID: <jiazs5RU4mhB6cH1X4OgpBJKDPZt9zNusqTDGccVGg0=.b5a9481b-1e57-4a02-9f6c-f5c0b70e1a0f@github.com>

On Mon, 16 Oct 2023 14:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
Message-ID: <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>

> 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: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>
References: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>
Message-ID: <Kouk85Cru2ApuOQmAfuXMNtA2zeLmMfgc3VkW-8zy_0=.ff233cb9-52e6-49e5-b872-d7083be7e250@github.com>

> -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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@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.

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

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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <KQjXXgMogpMpHh6c8IZ_--ZnyvSuZR8jsEtw7Z34gPc=.bb526555-06c6-4d5d-9d83-caf9a5fef223@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <K2LqDfjPo8FpPiCc_yh6IRA4rveuJZuWNLtqbmmi80M=.b1c239a8-ed3b-4d06-a08d-77b7e6706db7@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
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 <duke at openjdk.org> 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
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: <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
 <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>
Message-ID: <6mtIcg0H0wbOwcAzlmWG9thAjUpDCzQe55aLQDGA33Q=.deaada83-150c-4e1d-85c3-c07c61ff62a5@github.com>

On Sat, 4 Nov 2023 13:26:04 GMT, Alan Bateman <alanb at openjdk.org> 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: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
Message-ID: <6gX1AIFAraJXNagvz0R81ffShpGYy8NAuEx3LVel_cE=.534fbf76-a97b-4610-a672-09f5f0b14569@github.com>

On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
Message-ID: <r0wbja4EQLaK-gF2LRC2nQ3PveozCheDpoqlO6EKC_I=.4c6bdd18-f04d-4e71-ae22-903569f8dab6@github.com>

On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
Message-ID: <uYDUmqn0wounuXvyTqzy4yJmpzjtgOxCI4wFbh1mE5A=.bccddf09-2dd1-477f-a5be-499b4c244b73@github.com>

On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <Ll5CMVmBxvEmo6wINiuxfdONwKsW5u23zeNNDg4ikuM=.7036fc23-3eb9-47d3-8dc8-30c5c879a218@github.com>
Message-ID: <EjrdZaIg2YR81gJ8DrxTfvjJl9XpG6arMmoQImTtiKU=.9819df24-4704-48d8-8617-4f9c5294a0fa@github.com>

On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <K2LqDfjPo8FpPiCc_yh6IRA4rveuJZuWNLtqbmmi80M=.b1c239a8-ed3b-4d06-a08d-77b7e6706db7@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <K2LqDfjPo8FpPiCc_yh6IRA4rveuJZuWNLtqbmmi80M=.b1c239a8-ed3b-4d06-a08d-77b7e6706db7@github.com>
Message-ID: <AuDiHllc9Lj71-jyNZ31rytVzbKfeObT9A1U55xKBOI=.3deadb67-e295-4b6e-a569-d7148bfbe879@github.com>

On Mon, 6 Nov 2023 11:28:23 GMT, Ryan Wallace <duke at openjdk.org> 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: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <b2Wk3ScGo9gRNiVpT63MYtLDFlGWBbfEdKyoXIQD_Sc=.ac8331a7-baa4-4d1c-bbed-c4aafbc6ecea@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: 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: <coxdnsBkac7bXPWBEWQNOvrLG8gb5n8ceQp4KTTA9G4=.0fb543e6-fd12-46f4-8083-eb4f4cea5002@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
 <lt2hx3lOAsl5FkVoaPOoBt2Q0xv4wiAhHtU5e5oLcwk=.ed13369f-2b3f-4d51-b688-1ba2558b114f@github.com>
 <rEAPUo9x7uP2iRrXRPo3MKDsYeuDlFEKEDPp4sgKB3g=.fe5f6a5e-7870-490a-9f36-59c85a93ef39@github.com>
 <coxdnsBkac7bXPWBEWQNOvrLG8gb5n8ceQp4KTTA9G4=.0fb543e6-fd12-46f4-8083-eb4f4cea5002@github.com>
Message-ID: <SzOkUMnyKjETToGRTM2YUx5pcuNoIzXA8c_rp8shoaY=.62be14f9-2063-49e0-9e0d-7adb395dc7fd@github.com>

On Fri, 27 Oct 2023 14:26:56 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>

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 <current>` 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: <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
 <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>
Message-ID: <Bj6m-3t1jsusBHtPIYaBSBTOtIfspKNqAUIqXuXVIqE=.a0636aff-ed46-41fc-a494-1cc1cf0038fe@github.com>

On Mon, 6 Nov 2023 07:34:38 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <Bj6m-3t1jsusBHtPIYaBSBTOtIfspKNqAUIqXuXVIqE=.a0636aff-ed46-41fc-a494-1cc1cf0038fe@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
 <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>
 <Bj6m-3t1jsusBHtPIYaBSBTOtIfspKNqAUIqXuXVIqE=.a0636aff-ed46-41fc-a494-1cc1cf0038fe@github.com>
Message-ID: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com>

On Mon, 6 Nov 2023 18:12:10 GMT, Vicente Romero <vromero at openjdk.org> 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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
 <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>
 <Bj6m-3t1jsusBHtPIYaBSBTOtIfspKNqAUIqXuXVIqE=.a0636aff-ed46-41fc-a494-1cc1cf0038fe@github.com>
 <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com>
Message-ID: <Qk_TMBgsVj41k7eBMqs3_HxAP4SEc0qtxWxGCbyZJsI=.cda88e16-9852-4873-9276-a770ab39002b@github.com>

On Mon, 6 Nov 2023 18:51:59 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@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

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

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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <W0BndDd6thuTDon8wbJWh2YTwAft4cxWJcghBexy_-4=.51546c58-a260-4d7f-9106-56a85b6ec8d0@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:

  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: <W0BndDd6thuTDon8wbJWh2YTwAft4cxWJcghBexy_-4=.51546c58-a260-4d7f-9106-56a85b6ec8d0@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <W0BndDd6thuTDon8wbJWh2YTwAft4cxWJcghBexy_-4=.51546c58-a260-4d7f-9106-56a85b6ec8d0@github.com>
Message-ID: <iy9ZE58vLUCHRPlIueJBQr904UxdTqkInja48B8aLpk=.e4a7f6ef-85df-49ef-b505-9bbb36064ed4@github.com>

On Mon, 6 Nov 2023 19:53:03 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
Message-ID: <DxQagZr7jTY1geYX_9eNo4NDu2ms8QCySXQR7EXzhbQ=.5f772321-97bb-4101-9b97-1e0c4091f93c@github.com>

> 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: <Qk_TMBgsVj41k7eBMqs3_HxAP4SEc0qtxWxGCbyZJsI=.cda88e16-9852-4873-9276-a770ab39002b@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
 <RW9Y8G13WQwwSoqgZwWXL7vh89uLCGc2M-OqfVTwDK4=.82638d7f-4a18-469f-81aa-d5ec18295881@github.com>
 <Bj6m-3t1jsusBHtPIYaBSBTOtIfspKNqAUIqXuXVIqE=.a0636aff-ed46-41fc-a494-1cc1cf0038fe@github.com>
 <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com>
 <Qk_TMBgsVj41k7eBMqs3_HxAP4SEc0qtxWxGCbyZJsI=.cda88e16-9852-4873-9276-a770ab39002b@github.com>
Message-ID: <wlr0O2GMOowvorSSsLipj9uT53cbA5d9gGO3KtrDwaM=.a13e7363-b641-4b68-97d5-3d317de219f3@github.com>

On Mon, 6 Nov 2023 19:01:38 GMT, Vicente Romero <vromero at openjdk.org> 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: <DxQagZr7jTY1geYX_9eNo4NDu2ms8QCySXQR7EXzhbQ=.5f772321-97bb-4101-9b97-1e0c4091f93c@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
 <DxQagZr7jTY1geYX_9eNo4NDu2ms8QCySXQR7EXzhbQ=.5f772321-97bb-4101-9b97-1e0c4091f93c@github.com>
Message-ID: <0mHtAUXulQC-Wtq7GZEEBRPjhhEAFZRMAlSt6ottxwQ=.2ec4dfa2-4084-4962-9ec8-cef7cdb055f7@github.com>

On Mon, 6 Nov 2023 20:47:06 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <kkWR6yXfWwFD4NMpRvOt4u8D55PUctHCXxX74RoujAc=.b49b80e1-b100-4c10-b72e-47402be5130a@github.com>

> 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 <span>#</span>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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
 <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com>
Message-ID: <UqZEsXraRT5Cz4O_LWtJFeT0jttEBykGqanFUhp_FRs=.d046e811-4420-4f6a-86b0-c4ba34deb5bc@github.com>

On Mon, 6 Nov 2023 23:14:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <qAOuRsK4jqoJzc-p4qDNnbTP8WpDUW2RiqJUbw7XkV4=.6823faab-05e6-4d90-8899-128a5bf6ce80@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <FHQo47OSiJHRkO99GloqYaXTLucvDFtXUjfYbsaPB7A=.8af800b3-42c1-4820-81c1-fa6e1dd3f3a4@github.com>

On Thu, 26 Oct 2023 23:29:00 GMT, Jonathan Gibbons <jjg at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <-QZ9xPRrv02N3BZBi2U2jblEHAhWkvmYCzMT8HSLhDI=.b4451c95-2895-456f-b4b9-f28ff40319e7@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <IgtcOIPlwWGmIk4jb6zW8IkvAI9E0WsiOyaHjAcdrLE=.2b5b285f-a36f-4d71-9d19-91a3abc52f39@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> 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: <IgtcOIPlwWGmIk4jb6zW8IkvAI9E0WsiOyaHjAcdrLE=.2b5b285f-a36f-4d71-9d19-91a3abc52f39@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <IgtcOIPlwWGmIk4jb6zW8IkvAI9E0WsiOyaHjAcdrLE=.2b5b285f-a36f-4d71-9d19-91a3abc52f39@github.com>
Message-ID: <Xx3QgDO6Zoo6QzxCJR7DBmzOT8L3FCAkyQfjIep1wZU=.d1594edb-e30f-4e30-a923-cdcc848dcc62@github.com>

On Tue, 7 Nov 2023 11:04:14 GMT, Ryan Wallace <duke at openjdk.org> 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: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
References: <UKvUIob8ZIciXo2NEXgMSjC9qyvO-qNZdNuGShuqkdc=.b6ea0ace-f9cb-44ed-84cb-2b41d9323d18@github.com>
Message-ID: <5N26pFp5SYukkm-OA-oru3EWCajncfuoXwFg1LihgNs=.81ab9394-1ee3-4562-af7c-5638e6fed34a@github.com>

On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <jeYwfECLKX57_IHMV2uRhiGGePq30EeJkRrH3DKWLLc=.f2d59548-924c-4378-abc8-55d6647bad78@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 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <puwo67XW6iYk6mJqj5DvSjCPxiAH3T4jlPGFiTcJILw=.b376f838-628e-4927-90e2-7f62e6cfcc75@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <jeYwfECLKX57_IHMV2uRhiGGePq30EeJkRrH3DKWLLc=.f2d59548-924c-4378-abc8-55d6647bad78@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <jeYwfECLKX57_IHMV2uRhiGGePq30EeJkRrH3DKWLLc=.f2d59548-924c-4378-abc8-55d6647bad78@github.com>
Message-ID: <qpdw87mzLTEyI5f1y7wDqD1H5utWwd35WCmp0_ITBQY=.5fb2e20e-9aaa-4d45-be38-475d3dbfb730@github.com>

On Tue, 7 Nov 2023 12:29:12 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <qpdw87mzLTEyI5f1y7wDqD1H5utWwd35WCmp0_ITBQY=.5fb2e20e-9aaa-4d45-be38-475d3dbfb730@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <jeYwfECLKX57_IHMV2uRhiGGePq30EeJkRrH3DKWLLc=.f2d59548-924c-4378-abc8-55d6647bad78@github.com>
 <qpdw87mzLTEyI5f1y7wDqD1H5utWwd35WCmp0_ITBQY=.5fb2e20e-9aaa-4d45-be38-475d3dbfb730@github.com>
Message-ID: <jjfd-YkvlVQQ9WclSBF_kqv8YD4wVIVXq_jizpa-Rh4=.b641398c-78f5-4845-97e5-3a4d88eceb67@github.com>

On Tue, 7 Nov 2023 15:45:02 GMT, Alan Bateman <alanb at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <hIXgO_s3M3Ur7k30l_bqsNV8vPgcfIvUtl-THHQbNps=.41dda2cf-370e-4698-b572-cd78a66bda21@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:

  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: <jjfd-YkvlVQQ9WclSBF_kqv8YD4wVIVXq_jizpa-Rh4=.b641398c-78f5-4845-97e5-3a4d88eceb67@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <jeYwfECLKX57_IHMV2uRhiGGePq30EeJkRrH3DKWLLc=.f2d59548-924c-4378-abc8-55d6647bad78@github.com>
 <qpdw87mzLTEyI5f1y7wDqD1H5utWwd35WCmp0_ITBQY=.5fb2e20e-9aaa-4d45-be38-475d3dbfb730@github.com>
 <jjfd-YkvlVQQ9WclSBF_kqv8YD4wVIVXq_jizpa-Rh4=.b641398c-78f5-4845-97e5-3a4d88eceb67@github.com>
Message-ID: <DobsvzBO6Sgf1gXSrlqxnXuz3wNCfWyB4quKYyGBfoM=.6efea69d-7722-4822-994d-a4cfc7406f69@github.com>

On Tue, 7 Nov 2023 15:51:22 GMT, Alan Bateman <alanb at openjdk.org> 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: <hIXgO_s3M3Ur7k30l_bqsNV8vPgcfIvUtl-THHQbNps=.41dda2cf-370e-4698-b572-cd78a66bda21@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <hIXgO_s3M3Ur7k30l_bqsNV8vPgcfIvUtl-THHQbNps=.41dda2cf-370e-4698-b572-cd78a66bda21@github.com>
Message-ID: <kWc8N00mpdH26W9haN5MnSDnrShu-q6Ok9UMrieySK0=.83beafdd-02a0-4c95-8713-813e0fa69bc9@github.com>

On Tue, 7 Nov 2023 16:19:33 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <rBkIjAKFd9KVPfrq48uJJfMU8N6_DpPUdSKBvvMRKbg=.97bc7323-1d2f-4c10-9b9d-d67f27363f6b@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/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: <puwo67XW6iYk6mJqj5DvSjCPxiAH3T4jlPGFiTcJILw=.b376f838-628e-4927-90e2-7f62e6cfcc75@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <puwo67XW6iYk6mJqj5DvSjCPxiAH3T4jlPGFiTcJILw=.b376f838-628e-4927-90e2-7f62e6cfcc75@github.com>
Message-ID: <VLsqhYcZG5_VpD9rELotOmc2R4O7FU07jD6QkHniRcE=.c4a2b4bc-ae55-4d7b-8e1e-ee2a4450ef65@github.com>

On Tue, 7 Nov 2023 15:36:46 GMT, Mark Reinhold <mr at openjdk.org> 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: <JtUEUQuQ7tmnQI1HMYKLAT4rKFeyvW5FZn7NPJMwe8I=.cd84b778-aa95-447a-9f4f-45bf4c9271ef@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <jJdlYHFLeg0y5lGMlP4WzvB9LIUBnH1-URhdLUgiiww=.089e607e-75a3-4765-bcde-c6423f31da49@github.com>
 <JtUEUQuQ7tmnQI1HMYKLAT4rKFeyvW5FZn7NPJMwe8I=.cd84b778-aa95-447a-9f4f-45bf4c9271ef@github.com>
Message-ID: <Gz1LVhzAxvZ-rrKiK-Yg2qbCifmT_afj-F_sEUGMkgI=.6a298fc1-5e1a-449c-b691-8cf141d1e005@github.com>

On Thu, 2 Nov 2023 11:58:23 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Mh3lJsDaEK5B-J9HIpb8KDKWugzk0ynAsuTCO6nhIUo=.2276b475-05fa-4068-8d05-8dcfe560cde1@github.com>
References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com>
 <Mh3lJsDaEK5B-J9HIpb8KDKWugzk0ynAsuTCO6nhIUo=.2276b475-05fa-4068-8d05-8dcfe560cde1@github.com>
Message-ID: <qQv8wc9xp5rq6bxcjG33dc5V5yg8420AeloFrj2JntM=.fedc820f-dfe9-4ecf-a4f0-0a4fe7bb8375@github.com>

On Wed, 1 Nov 2023 19:19:15 GMT, Vicente Romero <vromero at openjdk.org> 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: <H-upisU7KXrYQDVBihhDKRhYq7wheR_wGnNurx5sTDc=.78066a2f-62ee-463e-8046-f2731bdf8eb0@github.com>

> 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: <tMZ2mwEY8vEapSLHTi2KbOBJgz6gNGUFsqIHpAcHhNU=.c3b7aab6-0993-4222-8c18-e6b8041f5695@github.com>

> 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: <IsQQGZw0jDhkn9d_NAuQRGNgWb6Simbr4CJGEfX_G6g=.b8e6e61e-1146-4f3f-b156-0aa0ecc37e2b@github.com>

> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <FIhRKY93rJFRZuTC6odUzkbmD0EqBiWkBozmwzKT-Qk=.5c1d6a7f-02ca-4f56-ac84-d28336a765ce@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <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 <duke at openjdk.org> 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: <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@github.com>
Message-ID: <GBU3tbHKK8DeGlHpbr_OcAy4lvTud5Eol_aoEyLo1Yw=.7bd6568a-14a8-45f4-b363-22a8da6e1455@github.com>

On Fri, 3 Nov 2023 08:39:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> 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: <GBU3tbHKK8DeGlHpbr_OcAy4lvTud5Eol_aoEyLo1Yw=.7bd6568a-14a8-45f4-b363-22a8da6e1455@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@github.com>
 <GBU3tbHKK8DeGlHpbr_OcAy4lvTud5Eol_aoEyLo1Yw=.7bd6568a-14a8-45f4-b363-22a8da6e1455@github.com>
Message-ID: <ukeM3qk5B1A1RHt-Joy4EkpzTAQUNboxIIvYhUmfkSg=.18992498-24fc-4c93-8917-58894c070808@github.com>

On Wed, 8 Nov 2023 13:31:32 GMT, Konrad Windszus <duke at openjdk.org> 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: <dC3WFWiqhseh2QDfQA3VcC2hPKYxG0xPpbf55oCeWHQ=.a0e13aa4-5fb5-495b-b24b-f40f322f19fd@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 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: <dC3WFWiqhseh2QDfQA3VcC2hPKYxG0xPpbf55oCeWHQ=.a0e13aa4-5fb5-495b-b24b-f40f322f19fd@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <dC3WFWiqhseh2QDfQA3VcC2hPKYxG0xPpbf55oCeWHQ=.a0e13aa4-5fb5-495b-b24b-f40f322f19fd@github.com>
Message-ID: <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com>

On Wed, 8 Nov 2023 14:32:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

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

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <SBDtGGFJpguf9dShCM2uhSEG8bGjp9zHiiQGQriZtl0=.49b6bbd7-65f7-4e04-800e-0b6938e8216c@github.com>

> 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: <ukeM3qk5B1A1RHt-Joy4EkpzTAQUNboxIIvYhUmfkSg=.18992498-24fc-4c93-8917-58894c070808@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@github.com>
 <GBU3tbHKK8DeGlHpbr_OcAy4lvTud5Eol_aoEyLo1Yw=.7bd6568a-14a8-45f4-b363-22a8da6e1455@github.com>
 <ukeM3qk5B1A1RHt-Joy4EkpzTAQUNboxIIvYhUmfkSg=.18992498-24fc-4c93-8917-58894c070808@github.com>
Message-ID: <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com>

On Wed, 8 Nov 2023 14:07:04 GMT, Chen Liang <liach at openjdk.org> 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <xgSf5C-MGlc-xEvDhrF8T7Qri12T_AAHcq3toRmpABU=.e677f7a5-4e34-45fd-b41e-7d63b8703ab3@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 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: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com>
Message-ID: <gV7PXC-EYLtc7gre05PTR4EcQWUatJ34DPDz6vPahn0=.1654002d-fd26-47df-9ddd-3313c2ad977e@github.com>

On Wed, 8 Nov 2023 09:42:25 GMT, Ryan Wallace <duke at openjdk.org> 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: <gV7PXC-EYLtc7gre05PTR4EcQWUatJ34DPDz6vPahn0=.1654002d-fd26-47df-9ddd-3313c2ad977e@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com>
 <gV7PXC-EYLtc7gre05PTR4EcQWUatJ34DPDz6vPahn0=.1654002d-fd26-47df-9ddd-3313c2ad977e@github.com>
Message-ID: <gD71QkvjgQ-v2oIDaOMmOG2Kor6dC_xizQ1JlWIkopQ=.fe3313bf-afbb-4a04-ba6c-545c2c68b387@github.com>

On Wed, 8 Nov 2023 16:03:22 GMT, Ryan Wallace <duke at openjdk.org> 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>
 <dC3WFWiqhseh2QDfQA3VcC2hPKYxG0xPpbf55oCeWHQ=.a0e13aa4-5fb5-495b-b24b-f40f322f19fd@github.com>
 <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com>
Message-ID: <dZ4LiSaIlPGpQchxvxfNLRQpxQ3w5xolIEktmwKfx6A=.e91f4c7d-f98c-44cb-94c5-f0b900c69a6b@github.com>

On Wed, 8 Nov 2023 15:22:54 GMT, Chen Liang <liach at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <8BGQzeJjj1KC5HShlTHPG08gAoaveXZDTyGRkyRooLI=.18ca0499-1d01-44d0-9b53-73f6ad723148@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <qbrQ71cNMeR9rrI51hm0Gojtp-TnSWMxPPeWrmKauqk=.841de7c6-6c83-48d6-b8fc-de7c8e72e9f7@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <qbrQ71cNMeR9rrI51hm0Gojtp-TnSWMxPPeWrmKauqk=.841de7c6-6c83-48d6-b8fc-de7c8e72e9f7@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <qbrQ71cNMeR9rrI51hm0Gojtp-TnSWMxPPeWrmKauqk=.841de7c6-6c83-48d6-b8fc-de7c8e72e9f7@github.com>
Message-ID: <z9ERu6yiAXcbiWgYiNeH9eLivWJbCEEOkosgMpdey7A=.4fb37f38-6a0e-4bf3-8a24-6ac21c2c37a5@github.com>

On Wed, 8 Nov 2023 16:22:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 <current>` 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <gYw6Ee-cZ8P00zAjoXOQnVSMNi1NKnvt5v0x-UQiOmE=.ac4b29f1-c795-4519-8b86-a0d1f3958d24@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <wL8lJNdDQp4ykQYJh78X3WwNeFteIYqq8WxYY2d5ULg=.01cc38c8-6c78-437d-84ce-32494c8f6d34@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>

On Thu, 26 Oct 2023 23:29:00 GMT, Jonathan Gibbons <jjg at openjdk.org> 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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <Pu1wVa9giLgoNxHnKOJUAhuDkjOrTF5shnWArJGWqpg=.fbfa09f9-0640-4734-9c63-db334d9084db@github.com>

On Wed, 8 Nov 2023 17:25:36 GMT, Pavel Rappo <prappo at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <9n64R-yPL-FjiPBc6UABsD0zW5YEWkF6ZhmvdnB_mv4=.a0434daf-91d2-41e5-b6cf-f401ccead7fe@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <wL8lJNdDQp4ykQYJh78X3WwNeFteIYqq8WxYY2d5ULg=.01cc38c8-6c78-437d-84ce-32494c8f6d34@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <wL8lJNdDQp4ykQYJh78X3WwNeFteIYqq8WxYY2d5ULg=.01cc38c8-6c78-437d-84ce-32494c8f6d34@github.com>
Message-ID: <6RYD-SZ7pvhaJGBgKQIEjhX2sguj7obDPVSqe_fnovQ=.e7ae67cc-1dd5-467d-8eb7-f3927152abfe@github.com>

On Wed, 8 Nov 2023 16:31:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 <current>` 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@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:

  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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <VNloSPsWU_lPKKqBJlhCeIwQbOX1tROMhxcsQgbip_A=.a1bdad18-4621-4a9a-afaa-499d93f94b83@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>

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<String> cannot be converted to List<Number>` rather than `incompatible types: List<String> 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>
 <UEOdYylc5vogXRIwedvXyrC7I7e5cPN9FVCH4psOUAI=.2a17405b-d77f-4ae9-9d18-6585a3d3844d@github.com>
 <GBU3tbHKK8DeGlHpbr_OcAy4lvTud5Eol_aoEyLo1Yw=.7bd6568a-14a8-45f4-b363-22a8da6e1455@github.com>
 <ukeM3qk5B1A1RHt-Joy4EkpzTAQUNboxIIvYhUmfkSg=.18992498-24fc-4c93-8917-58894c070808@github.com>
 <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com>
Message-ID: <oBp6OJwJg3ig0DC6TwAKUM2qIGz7hlrQgf7oEtWSkBc=.bd93b5c0-2fc3-415b-95f9-7fcc57f8c7e0@github.com>

On Wed, 8 Nov 2023 15:45:56 GMT, Konrad Windszus <duke at openjdk.org> 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: <X1l_UPuyeihXui_6HL0nrNVCstCTNT7pyoPex9Yz-is=.f4f21a3d-7c72-4d49-9cc2-af4a5f2ed25c@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 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <tnXo0cEe34opr2017xfBPI1adTrcJDXwaSnmnOt3Gtg=.31f37e8c-a452-4cd6-ad7a-1cbc963e38d2@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>

> 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 <current>` 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <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 <jlaskey at openjdk.org> 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: <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
Message-ID: <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>

On Wed, 8 Nov 2023 22:17:21 GMT, Jonathan Gibbons <jjg at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
 <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com>
Message-ID: <QmmTOtq8LhXyK06zK3BG1cXVhF8SeM6FvWj20vO8bSg=.f09989f0-d9c0-4899-ad55-903f5f2767e9@github.com>

On Mon, 6 Nov 2023 23:14:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <tnXo0cEe34opr2017xfBPI1adTrcJDXwaSnmnOt3Gtg=.31f37e8c-a452-4cd6-ad7a-1cbc963e38d2@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <tnXo0cEe34opr2017xfBPI1adTrcJDXwaSnmnOt3Gtg=.31f37e8c-a452-4cd6-ad7a-1cbc963e38d2@github.com>
Message-ID: <A6NKLJEuw4U7to70jUqEhVU62X5MkU5SFf_5l6ONmwg=.d12d12f6-22f9-40fb-a3d8-6d34f4f133c8@github.com>

On Thu, 9 Nov 2023 10:55:06 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <VNloSPsWU_lPKKqBJlhCeIwQbOX1tROMhxcsQgbip_A=.a1bdad18-4621-4a9a-afaa-499d93f94b83@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <VNloSPsWU_lPKKqBJlhCeIwQbOX1tROMhxcsQgbip_A=.a1bdad18-4621-4a9a-afaa-499d93f94b83@github.com>
Message-ID: <HEA702gLqUw3fJ_xmxRIdhVdP8J0-n3_8KBK2GBMjqU=.44a92527-b9d8-403b-856f-32953f8be66c@github.com>

On Thu, 9 Nov 2023 00:01:26 GMT, Erik Joelsson <erikj at openjdk.org> 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 <current>` 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <z6CYao5VuULZx_6O5gBS4klLVM4J0NGTXGzlbz_z3dE=.9615eb9d-0389-43cd-835f-6005b7a974cd@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 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: <QmmTOtq8LhXyK06zK3BG1cXVhF8SeM6FvWj20vO8bSg=.f09989f0-d9c0-4899-ad55-903f5f2767e9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
 <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com>
 <QmmTOtq8LhXyK06zK3BG1cXVhF8SeM6FvWj20vO8bSg=.f09989f0-d9c0-4899-ad55-903f5f2767e9@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 <vromero at openjdk.org> 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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <IHMQ6rCSQpfc9LiN6ZXqdm44j4SAmRai7IxnrgH48rU=.39490c86-9bec-406b-a707-b49e529cad29@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 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: <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>
Message-ID: <cPd1Ufjj8VbWlXAINdnOnLUWMjg05UZWWpdElgCh6wQ=.392cc88d-bcfc-48e8-b884-267b6b46d355@github.com>

On Thu, 9 Nov 2023 14:09:39 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <gYw6Ee-cZ8P00zAjoXOQnVSMNi1NKnvt5v0x-UQiOmE=.ac4b29f1-c795-4519-8b86-a0d1f3958d24@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <gYw6Ee-cZ8P00zAjoXOQnVSMNi1NKnvt5v0x-UQiOmE=.ac4b29f1-c795-4519-8b86-a0d1f3958d24@github.com>
Message-ID: <I-B05d97BZN3PmI_HwDxQlzfubp9jh3rEw5F5YKGK40=.7b36ce4c-75c0-4f8a-a3c5-efdad4332c27@github.com>

On Wed, 8 Nov 2023 16:25:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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: <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>
Message-ID: <IZog47g0iHK-dNjGLfYUejgi_bw37ei33_uRsYa_JFY=.d32954a5-e63e-4051-b860-d1f76eaee491@github.com>

On Thu, 9 Nov 2023 14:09:39 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
References: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
Message-ID: <jtu6zkbuxPV5AeHQUq_oAyZ7kUFcsymqLzBHlhKi3Oc=.0826bb57-b11e-4b7a-a148-2dc95ea24491@github.com>

On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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<String> cannot be converted to List<Number>` rather than `incompatible types: List<String> 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: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
References: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
Message-ID: <nzd3GGTd-31F7O8NcRSp5y25CFXoJoqSZm_dqE36OzQ=.0f6754c3-e4cb-4773-b2f0-18f0d70c7a9c@github.com>

On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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<String> cannot be converted to List<Number>` rather than `incompatible types: List<String> 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: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>

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: <nzd3GGTd-31F7O8NcRSp5y25CFXoJoqSZm_dqE36OzQ=.0f6754c3-e4cb-4773-b2f0-18f0d70c7a9c@github.com>
References: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
 <nzd3GGTd-31F7O8NcRSp5y25CFXoJoqSZm_dqE36OzQ=.0f6754c3-e4cb-4773-b2f0-18f0d70c7a9c@github.com>
Message-ID: <YGwVpjHRm8tPJJEXn7PfE7nV9iQaX7yuGKwovmCwJSI=.9e4168e2-ec8b-4a50-a63a-ad019f9e00ac@github.com>

On Fri, 10 Nov 2023 01:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <awfZ_jlHUMamn0awWL61ZBYrp6z-MGsgU5146YLg5f0=.ed13b308-e789-4eef-873d-5a1218550f24@github.com>
References: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
 <awfZ_jlHUMamn0awWL61ZBYrp6z-MGsgU5146YLg5f0=.ed13b308-e789-4eef-873d-5a1218550f24@github.com>
Message-ID: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com>

On Fri, 3 Nov 2023 08:21:15 GMT, Adam Sotona <asotona at openjdk.org> 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: <Kouk85Cru2ApuOQmAfuXMNtA2zeLmMfgc3VkW-8zy_0=.ff233cb9-52e6-49e5-b872-d7083be7e250@github.com>
References: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>
 <Kouk85Cru2ApuOQmAfuXMNtA2zeLmMfgc3VkW-8zy_0=.ff233cb9-52e6-49e5-b872-d7083be7e250@github.com>
Message-ID: <WJN9vL-FQKCISBNXTM1YTS9ERpavtuBRGc3IFp2sv8o=.f0b3f2db-9cde-49ac-853c-bab39e7f95e8@github.com>

On Mon, 6 Nov 2023 08:39:27 GMT, Adam Sotona <asotona at openjdk.org> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
References: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
Message-ID: <MMdCX9G23Sa4v8Otr5Ci9efn9NnPVY7b3mM-ZKdZft0=.2a899885-d812-46db-b5ff-6ec0b7b490ab@github.com>

> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
 <awfZ_jlHUMamn0awWL61ZBYrp6z-MGsgU5146YLg5f0=.ed13b308-e789-4eef-873d-5a1218550f24@github.com>
 <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com>
Message-ID: <HfI3-x6nx64ikFHaoV2p3A4-7XVonUnRFSqKQE5gHTk=.1a46f4e4-679b-44c8-815c-0c4fd843a016@github.com>

On Fri, 10 Nov 2023 07:25:45 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
 <awfZ_jlHUMamn0awWL61ZBYrp6z-MGsgU5146YLg5f0=.ed13b308-e789-4eef-873d-5a1218550f24@github.com>
 <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com>
Message-ID: <iLvuarIL7Vra4N42DaHgX6PYYqij4ILlsi9F6EOUKRo=.6c4518dd-d495-419b-bab5-7284590b83dc@github.com>

On Fri, 10 Nov 2023 07:28:30 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <NjmOEF0YagdyGMDr8MYQXnI4GgLnDI-WUXmClJsuZE4=.32f1536a-8ec3-4632-b846-d678627520d8@github.com>

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: <rIsdGlquTQsEnqCk5QieoQu0X26BZq5c4N1eYVh1q4I=.37abc731-a08d-4273-b5b0-6d3b59497b6d@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <rIsdGlquTQsEnqCk5QieoQu0X26BZq5c4N1eYVh1q4I=.37abc731-a08d-4273-b5b0-6d3b59497b6d@github.com>
Message-ID: <F7apHeN6D271xfOCtC9K-nDQ7qYuHoUmWgBrlJq-J2I=.fdea9cbb-8213-42e1-843d-28d18ebfd4de@github.com>

On Thu, 6 Apr 2023 04:58:16 GMT, Joe Darcy <darcy at openjdk.org> 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<Void> 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: <YGwVpjHRm8tPJJEXn7PfE7nV9iQaX7yuGKwovmCwJSI=.9e4168e2-ec8b-4a50-a63a-ad019f9e00ac@github.com>
References: <I8ZyHOvAHcZuSVKbWYHtOLMYU5Zje2GzVoBEo1K9mtY=.1b2926b8-ae56-4186-855e-257df975c01d@github.com>
 <nzd3GGTd-31F7O8NcRSp5y25CFXoJoqSZm_dqE36OzQ=.0f6754c3-e4cb-4773-b2f0-18f0d70c7a9c@github.com>
 <YGwVpjHRm8tPJJEXn7PfE7nV9iQaX7yuGKwovmCwJSI=.9e4168e2-ec8b-4a50-a63a-ad019f9e00ac@github.com>
Message-ID: <Ul4jzR1rxba4ynqlJaihJi6FzaCR6Api1WJSnNMzTro=.1d06c8b2-9b19-4339-bada-0c773110f7c1@github.com>

On Fri, 10 Nov 2023 03:49:47 GMT, Joe Darcy <darcy at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <nKPz3UKLxlxHFWYlFPEo84MJfx-WcXmO6gA7ia3j8Rw=.7e7f8a2f-8d1b-4c02-a561-bd20f7dc76cd@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 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: <nKPz3UKLxlxHFWYlFPEo84MJfx-WcXmO6gA7ia3j8Rw=.7e7f8a2f-8d1b-4c02-a561-bd20f7dc76cd@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nKPz3UKLxlxHFWYlFPEo84MJfx-WcXmO6gA7ia3j8Rw=.7e7f8a2f-8d1b-4c02-a561-bd20f7dc76cd@github.com>
Message-ID: <yht6cvwuBYbNFqprqFfHuOiVD9wkf2fZphU1n2LNABI=.9cdfb214-5ba2-4263-9cbb-76ae1f475274@github.com>

On Fri, 10 Nov 2023 20:00:28 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <BvP33xRYa0XOmqFkueoLWLn2gY9ueO4mD98mIncCuEE=.6ddd342a-0130-448c-a8fe-cc7c8bb11897@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com>
Message-ID: <H1StkLOxxJtUe1xRxrcjW9KDbI4B0urSie-caiXCSzo=.3c3aa06b-5003-4009-96f4-7b80a2e18b80@github.com>

On Sat, 11 Nov 2023 15:53:41 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <b2Wk3ScGo9gRNiVpT63MYtLDFlGWBbfEdKyoXIQD_Sc=.ac8331a7-baa4-4d1c-bbed-c4aafbc6ecea@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <b2Wk3ScGo9gRNiVpT63MYtLDFlGWBbfEdKyoXIQD_Sc=.ac8331a7-baa4-4d1c-bbed-c4aafbc6ecea@github.com>
Message-ID: <KDSILIHN_m56wGSVayBL0bASX8--_t4l555T0w9Imok=.6e36de2f-9828-4bc5-b1eb-f5fa7a52c6e8@github.com>

On Mon, 6 Nov 2023 15:45:05 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: 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: <f062R34TEyBE3m33qz9Pz6f0TBCBjT13OrJSoZUWGF0=.ff63a848-ea18-458f-8ea3-79fc8f36c8cb@github.com>

> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@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:

  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: <f062R34TEyBE3m33qz9Pz6f0TBCBjT13OrJSoZUWGF0=.ff63a848-ea18-458f-8ea3-79fc8f36c8cb@github.com>
References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com>
 <f062R34TEyBE3m33qz9Pz6f0TBCBjT13OrJSoZUWGF0=.ff63a848-ea18-458f-8ea3-79fc8f36c8cb@github.com>
Message-ID: <FQPLycqsRyjrxY4lpwe_I2nDn2l25U2UUD1rWgbfGs0=.71c5d4e5-b80c-46e4-8a57-cc0b07082f3e@github.com>

On Mon, 13 Nov 2023 17:14:14 GMT, Vicente Romero <vromero at openjdk.org> 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: <XGkjj7xRzKoN7Sm24UFvifLZgSBIGoytrEkg4ViRtf8=.7deaffb6-0cbd-4d71-886c-b5b1ce283fcc@github.com>

On Wed, 1 Nov 2023 04:45:36 GMT, Vicente Romero <vromero at openjdk.org> 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 <vromero at openjdk.org>
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 <jlahoda at openjdk.org>
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: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
References: <MfbxQmx9UkDjJtPdJaPb1Ie_A5XOTxXmTQ16PP-IxAo=.331980e3-8ebb-443a-8845-0c0051d785d9@github.com>
Message-ID: <B4jqDC7OTnzvmCufJZobaxf3rhTVsfYiXZSjOJWuufY=.36346205-3991-4d0d-ad8c-32cd4b00ba63@github.com>

On Thu, 2 Nov 2023 18:01:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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 <cushon at openjdk.org>
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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <HDXO-NiPhRovwSTu4cTdeJHnQzeXw_UVsggKoTEVXn8=.5d3177b8-fd7b-44db-b3f8-55ed895ab705@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:

  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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <Q8aOFIrPhRBs4R0ldWlPIbFcZv2DNdqWV5Pe-oJyQAk=.e9bc6949-abe1-4fe0-9664-78d4bd2cda7f@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:

  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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <JvQHfNjkqUxZVblkDYNryxdSdStpTfyKK7RwpQlwSfY=.a9ee1fe9-9e4a-46ca-a94d-b278a5bc8a29@github.com>

On Wed, 8 Nov 2023 10:31:14 GMT, Pavel Rappo <prappo at openjdk.org> 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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com>

On Wed, 8 Nov 2023 10:59:58 GMT, Pavel Rappo <prappo at openjdk.org> 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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <0Xdi3qFcxeEQnEZs8Q393_unbH7679dhaxuKTGViUhA=.36dc71a2-6b38-4ef1-96ae-b0931dfd94c4@github.com>

On Wed, 8 Nov 2023 17:24:46 GMT, Pavel Rappo <prappo at openjdk.org> 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com>
Message-ID: <ag2dtvCzHnO2BJ1nv1d1c9I-zq4mz898SbOFC7ucmGQ=.0103ad58-bf4b-428f-a44d-d9b537954ba1@github.com>

On Wed, 15 Nov 2023 00:09:17 GMT, Jonathan Gibbons <jjg at openjdk.org> 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: <Pu1wVa9giLgoNxHnKOJUAhuDkjOrTF5shnWArJGWqpg=.fbfa09f9-0640-4734-9c63-db334d9084db@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <Pu1wVa9giLgoNxHnKOJUAhuDkjOrTF5shnWArJGWqpg=.fbfa09f9-0640-4734-9c63-db334d9084db@github.com>
Message-ID: <DfXUuCchGUfwJW0GxVU3l9QCnbBH-532hvSYKbteZHU=.f76b2219-2451-434d-9413-0735d643c544@github.com>

On Wed, 8 Nov 2023 17:28:10 GMT, Pavel Rappo <prappo at openjdk.org> 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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <5LmN58g4_56xYuRsehl-rCjb09n3YO8snUPTjsJeU9k=.41ef3b1f-f276-419f-90b5-9b6043c057d8@github.com>

On Wed, 8 Nov 2023 17:28:48 GMT, Pavel Rappo <prappo at openjdk.org> 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: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <Zwe6y0vUwzwB1fCJM_FiKalBTvej10e5oxQIjX-xNJk=.ab043e54-14a4-4f9c-9687-7957354d460d@github.com>

On Wed, 8 Nov 2023 17:37:25 GMT, Pavel Rappo <prappo at openjdk.org> 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: <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
 <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
Message-ID: <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>

On Thu, 9 Nov 2023 16:39:58 GMT, Pavel Rappo <prappo at openjdk.org> 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: <mLxwj42rbBdzDpe6axuRcFJXZA-pONmtLoiUWn8-6Bg=.3fe32bc0-a636-413e-a41f-cc6329bf186a@github.com>

On Wed, 15 Nov 2023 04:22:15 GMT, Vicente Romero <vromero at openjdk.org> 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: <H1StkLOxxJtUe1xRxrcjW9KDbI4B0urSie-caiXCSzo=.3c3aa06b-5003-4009-96f4-7b80a2e18b80@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com>
 <H1StkLOxxJtUe1xRxrcjW9KDbI4B0urSie-caiXCSzo=.3c3aa06b-5003-4009-96f4-7b80a2e18b80@github.com>
Message-ID: <-9vMMWxs2cxsB4xoK1g37hZkdIaLWe30KsVssp1mgGU=.7680c892-9645-4c45-b511-52f02de42b3d@github.com>

On Sat, 11 Nov 2023 15:57:40 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <mLxwj42rbBdzDpe6axuRcFJXZA-pONmtLoiUWn8-6Bg=.3fe32bc0-a636-413e-a41f-cc6329bf186a@github.com>
References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com>
 <mLxwj42rbBdzDpe6axuRcFJXZA-pONmtLoiUWn8-6Bg=.3fe32bc0-a636-413e-a41f-cc6329bf186a@github.com>
Message-ID: <9jPTQJcLsVDxf_kb4qLdScSvp0S5hfUD2IFxU6xQl84=.bd89cffa-c13d-4842-931e-2230e807f715@github.com>

On Wed, 15 Nov 2023 15:26:42 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
Message-ID: <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>

On Tue, 14 Nov 2023 13:35:46 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
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: <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
 <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
 <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>
Message-ID: <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com>

On Wed, 15 Nov 2023 00:58:51 GMT, Jonathan Gibbons <jjg at openjdk.org> 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 <vromero at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <FBKURHo6hy7s0HIxENtujHdSBCXMxV4yRl0aWh7YFWw=.d7a727ac-d60f-4b89-899a-77469c7e6046@github.com>

> 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 <current>` 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <Y_PbiT5jdmm20Dl-KPJ1e-MAnqLVYdm_DU08ywKCRCQ=.f5ccb281-c2a7-4810-a3f9-d735cbb03c64@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:

  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: <QTStkCeGr23zxehvF2TWEmopYeMuW9toIiPcIsKvpKw=.3a3339fb-4c93-48df-82d2-f2eb5a6dbe0d@github.com>

On Thu, 16 Nov 2023 04:29:51 GMT, Vicente Romero <vromero at openjdk.org> 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 <vromero at openjdk.org> 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 <vromero at openjdk.org>
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: <QTStkCeGr23zxehvF2TWEmopYeMuW9toIiPcIsKvpKw=.3a3339fb-4c93-48df-82d2-f2eb5a6dbe0d@github.com>
References: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com>
 <QTStkCeGr23zxehvF2TWEmopYeMuW9toIiPcIsKvpKw=.3a3339fb-4c93-48df-82d2-f2eb5a6dbe0d@github.com>
Message-ID: <qV7NHGs5z4K67Z_HflYyJyEEmqbH-gB7SXEZT8goUTQ=.81bd4ea8-fab8-49cb-ab31-fbfa3885d81d@github.com>

On Thu, 16 Nov 2023 13:46:03 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <X7VGJBORxXgYl0mhwnhoedxdCv860AscHnnLBawEDC8=.03007eb4-be18-494d-b5b2-cbac1ad9e01a@github.com>

On Thu, 16 Nov 2023 04:29:51 GMT, Vicente Romero <vromero at openjdk.org> 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 <vromero at openjdk.org>
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: <uFepEcWPUftTTALfeUiY6LeSSfcIulxCMxjS77V_NuU=.04d8d9ee-2392-4756-83f8-2f1a9c0cc6fd@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/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 <raffaello.giulietti at oracle.com>
 - 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <tNRC8M90OEzk0NTfaV1JKBFOF00xqoQMymh_ZfD5tOs=.a375c665-53ce-4fac-bdb5-81995a755ce0@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 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: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <AXuNMbf6szyhaTS6Lgj2s0vjAKrlKDACx3T8-D1SDOA=.57683ed1-04a6-4608-b0e2-a04ae49ad3b0@github.com>

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey <jlaskey at openjdk.org> 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 <jlaskey at openjdk.org>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <kXezZHDw42BRp2AMzYApqIvG8wZOoJhkPXk1fCW_Ah4=.c0ee5996-300a-445f-9ac8-466273c67cd8@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:

  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: <LYbF3tPB5KZ5xBcRU9fqGUAfvP3os3e7Eje7UMyQzEM=.b548ca93-4583-460c-99c2-d9672cd0f8cb@github.com>

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

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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 <raffaello.giulietti at oracle.com>
 - ... 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <FouxRNt3_aKtSqMgb9ioo8wIrJxDbF6EgnkbmTorf0I=.2b31cdbe-67fe-4e33-b06a-41f14d832cf2@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <ON0u2uY1alQ159UcDd9pruX7vRpNaMlzQdt8WArB9yM=.29d18cea-f723-4a97-9dec-e4d44aa2ec22@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <eQk3JMpdAIFDuLVYRXzB2MfurPyMG3qrNLOau1rHvd0=.4374e8b6-77a1-4b45-9288-dc2531577da4@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <wEnq5baVIiwnN4_fhunTcIAeqhFLOTGUnBiAsXnpmfQ=.494d0e2a-af5c-49f4-a972-bd8f7b0be0ed@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <KOE0gpPbGhRg6NwE9QfEwlniISM85JIbgeFLEFp7HRM=.7efaaaf8-239b-4fb5-aa46-77504c68024e@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:

  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: <Q4cOUKVitHgXJbTIdlcgG8b29ErFzVObaKTslGUk-KU=.d287423e-00c3-4772-b327-50d00d6b04b5@github.com>

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

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <UD95TiQZvqGekfqH41TaJzojYNpOiTgffgeHt1qKWU4=.a50efbaf-b338-4dd3-b92d-5ccf1c5e3d2d@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <kXezZHDw42BRp2AMzYApqIvG8wZOoJhkPXk1fCW_Ah4=.c0ee5996-300a-445f-9ac8-466273c67cd8@github.com>
 <UD95TiQZvqGekfqH41TaJzojYNpOiTgffgeHt1qKWU4=.a50efbaf-b338-4dd3-b92d-5ccf1c5e3d2d@github.com>
Message-ID: <nhftRPjOyMdisGmXpnuXSdZk8WmpOl_Eaa1o0JIeq2Y=.7231a9eb-ec81-4dcb-984a-78b032294c8c@github.com>

On Mon, 20 Nov 2023 11:53:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <kXezZHDw42BRp2AMzYApqIvG8wZOoJhkPXk1fCW_Ah4=.c0ee5996-300a-445f-9ac8-466273c67cd8@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <kXezZHDw42BRp2AMzYApqIvG8wZOoJhkPXk1fCW_Ah4=.c0ee5996-300a-445f-9ac8-466273c67cd8@github.com>
Message-ID: <UD95TiQZvqGekfqH41TaJzojYNpOiTgffgeHt1qKWU4=.a50efbaf-b338-4dd3-b92d-5ccf1c5e3d2d@github.com>

On Fri, 17 Nov 2023 13:56:13 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <uF7-kWL_Fy4dKKVvO43mgyVmQPITX2MPXmEJkLKYLvM=.3c668a66-2e5b-4794-b3e1-718b38025f0b@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:

  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: <KOE0gpPbGhRg6NwE9QfEwlniISM85JIbgeFLEFp7HRM=.7efaaaf8-239b-4fb5-aa46-77504c68024e@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <KOE0gpPbGhRg6NwE9QfEwlniISM85JIbgeFLEFp7HRM=.7efaaaf8-239b-4fb5-aa46-77504c68024e@github.com>
Message-ID: <QxR_8zVEYbQdx9-ItTMIg3vIu_iFo8LS5aEgWE01WRE=.6d07eb57-11fa-4daa-98e0-c2c7cbea6ee7@github.com>

On Sun, 19 Nov 2023 20:14:10 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <QxR_8zVEYbQdx9-ItTMIg3vIu_iFo8LS5aEgWE01WRE=.6d07eb57-11fa-4daa-98e0-c2c7cbea6ee7@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <KOE0gpPbGhRg6NwE9QfEwlniISM85JIbgeFLEFp7HRM=.7efaaaf8-239b-4fb5-aa46-77504c68024e@github.com>
 <QxR_8zVEYbQdx9-ItTMIg3vIu_iFo8LS5aEgWE01WRE=.6d07eb57-11fa-4daa-98e0-c2c7cbea6ee7@github.com>
Message-ID: <x7OAAmhi1DldehnmaEYbx34e3FyYdfOhu4teY1cTctE=.302675f0-014c-4c48-9708-23df4a4e7273@github.com>

On Mon, 20 Nov 2023 13:50:45 GMT, Alan Bateman <alanb at openjdk.org> 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<Method>` 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <nhftRPjOyMdisGmXpnuXSdZk8WmpOl_Eaa1o0JIeq2Y=.7231a9eb-ec81-4dcb-984a-78b032294c8c@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <kXezZHDw42BRp2AMzYApqIvG8wZOoJhkPXk1fCW_Ah4=.c0ee5996-300a-445f-9ac8-466273c67cd8@github.com>
 <UD95TiQZvqGekfqH41TaJzojYNpOiTgffgeHt1qKWU4=.a50efbaf-b338-4dd3-b92d-5ccf1c5e3d2d@github.com>
 <nhftRPjOyMdisGmXpnuXSdZk8WmpOl_Eaa1o0JIeq2Y=.7231a9eb-ec81-4dcb-984a-78b032294c8c@github.com>
Message-ID: <DUEVbSUwRoNxfd7W9w1Qk54-vQMxK6Rxaovair1qvos=.69208dc4-ac68-46ea-9d3e-ccc45dd1cc8f@github.com>

On Mon, 20 Nov 2023 11:55:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <tCHrzf3AjmV05UHGbeL9RuW3BGypNW9Q-tL4WPFsCdw=.7ec22bfe-f048-4e62-a175-ba8e1cee1a61@github.com>

> 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 <current>` 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <uPVpZrqAW1eIHyTSWv5OzLHGWuY2Y1z0vZNoBrSgkAg=.5776df94-eb3b-4893-bc1f-5aa53e7974ab@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:

  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: <x7OAAmhi1DldehnmaEYbx34e3FyYdfOhu4teY1cTctE=.302675f0-014c-4c48-9708-23df4a4e7273@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <KOE0gpPbGhRg6NwE9QfEwlniISM85JIbgeFLEFp7HRM=.7efaaaf8-239b-4fb5-aa46-77504c68024e@github.com>
 <QxR_8zVEYbQdx9-ItTMIg3vIu_iFo8LS5aEgWE01WRE=.6d07eb57-11fa-4daa-98e0-c2c7cbea6ee7@github.com>
 <x7OAAmhi1DldehnmaEYbx34e3FyYdfOhu4teY1cTctE=.302675f0-014c-4c48-9708-23df4a4e7273@github.com>
Message-ID: <ymEt9pz7zCFsBn31JQLtEHLruvBKG2E9WWIy75iRy38=.8a96bda2-513a-4294-a087-019344b550a1@github.com>

On Mon, 20 Nov 2023 13:56:13 GMT, Christian Stein <cstein at openjdk.org> 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<Method>` as the return type.
> 
> Or `Optional<Method> 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: <IZog47g0iHK-dNjGLfYUejgi_bw37ei33_uRsYa_JFY=.d32954a5-e63e-4051-b860-d1f76eaee491@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <TVkfckVm7fSopz0RC7ayzcdRTfocFJluhSlEM2TokbU=.1d5ff5d1-567b-47c2-9657-eec5a4e6f174@github.com>
 <IZog47g0iHK-dNjGLfYUejgi_bw37ei33_uRsYa_JFY=.d32954a5-e63e-4051-b860-d1f76eaee491@github.com>
Message-ID: <9MSelUgHbXKbq6YD59zaAhQhJsoFMn_P0UhLWmxTEJw=.ca7685ef-de64-4916-bc33-e04f6f333501@github.com>

On Fri, 10 Nov 2023 00:42:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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: <kQQe1t5zi3QwqiJwX97ed-WlTdUwaacrcdLrHRWd0Gs=.53416c9e-e48a-4d97-b935-3608f44cdeeb@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:

  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: <OptrmmMzP2c5TMSzrdbPy3CTtgEfctEgd8HhqJZ0T_A=.c8b38241-3c23-444e-8aaf-8dc42dca0447@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <gvM-zwlNQ6FK_qYVj93B-kmwIst1XadavJErXZifCKI=.4437a706-51c8-44c8-889a-d92719705d3e@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:

  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: <MMdCX9G23Sa4v8Otr5Ci9efn9NnPVY7b3mM-ZKdZft0=.2a899885-d812-46db-b5ff-6ec0b7b490ab@github.com>
References: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
 <MMdCX9G23Sa4v8Otr5Ci9efn9NnPVY7b3mM-ZKdZft0=.2a899885-d812-46db-b5ff-6ec0b7b490ab@github.com>
Message-ID: <cVNjh9rP4XeSdXKvr9I-64Dyv0qKdpA6fOmWxjQ9Mc8=.698b315d-5585-4ca6-b07b-19f7e146646d@github.com>

On Fri, 10 Nov 2023 08:38:09 GMT, Adam Sotona <asotona at openjdk.org> 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: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
References: <ek8mW9jZvt4M-d7YF4fEfedIaasOHDXINX9M_Fga2JA=.328484df-0641-4098-8649-6f5a00cf395d@github.com>
Message-ID: <vm2o2mvQm9OXiYI72haAGsCt-wcBl2PUjZUzHGN0ZRk=.59b5e7c3-202f-482e-9e51-554a41d5b4a6@github.com>

On Thu, 2 Nov 2023 13:49:17 GMT, Adam Sotona <asotona at openjdk.org> 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 <asotona at openjdk.org>
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: <tCHrzf3AjmV05UHGbeL9RuW3BGypNW9Q-tL4WPFsCdw=.7ec22bfe-f048-4e62-a175-ba8e1cee1a61@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <tCHrzf3AjmV05UHGbeL9RuW3BGypNW9Q-tL4WPFsCdw=.7ec22bfe-f048-4e62-a175-ba8e1cee1a61@github.com>
Message-ID: <9T3oRP6oweDe_Suigeg0k1PX1D_i3Zbg3KyzZZkab5M=.effc1035-6099-4fab-91f0-7274ea73d045@github.com>

On Mon, 20 Nov 2023 17:20:50 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <CuUDVMMrGtq0G6i1ZcBhlowx1RpG7RJo2xfKa4k1ETg=.9c87e199-89a5-4e09-8254-b10c96b69034@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 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: <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
 <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>
Message-ID: <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>

On Wed, 15 Nov 2023 15:54:26 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
 <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>
 <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>
Message-ID: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com>

On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo <prappo at openjdk.org> 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: <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
 <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>
 <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>
Message-ID: <UXjip-kPtSDUUVFf7UCUpcdmeYcHmCEpnMgUMVnOtdw=.c82be40d-b6d2-4e1a-88d7-2ca9a4755615@github.com>

On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo <prappo at openjdk.org> 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: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>
References: <XihSYsriBH80SeZSTBatxije2np2ih0-HjcL1BhG8ok=.5cfc97ba-86cb-44da-88fd-a30ab80145e1@github.com>
Message-ID: <lBLnuDjyAy7Vca5Bz-pCRUBfXDPtoM_pS-E2xI4KSK0=.d4400b9e-f6a7-415a-ad6b-4a7af1e273a5@github.com>

On Wed, 1 Nov 2023 15:33:24 GMT, Adam Sotona <asotona at openjdk.org> 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 <asotona at openjdk.org>
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 <cstein at openjdk.org> 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: <gvM-zwlNQ6FK_qYVj93B-kmwIst1XadavJErXZifCKI=.4437a706-51c8-44c8-889a-d92719705d3e@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gvM-zwlNQ6FK_qYVj93B-kmwIst1XadavJErXZifCKI=.4437a706-51c8-44c8-889a-d92719705d3e@github.com>
Message-ID: <fsOPGYkSgJy686-d_Y0dcSZfAA1R9z1H3XWw7WbwvnM=.c15c7072-4885-452b-a7bf-6c6a64641c6a@github.com>

On Mon, 20 Nov 2023 20:45:22 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <rm2N1fRWQmjlaGoF6deLQkNuMz3y4PeDEGGBqR2L5A0=.995ffb28-11f3-4094-b30c-d4bd826cc070@github.com>

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

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <nL9aQeJmC1d5aAoT2swcZGOID3LCsROCxMRCZO78mPM=.d9ae00f0-2815-46e5-858b-771c3708dde2@github.com>
 <YXdxTskcxlzg54v9O5gIq-O-g0kTL3W5TeD4AmLM5Jc=.638a5cbd-1ccc-4801-bee6-58f6dd155b00@github.com>
 <h-AXPufTj3gsF6JxKoiuONu8JlhGId87ANsKB-rG5jI=.dae61d7d-6a8d-4ada-80b2-162e744703d0@github.com>
 <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com>
Message-ID: <XrNQpxoKfdqz_HYv4BjQVk2IrpwERrQRG6Ofizu8KYE=.438fb54d-3b7f-471d-8001-2431d627c71c@github.com>

On Tue, 21 Nov 2023 12:58:42 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
Message-ID: <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>

On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
 <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>
Message-ID: <i4S4815P7ul2g382Z2iN29wLaic0C6Mu8hfZCIIT41Y=.92bde411-bd9b-4843-a77a-e0a1e5125e78@github.com>

On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <i4S4815P7ul2g382Z2iN29wLaic0C6Mu8hfZCIIT41Y=.92bde411-bd9b-4843-a77a-e0a1e5125e78@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
 <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>
 <i4S4815P7ul2g382Z2iN29wLaic0C6Mu8hfZCIIT41Y=.92bde411-bd9b-4843-a77a-e0a1e5125e78@github.com>
Message-ID: <R-BxFq09oWG9d8CBBZRZyyKBbL95MoxoFX6O9xmOdBw=.3ea35beb-4207-47f0-b378-c3c0516ca712@github.com>

On Tue, 21 Nov 2023 18:59:51 GMT, Pavel Rappo <prappo at openjdk.org> 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: <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
Message-ID: <Q9vp_SXVOcd72q09DGSwTMwEC9PzRALD_kJPziVzsv8=.6a8f008c-6c72-4da9-ad27-d370a4593bb0@github.com>

On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey <jlaskey at openjdk.org> 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:      * <p>{@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: <Q9vp_SXVOcd72q09DGSwTMwEC9PzRALD_kJPziVzsv8=.6a8f008c-6c72-4da9-ad27-d370a4593bb0@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
 <Q9vp_SXVOcd72q09DGSwTMwEC9PzRALD_kJPziVzsv8=.6a8f008c-6c72-4da9-ad27-d370a4593bb0@github.com>
Message-ID: <BX8U1ZIjtq0_05F00j0T9-cN1KTDLUjVE-aWhn-QXJY=.d221fe5f-e568-4734-9010-0d43c978cd47@github.com>

On Tue, 21 Nov 2023 19:16:06 GMT, Alan Bateman <alanb at openjdk.org> 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:      * <p>{@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: <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <gtQnuOwsdwSnXEni29Ffhp3-Wo7r5KE9ySamgLuGS0g=.1f5463ab-5ab1-4a1e-afe7-91fc72909d99@github.com>
 <MNkDoq-AQkO02yFklrBUm6JaRjwsTiq1ewp4pHjVE_E=.49a1765a-5a77-4bd1-827f-d4d54c917308@github.com>
Message-ID: <7WfOKRXJUWg0CT8T4RqwC5VzgJp2ZEbnvrr39TLpJHk=.517338f9-dfe0-4b7d-bf18-b117818aa98a@github.com>

On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@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

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

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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
Message-ID: <mneus369NEIPsmV6CL2sznsQ-pr0RVrPeaRi189IlIY=.dc76607c-e67d-4478-b9c7-9e9794c1848e@github.com>

On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero <vromero at openjdk.org> 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: <mneus369NEIPsmV6CL2sznsQ-pr0RVrPeaRi189IlIY=.dc76607c-e67d-4478-b9c7-9e9794c1848e@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <mneus369NEIPsmV6CL2sznsQ-pr0RVrPeaRi189IlIY=.dc76607c-e67d-4478-b9c7-9e9794c1848e@github.com>
Message-ID: <XrvBcTCmnj7ygbgG9PcwmTU8sS2jjrv6T8872p-qR78=.daab4f81-4ae4-4b3f-b88c-48108ce9670a@github.com>

On Tue, 21 Nov 2023 22:48:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
Message-ID: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com>

On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero <vromero at openjdk.org> 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: <XrvBcTCmnj7ygbgG9PcwmTU8sS2jjrv6T8872p-qR78=.daab4f81-4ae4-4b3f-b88c-48108ce9670a@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <mneus369NEIPsmV6CL2sznsQ-pr0RVrPeaRi189IlIY=.dc76607c-e67d-4478-b9c7-9e9794c1848e@github.com>
 <XrvBcTCmnj7ygbgG9PcwmTU8sS2jjrv6T8872p-qR78=.daab4f81-4ae4-4b3f-b88c-48108ce9670a@github.com>
Message-ID: <Osyb3JBEvTPmHwN4P1nidZ2AKTPcBxsxRVc6wbr4tiQ=.35a11a2e-c525-46b1-901d-81f7084200c4@github.com>

On Tue, 21 Nov 2023 23:22:47 GMT, Vicente Romero <vromero at openjdk.org> 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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com>
Message-ID: <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>

On Tue, 21 Nov 2023 23:30:28 GMT, Werner Dietl <wmdietl at openjdk.org> 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: <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com>
 <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>
Message-ID: <kUlzAwgGfaqB-muGvtI2oLk9qoQ8QnwX3mShCAQi2B0=.767eb3c7-391c-4c68-b549-40d98dd5ff3e@github.com>

On Tue, 21 Nov 2023 23:39:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com>
 <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>
Message-ID: <w0vFXAmFqA3CWkW-krjwZ-7buSNyusH-7dZde_1uQs8=.ee79c38a-6313-4f2b-a234-c7778d5c1829@github.com>

On Tue, 21 Nov 2023 23:39:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <Osyb3JBEvTPmHwN4P1nidZ2AKTPcBxsxRVc6wbr4tiQ=.35a11a2e-c525-46b1-901d-81f7084200c4@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <mneus369NEIPsmV6CL2sznsQ-pr0RVrPeaRi189IlIY=.dc76607c-e67d-4478-b9c7-9e9794c1848e@github.com>
 <XrvBcTCmnj7ygbgG9PcwmTU8sS2jjrv6T8872p-qR78=.daab4f81-4ae4-4b3f-b88c-48108ce9670a@github.com>
 <Osyb3JBEvTPmHwN4P1nidZ2AKTPcBxsxRVc6wbr4tiQ=.35a11a2e-c525-46b1-901d-81f7084200c4@github.com>
Message-ID: <R9tdEaDiJtEhrt37zUTWR6WfySZ0RuywUmjw5rC1mW4=.131169c3-22ca-40d1-910e-c6c19b20f7f9@github.com>

On Tue, 21 Nov 2023 23:31:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
Message-ID: <X5I-xJvgNNn0kdD5SGBj0n2qmQbv5k7NYGQ1xm7Ck3s=.ac0e5628-da18-40d9-983f-3d7c2877bb83@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:

  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: <w0vFXAmFqA3CWkW-krjwZ-7buSNyusH-7dZde_1uQs8=.ee79c38a-6313-4f2b-a234-c7778d5c1829@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com>
 <eMqAGtNMVPMhPOI68GGOUJS04c_NBeBF4mKdvspN8GQ=.a4184041-3ea5-4676-bf19-5a2f0aced5ec@github.com>
 <w0vFXAmFqA3CWkW-krjwZ-7buSNyusH-7dZde_1uQs8=.ee79c38a-6313-4f2b-a234-c7778d5c1829@github.com>
Message-ID: <9WGf0HeoFjA9JgTZKJz-s17dAuxLoNfPfhwvhid7ZNw=.c9645aff-6e9a-4267-86fe-03ae20cda776@github.com>

On Wed, 22 Nov 2023 00:04:40 GMT, Werner Dietl <wmdietl at openjdk.org> 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: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com>
Message-ID: <Djw9flhSIBqkEoXerycl6GsJeykdYVN3Fjnn7TmSbFA=.38442fba-91ad-48fa-b870-4c44641dbe83@github.com>

On Wed, 15 Nov 2023 18:58:43 GMT, Jonathan Gibbons <jjg at openjdk.org> 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<DCTree> 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: <FXznkVxZrYUJBCVSlsYUaBDxXG1Pt8qo8X5iWb38nPw=.88c2fbbb-bc37-4d3d-8d63-f7d2ba1166de@github.com>

On Tue, 21 Nov 2023 08:41:00 GMT, Christian Stein <cstein at openjdk.org> 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 <cstein at openjdk.org>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <N6gCR4n647G_lLAIGrORuuvEYWQ6_jdoWN3wEwTkkIw=.5febcb3f-00f5-4f25-855e-abee0b7af917@github.com>

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: <X5I-xJvgNNn0kdD5SGBj0n2qmQbv5k7NYGQ1xm7Ck3s=.ac0e5628-da18-40d9-983f-3d7c2877bb83@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
 <X5I-xJvgNNn0kdD5SGBj0n2qmQbv5k7NYGQ1xm7Ck3s=.ac0e5628-da18-40d9-983f-3d7c2877bb83@github.com>
Message-ID: <cVr_hxAzwh9YupKu6zu8-77ewHY9q2YNlZp64FTwTwg=.3934b653-dad4-4c9e-811d-840f9d336590@github.com>

On Wed, 22 Nov 2023 01:06:35 GMT, Vicente Romero <vromero at openjdk.org> 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: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231122/fe0462bc/attachment.htm>

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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com>
Message-ID: <k-sHPdCSCB51V-HP16AkLRxRVr6ewcyGLe_33gSuQyQ=.a38704a6-d29a-4d27-8515-862b0f7b6d60@github.com>

On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
References: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
Message-ID: <dMC3WDfhDE52hCNPMGWpX7fQj_SDJX5yXlWARbo3XhY=.291c6387-f9b7-4133-bdcb-6eeb912ddc85@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 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: <N6gCR4n647G_lLAIGrORuuvEYWQ6_jdoWN3wEwTkkIw=.5febcb3f-00f5-4f25-855e-abee0b7af917@github.com>
References: <N6gCR4n647G_lLAIGrORuuvEYWQ6_jdoWN3wEwTkkIw=.5febcb3f-00f5-4f25-855e-abee0b7af917@github.com>
Message-ID: <kisJORo7m1Lh0QyoJd49CHB8QxbV2Lce6vvxbolo8OU=.b3597676-34ae-4fab-86c0-f2fa79dcc844@github.com>

On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer <clanger at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com>
Message-ID: <sHzDxI3FyummEE2h7rSf2DWpx2rz8UnorCfVH6Y6tFg=.08f110cb-2c5f-4714-9535-a1644e66e8c4@github.com>

On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
References: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
Message-ID: <IA1PR10MB75158329A44CE42CB9236DDD82B9A@IA1PR10MB7515.namprd10.prod.outlook.com>

Thanks for the analysis and report

Opened https://bugs.openjdk.org/browse/JDK-8320660

________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Werner Dietl <wdietl at gmail.com>
Sent: 22 November 2023 18:55
To: compiler-dev <compiler-dev at openjdk.java.net>
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: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231123/eeb1da85/attachment-0001.htm>

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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <GPI78Y4eEofAZLD3a0X0-C5K3Iak4V4scXVX2Yj4bzw=.351ce5e9-e5ba-4107-a2ab-a8d579092387@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@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 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: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
Message-ID: <t6yedn8ITAKgjJsEDZKwyD6iy0HgsMFgR6RMTRgodb4=.d30c6b84-1a78-409a-b930-b16cd24330b6@github.com>

On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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 <jlahoda at openjdk.org>
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 <erikj at openjdk.org>
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: <tCHrzf3AjmV05UHGbeL9RuW3BGypNW9Q-tL4WPFsCdw=.7ec22bfe-f048-4e62-a175-ba8e1cee1a61@github.com>
References: <UUiIPpf2BMElXWKaZPCv84mDIp384fApd9qmjM6FFj0=.a4345265-d4f9-4e13-952b-b722bac85025@github.com>
 <tCHrzf3AjmV05UHGbeL9RuW3BGypNW9Q-tL4WPFsCdw=.7ec22bfe-f048-4e62-a175-ba8e1cee1a61@github.com>
Message-ID: <Ky2WZj4HPoEhkGHUwC6GUtdWv2eojKfIlZ53TLLPQ-g=.98890560-7ace-44e7-9428-7845e1c4a8e3@github.com>

On Mon, 20 Nov 2023 17:20:50 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <current>` 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: <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@github.com>
Message-ID: <LReoDSLTohQQi1SV8DyJqKuq-SIKtDyTi26aqUYNiz0=.016be10b-9340-433d-b966-d105bbb9ab81@github.com>

On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@github.com>
Message-ID: <R4WLmEBMEwemkYoFam_ZAaY4UJ7dP-NZz3eRuPwCzvA=.2de6c810-ed82-491d-b0f6-1bc1e5ce8802@github.com>

On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@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 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: <LReoDSLTohQQi1SV8DyJqKuq-SIKtDyTi26aqUYNiz0=.016be10b-9340-433d-b966-d105bbb9ab81@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <DpnBCcFU4skjHp6HOrouHCG3nf_HA6cVi0ArN2R4FpE=.5f02bda7-aff5-491c-8724-8ed2b5b669da@github.com>
 <LReoDSLTohQQi1SV8DyJqKuq-SIKtDyTi26aqUYNiz0=.016be10b-9340-433d-b966-d105bbb9ab81@github.com>
Message-ID: <TNBDWW34siXS3-MQ65j6Y7hlJWwo9l5uOu3V5ukTr24=.3d24de4b-3d8a-41a1-9b6f-4fbc49cfce4b@github.com>

On Fri, 24 Nov 2023 11:00:18 GMT, Alan Bateman <alanb at openjdk.org> 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: <N6gCR4n647G_lLAIGrORuuvEYWQ6_jdoWN3wEwTkkIw=.5febcb3f-00f5-4f25-855e-abee0b7af917@github.com>
References: <N6gCR4n647G_lLAIGrORuuvEYWQ6_jdoWN3wEwTkkIw=.5febcb3f-00f5-4f25-855e-abee0b7af917@github.com>
Message-ID: <l-zYu-WEIArnrV6zVpmyyt2VmCz6imeV8hILRDw-090=.85fa7ea7-9acc-448d-852f-6f4da61877dc@github.com>

On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer <clanger at openjdk.org> 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 <clanger at openjdk.org>
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: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
 <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com>
Message-ID: <CAL4QsguAXd16-tyK0dAJ8xO9G_cL-Um-Z84+cYi8O7_H7=Qw3w@mail.gmail.com>

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 <alex.buckley at oracle.com>
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: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231127/9b503bbb/attachment-0001.htm>

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: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
References: <K0-Glr2tyTjptErDS7xMBkq14EmV5D1ZVO2H5xCsoj0=.188e44ab-6522-4aa9-adc5-8d6631586772@github.com>
Message-ID: <ybkHod_uSkvyiWQg1FXt1PTuvJDT-lthH9s8HN0bmwI=.40ca2759-aa6a-4668-9fb1-1241fdeebab8@github.com>

On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero <vromero at openjdk.org> 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 <vromero at openjdk.org>
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: <kkWR6yXfWwFD4NMpRvOt4u8D55PUctHCXxX74RoujAc=.b49b80e1-b100-4c10-b72e-47402be5130a@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <kkWR6yXfWwFD4NMpRvOt4u8D55PUctHCXxX74RoujAc=.b49b80e1-b100-4c10-b72e-47402be5130a@github.com>
Message-ID: <YSwX5d4yq6xrdRY3myIze6KCgYYTOZa9QjWTeCHlZq0=.eaa4f246-85b4-4502-84f3-65cadfa5d1a6@github.com>

On Mon, 6 Nov 2023 21:14:07 GMT, Archie Cobbs <acobbs at openjdk.org> 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 <span>#</span>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: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <GS417dYmvE19LBwPTJgLQ0EnC5raLIuc5l4BPv611-8=.8f7bf4af-5119-4452-94ae-6dd1af35af67@github.com>

On Tue, 25 Apr 2023 20:40:18 GMT, Archie Cobbs <acobbs at openjdk.org> 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 <span>#</span>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 <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
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: <CAL4QsguAXd16-tyK0dAJ8xO9G_cL-Um-Z84+cYi8O7_H7=Qw3w@mail.gmail.com>
References: <CAJYRO=7ttWELDY5dhd4zm1mAw2EXnyRN7x5aT8Wt4NFUbQ10Ng@mail.gmail.com>
 <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com>
 <CAL4QsguAXd16-tyK0dAJ8xO9G_cL-Um-Z84+cYi8O7_H7=Qw3w@mail.gmail.com>
Message-ID: <CAJYRO=7Vys-EWMHpkOyut-JG+Herkz9737h1A0pfrCSyM36rYA@mail.gmail.com>

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 <cushon at google.com>
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 <alex.buckley at oracle.com>
> 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: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231127/97472ca1/attachment-0001.htm>

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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com>

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

> Time to start making preparations for JDK 23.

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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>

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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <n65r3OHuJl8T-u4_Db3sVDwSweMraaSX58tbMIXf7iY=.8eb62167-47a2-4eba-933a-8910ae47ce9b@github.com>

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

> Time to start making preparations for JDK 23.

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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com>
Message-ID: <GpEnHGCNwxp6mrOIZKtn6p_PmoVna9xL4PtS3CebYbY=.6f3fb6c8-8416-4690-9909-8d8edf34593d@github.com>

On Fri, 3 Nov 2023 23:52:45 GMT, Chen Liang <liach at openjdk.org> 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: <pnKcUK_RQk2lKvUaKsA9Owi9HrGsy3I9Pq75f6Y5yxE=.b91f1923-ce37-4aec-8d0f-ee82c7e8d7dd@github.com>

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: <pnKcUK_RQk2lKvUaKsA9Owi9HrGsy3I9Pq75f6Y5yxE=.b91f1923-ce37-4aec-8d0f-ee82c7e8d7dd@github.com>
References: <pnKcUK_RQk2lKvUaKsA9Owi9HrGsy3I9Pq75f6Y5yxE=.b91f1923-ce37-4aec-8d0f-ee82c7e8d7dd@github.com>
Message-ID: <m7UwDBlL8ptfFwPudYTaHH0zxfEEYM69HA5u_qeTqf8=.344d19e4-2ffc-455f-8553-ebc2f5386aea@github.com>

On Mon, 27 Nov 2023 20:17:44 GMT, Joe Darcy <darcy at openjdk.org> 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: <pnKcUK_RQk2lKvUaKsA9Owi9HrGsy3I9Pq75f6Y5yxE=.b91f1923-ce37-4aec-8d0f-ee82c7e8d7dd@github.com>
References: <pnKcUK_RQk2lKvUaKsA9Owi9HrGsy3I9Pq75f6Y5yxE=.b91f1923-ce37-4aec-8d0f-ee82c7e8d7dd@github.com>
Message-ID: <A0us_oV21mcBnAmNXC_cr25Mc3z4jzd70WVgecUvhmg=.4973c173-8f41-4e00-9f50-b710f60a1fa3@github.com>

On Mon, 27 Nov 2023 20:17:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Quick doc-only fix.

This pull request has now been integrated.

Changeset: 6871a2ff
Author:    Joe Darcy <darcy at openjdk.org>
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: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>

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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <OGayXcdIM-XLUnHejuwlDR5KRfvoiSvsShJ9Qes3D8M=.d2d608ad-5002-4ab9-9acd-60ff274d410c@github.com>

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

> Time to start making preparations for JDK 23.

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: <FIkaduUczNE0cX9dLjrBN6RoMjDU7QzOkf0_UeZ4nKY=.54c19477-afaa-466a-8f2a-3fae964cc78d@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <thfY3p4Lu4g7iOu2FzPXg1MesH8Jya-svNSS-F6hBF4=.22f20bd0-ecab-4b32-98ff-420fec6d37f1@github.com>
 <tNKEDh6oUjibZRuY8XISdVAvdqPaqjWjcvTr1lV-j-U=.635cda4f-d3e4-43df-8db8-ec6540957477@github.com>
 <REQzEPumwHOV2ZS_0AdfPxnd9vTUAsMFICuSb_eI6h8=.afb9310e-0aa8-47ab-9626-bee45f57f799@github.com>
 <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com>
 <FIkaduUczNE0cX9dLjrBN6RoMjDU7QzOkf0_UeZ4nKY=.54c19477-afaa-466a-8f2a-3fae964cc78d@github.com>
Message-ID: <-Tw35Sh8XjisOJEIbFFVf_xE7asoSucQDV97LsOkWdA=.5f97af1f-86b1-47b2-9d92-752f0b40f6fd@github.com>

On Thu, 2 Nov 2023 17:42:48 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
Message-ID: <E8G8mHRvJDVMHTPXom6Iq15AiBlRkjKmCsqyggeUV4U=.bdd31e24-9733-4d48-a2bb-4ceed5873446@github.com>

On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <l1X_ueavEiK0lZYOr28KiH7kPRl9CfEo3Cx1WGtiiWU=.739f7e16-40ab-458e-97b6-cf9477ef48b6@github.com>

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

> Time to start making preparations for JDK 23.

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: <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
Message-ID: <es-pc9c_NAqRyou4ddwpMiiJ2eQSHC0TLJwL3-Xq5UI=.7a5596c1-a296-451a-b71a-a40b6c732abd@github.com>

On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey <jlaskey at openjdk.org> 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 <asotona at openjdk.org> wrote:

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

On Mon, 6 Nov 2023 15:45:05 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: 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: <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>

On Tue, 28 Nov 2023 10:21:25 GMT, Per Minborg <pminborg at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_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 <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com>
 <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com>
Message-ID: <A61Pqahd28-8nhvyGOi_1sE1y-XcBqTVGZyxdxQDlt4=.5f856d19-a48e-4110-9857-b8bec23eb4b1@github.com>

On Tue, 28 Nov 2023 14:15:48 GMT, Alan Bateman <alanb at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <NyJ10F4CEwr-LCTXIoppPLaFc2aNJ9PkaxJpGqt2IqM=.74261528-807d-4fa3-bffc-935df6c8f5a1@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com>
Message-ID: <tt9syLDXu0BPWlFubRaamhXkpFWsVrV23WjF1-F2_Jo=.9186972d-63f1-4fb6-9054-2283f6191263@github.com>

On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <t-n2b0507T-0zWkfPmNlsC47r6T1OjWmliHi2AUfRek=.b4123e09-cccf-432b-910c-aa7d1a1a2bdb@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:

  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: <E8G8mHRvJDVMHTPXom6Iq15AiBlRkjKmCsqyggeUV4U=.bdd31e24-9733-4d48-a2bb-4ceed5873446@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
 <E8G8mHRvJDVMHTPXom6Iq15AiBlRkjKmCsqyggeUV4U=.bdd31e24-9733-4d48-a2bb-4ceed5873446@github.com>
Message-ID: <V2dsK-C8sKaQIYFs24ONuA07GWvZ5mbA_AEwzbMNY7w=.58904b4f-b093-4099-b20f-21755a9edd85@github.com>

On Mon, 27 Nov 2023 23:46:00 GMT, Joe Darcy <darcy at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com>
Message-ID: <LmKE2fke3iysuEEIJ2LpMZME6btlXz-GlMXsAJkf-mw=.6bc7a653-66e1-481c-8dc6-f0764346b18a@github.com>

On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <NjmOEF0YagdyGMDr8MYQXnI4GgLnDI-WUXmClJsuZE4=.32f1536a-8ec3-4632-b846-d678627520d8@github.com>
References: <NjmOEF0YagdyGMDr8MYQXnI4GgLnDI-WUXmClJsuZE4=.32f1536a-8ec3-4632-b846-d678627520d8@github.com>
Message-ID: <wkAnXRaYrPSKzzxQx06ZJW-9F-clMjhVVjLv948ZQQE=.9ac83484-0319-4cc4-ba1c-775836398fe0@github.com>

On Fri, 10 Nov 2023 13:30:10 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <uQSFw0LAjcKb4d4w4rmGSN_Rz0U7aU1zJ9Wad3Pf6gM=.6199770c-1c57-4cb5-8755-b8ab0589dd78@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 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <wHgX1aLJ1URiIw6C7StYxl08ztOSF6oeoCmHmSRfi3E=.b7a49949-c46e-4b84-83b6-b1f61ac5fdfe@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 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: <tt9syLDXu0BPWlFubRaamhXkpFWsVrV23WjF1-F2_Jo=.9186972d-63f1-4fb6-9054-2283f6191263@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com>
 <tt9syLDXu0BPWlFubRaamhXkpFWsVrV23WjF1-F2_Jo=.9186972d-63f1-4fb6-9054-2283f6191263@github.com>
Message-ID: <auHNi-0ilP5-04jLG8XB7UsN-5QXaocv9fQTLh_BlOQ=.ac308ff3-a21b-4298-9785-2e4d0a26900f@github.com>

On Tue, 28 Nov 2023 14:43:36 GMT, Alan Bateman <alanb at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <v4UysQpZExkuxt_5KvyHuvh1ItnB720UBA5HIV5t2Us=.7d544639-9ab8-4fd2-b113-2460384268df@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 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: <LmKE2fke3iysuEEIJ2LpMZME6btlXz-GlMXsAJkf-mw=.6bc7a653-66e1-481c-8dc6-f0764346b18a@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com>
 <LmKE2fke3iysuEEIJ2LpMZME6btlXz-GlMXsAJkf-mw=.6bc7a653-66e1-481c-8dc6-f0764346b18a@github.com>
Message-ID: <50sgilEAyAxziPJyoaVqfwv9e3xFAXtSo2cTsUCu3lE=.4baff79c-fbe0-4fdd-bd92-921af3e1fb89@github.com>

On Tue, 28 Nov 2023 15:51:37 GMT, Alan Bateman <alanb at openjdk.org> 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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <kISEzPDw7MDNGPbaN8KpQ6CAct0PbUQZQXkGHjf3Ta8=.292b01d5-6929-427c-9040-b04e544d0908@github.com>

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

> Time to start making preparations for JDK 23.

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: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>

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: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
References: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
Message-ID: <sN4nO40l5wyy-hGAtn9-dPnLesHxHjVYBz5_MSzJhVM=.d6dffd54-4a2f-41d3-929c-86e0d01f3c98@github.com>

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

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

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: <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com>
 <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com>
 <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>
Message-ID: <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>

On Tue, 28 Nov 2023 13:03:48 GMT, Adam Sotona <asotona at openjdk.org> 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<Integer, Integer>` 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: <NjmOEF0YagdyGMDr8MYQXnI4GgLnDI-WUXmClJsuZE4=.32f1536a-8ec3-4632-b846-d678627520d8@github.com>
References: <NjmOEF0YagdyGMDr8MYQXnI4GgLnDI-WUXmClJsuZE4=.32f1536a-8ec3-4632-b846-d678627520d8@github.com>
Message-ID: <LZHFiL3QlaAzUtVmb55fdIeaBuus1y5NFSMnZRF6tpc=.057d6772-a82a-4135-801b-77e55ade2905@github.com>

On Fri, 10 Nov 2023 13:30:10 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
References: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
Message-ID: <067AWRziZPR5ffmcHi7Q2SZiiG-VsLfun5-vZd-zeBU=.19bc187c-6a21-4ba7-969c-30c2222f0f6f@github.com>

On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy <darcy at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <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 <jlaskey at openjdk.org> 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: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
References: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
Message-ID: <hxg0wBtiFB80h_JHi9SNoZkcwnmI_qcYwFWIrse1_FI=.ff41c80f-07ae-440a-b738-3c757e3986f5@github.com>

On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy <darcy at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@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 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: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
References: <w0WT17aPgY7OEZEissM5Iwb1W6icjy30YltQ4g4TXB0=.0b4b48a8-b314-447a-9a00-87c967a5b2ca@github.com>
Message-ID: <kGz1yNGNdpYSS07sZDuJLvhZHHfuBn2MrwGJTxPDIpU=.5c0dcbc8-1fd9-42b7-8a62-5fc80a5da23c@github.com>

On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward test update for a new language feature.

This pull request has now been integrated.

Changeset: b68356b2
Author:    Joe Darcy <darcy at openjdk.org>
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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <Sd7laSSs2Jo8sM8oFc5Wj9BVyoLmMVW-o4c3YOcB38M=.8773e247-9f17-4e10-9ca5-9c4f120cec92@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@github.com>
Message-ID: <wKANRSJ7DwP1j4HbB9Ty_qgRWU0792IW71erZAbLbT4=.2aa9fd76-b91e-44f5-98e8-775e5ff606fb@github.com>

On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <V2dsK-C8sKaQIYFs24ONuA07GWvZ5mbA_AEwzbMNY7w=.58904b4f-b093-4099-b20f-21755a9edd85@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <q0Xk_W_Cq4I6vRniZ30X-DKE6u5mbvVRMEfPx1moyxE=.b536cc53-f54e-485d-8fe9-cdf9932901ef@github.com>
 <E8G8mHRvJDVMHTPXom6Iq15AiBlRkjKmCsqyggeUV4U=.bdd31e24-9733-4d48-a2bb-4ceed5873446@github.com>
 <V2dsK-C8sKaQIYFs24ONuA07GWvZ5mbA_AEwzbMNY7w=.58904b4f-b093-4099-b20f-21755a9edd85@github.com>
Message-ID: <h5brh_W87g4oPn0TzcqIMApJ9r75-JFFLLXsco5zrZk=.bf59eb3f-640c-4559-abe4-afe38779335f@github.com>

On Tue, 28 Nov 2023 15:00:43 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@github.com>
Message-ID: <ZVAC6aYkahVRWTv3siKYE3CqEUGvz4pnMT1cSVG05DE=.6de605a0-e14c-4392-9ea4-71877c602c16@github.com>

On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey <jlaskey at openjdk.org> 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: <sN4nO40l5wyy-hGAtn9-dPnLesHxHjVYBz5_MSzJhVM=.d6dffd54-4a2f-41d3-929c-86e0d01f3c98@github.com>
References: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
 <sN4nO40l5wyy-hGAtn9-dPnLesHxHjVYBz5_MSzJhVM=.d6dffd54-4a2f-41d3-929c-86e0d01f3c98@github.com>
Message-ID: <byKGf_wV-Jqy_cVcJJYM1UV9XVeq8x15ooxM5lWStU0=.a736edc3-e1a9-4efc-9193-b2276407d84f@github.com>

On Wed, 29 Nov 2023 03:10:14 GMT, Joe Darcy <darcy at openjdk.org> 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: <byKGf_wV-Jqy_cVcJJYM1UV9XVeq8x15ooxM5lWStU0=.a736edc3-e1a9-4efc-9193-b2276407d84f@github.com>
References: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
 <sN4nO40l5wyy-hGAtn9-dPnLesHxHjVYBz5_MSzJhVM=.d6dffd54-4a2f-41d3-929c-86e0d01f3c98@github.com>
 <byKGf_wV-Jqy_cVcJJYM1UV9XVeq8x15ooxM5lWStU0=.a736edc3-e1a9-4efc-9193-b2276407d84f@github.com>
Message-ID: <OEJQAoE4cjLKrOaI43QMgAIRCri93sHXYf5MPZViusQ=.c309bb8a-b96d-4adc-861b-2fd948a2a91f@github.com>

On Wed, 29 Nov 2023 21:59:22 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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: <iSGtUvRACyNXm1CZwwBVQhd-u5B4-sqH2Z1kTC7IErw=.901d5bea-eaca-4e39-b231-86a0f4e4be83@github.com>

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: <wKANRSJ7DwP1j4HbB9Ty_qgRWU0792IW71erZAbLbT4=.2aa9fd76-b91e-44f5-98e8-775e5ff606fb@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
 <l4MzOlQTk1wjgr_K9_ki-dAp-GLcst7nDd-r8eOtedg=.f7a36fcf-d41b-44c5-8979-b2a5dfd20802@github.com>
 <wKANRSJ7DwP1j4HbB9Ty_qgRWU0792IW71erZAbLbT4=.2aa9fd76-b91e-44f5-98e8-775e5ff606fb@github.com>
Message-ID: <LvLkQHqfsOr1FH8TottsYc6tQ8JI5AWcPbe-6eZJh-A=.56c15c57-3b61-46f8-8a40-c101ed4fb5f5@github.com>

On Wed, 29 Nov 2023 20:07:50 GMT, Joe Darcy <darcy at openjdk.org> 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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <bC4elOsrVyPo-i86HECOXU08QUUKWHTOTfqozOK1O5M=.c4c12c59-a738-4bae-862e-94e1f0f301f4@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:

  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: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
References: <Tt_p-Gw8r2KLztpiB0DUb0eOOgt_OHfJGaF69bwFTAY=.ea85e568-187b-4892-bf54-5f8b0d6ce170@github.com>
Message-ID: <Wod5ZYkKD1h557eEFBgV0Vf2en-Dknl2F4I2hyR-NtU=.61889717-5f10-4830-8f39-b905f8320c90@github.com>

On Wed, 1 Nov 2023 18:56:13 GMT, Jim Laskey <jlaskey at openjdk.org> 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 <jlaskey at openjdk.org>
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: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>

Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".

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

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

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: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
Message-ID: <GG8vHiLmpF27IH7i1FsCeVMGVSApXD1Ie3gkc2w3zLM=.b4baf3d5-652a-4fdb-92f6-974e53bd3d4b@github.com>

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

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

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: <iSGtUvRACyNXm1CZwwBVQhd-u5B4-sqH2Z1kTC7IErw=.901d5bea-eaca-4e39-b231-86a0f4e4be83@github.com>
References: <iSGtUvRACyNXm1CZwwBVQhd-u5B4-sqH2Z1kTC7IErw=.901d5bea-eaca-4e39-b231-86a0f4e4be83@github.com>
Message-ID: <qFR2w_d2V3lD5kXRFsBAPH6eUYwthFyz_dNB0p9kszs=.33362aa4-79d2-41a7-b314-68848ede0a63@github.com>

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

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

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: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
Message-ID: <WCqF8rPQnqAJ2GbPIDQXJTTpcnHClOTSXdcG3WlVbkI=.bbea1f2e-ed62-433c-8a20-63de09bafa14@github.com>

On Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy <darcy at openjdk.org> 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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <KbwFGTaxdf64FHbE6RjNBBp-uhKoIKiaUAJuNXTDKDM=.1818c82b-839a-42e8-ba0c-5fdfe9555fcd@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <WCqF8rPQnqAJ2GbPIDQXJTTpcnHClOTSXdcG3WlVbkI=.bbea1f2e-ed62-433c-8a20-63de09bafa14@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <WCqF8rPQnqAJ2GbPIDQXJTTpcnHClOTSXdcG3WlVbkI=.bbea1f2e-ed62-433c-8a20-63de09bafa14@github.com>
Message-ID: <epnNqHl_psXmZlK2gQbRVx9zK4oero1RvARgkhbE6e0=.1c9b8ddf-f8fe-4147-9cac-a4585ed7ff58@github.com>

On Thu, 30 Nov 2023 20:31:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

Thanks for the input @shipilev ; I'm looking into options to amend this change later in JDK 22.

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

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: <KbwFGTaxdf64FHbE6RjNBBp-uhKoIKiaUAJuNXTDKDM=.1818c82b-839a-42e8-ba0c-5fdfe9555fcd@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <KbwFGTaxdf64FHbE6RjNBBp-uhKoIKiaUAJuNXTDKDM=.1818c82b-839a-42e8-ba0c-5fdfe9555fcd@github.com>
Message-ID: <biOr7L2Vo8rLlJ08dXBN8fChsVXYMqjhkeieYmd7UUo=.86ec48fa-c9f7-4871-b8cc-a582aa8c1c3b@github.com>

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

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>

> Time to start making preparations for JDK 23.

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

  Update 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