From jlaskey at openjdk.org  Mon May  1 12:10:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 1 May 2023 12:10:55 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <FPr8Cf00YVgejbm80QLSH1qAmPHoM-RCJcS4IxXPAC4=.8eada591-9902-4c1d-9260-a0637c2407db@github.com>
 <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com>
Message-ID: <NL3FV21KmTjIP3oQAvy-XDPtz3dyFKG5yPHmvW__pYE=.690ba017-641c-4e0b-af15-0c8ae94371da@github.com>

On Thu, 27 Apr 2023 18:00:38 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 590:
>> 
>>> 588:         CHECK_EXCEPTION_NULL_LEAVE(mainID);
>>> 589:         (*env)->CallVoidMethod(env, mainObject, mainID);
>>> 590:         break;
>> 
>> This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that.
>
> Good idea. If @hidden doesn't work then we can eat the trace entries.

Many dependencies (ex. JDI) on main being the first frame. Will set up a separate RFE witch should include using the LauncherHelper in the source code launcher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1181532559

From jlaskey at openjdk.org  Mon May  1 13:06:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 1 May 2023 13:06:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v8]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Anonymous main classes renamed to unnamed classes
 - Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/a09a0a1b..ff7cd4c7

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

  Stats: 314 lines in 14 files changed: 151 ins; 135 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From vromero at openjdk.org  Mon May  1 13:39:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 May 2023 13:39:29 GMT
Subject: RFR: 8305672: Surprising definite assignment error after
 JDK-8043179 [v3]
In-Reply-To: <pX0mlY4R5o1nPHwphztwkEEYDw-DCQFskk-7HVOa9do=.93a0a881-1c83-462a-8d07-fa732b193ead@github.com>
References: <rltCSwU6EsmzoWwqlU8Smx92_Chy2q9KRbtB5Y9UGDE=.b6e65b7a-1f3e-46b6-aaee-88cbf12430d9@github.com>
 <pvMEioBqQ9YnAkbu_Wopyp76dtXr4zefDVxK4wqkGiY=.e99f87a4-c08a-4e67-82c6-7372568f4b4c@github.com>
 <pX0mlY4R5o1nPHwphztwkEEYDw-DCQFskk-7HVOa9do=.93a0a881-1c83-462a-8d07-fa732b193ead@github.com>
Message-ID: <_at5mqPt_PU0kSLRmgTjpKu9Ghn9qPFEn6Rhe_yuYrM=.528b271f-f14a-467a-a8f2-e8f9744fb9b6@github.com>

On Fri, 28 Apr 2023 17:12:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8305672
>>  - Merge branch 'master' into JDK-8305672
>>  - Fix failure of visitLambda() to save & restore uninitsTry bits.
>
> the fix looks good to me, running regression tests now to make sure nothing breaks, will approve if all green

> Thanks for the review @vicente-romero-oracle !
> 
> /integrate

sure thanks @kevinrushforth and @neil too

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

PR Comment: https://git.openjdk.org/jdk/pull/13366#issuecomment-1529711388

From acobbs at openjdk.org  Mon May  1 13:39:53 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 1 May 2023 13:39:53 GMT
Subject: Integrated: 8305672: Surprising definite assignment error after
 JDK-8043179
In-Reply-To: <rltCSwU6EsmzoWwqlU8Smx92_Chy2q9KRbtB5Y9UGDE=.b6e65b7a-1f3e-46b6-aaee-88cbf12430d9@github.com>
References: <rltCSwU6EsmzoWwqlU8Smx92_Chy2q9KRbtB5Y9UGDE=.b6e65b7a-1f3e-46b6-aaee-88cbf12430d9@github.com>
Message-ID: <xbGKGMYjoODaPlHRtSFkhB2XRLHMVckqkdyJkf9z5ZE=.c4e489c8-4fbe-41d7-9556-fe5a4d362ac2@github.com>

On Wed, 5 Apr 2023 22:42:58 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes.
> 
> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error.
> 
> This patch fixes that by adding the necessary save & restore logic.

This pull request has now been integrated.

Changeset: d437c61f
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d437c61f5b77793606d73960eeaf98a091f14f6a
Stats:     49 lines in 2 files changed: 49 ins; 0 del; 0 mod

8305672: Surprising definite assignment error after JDK-8043179

Reviewed-by: kcr, vromero

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

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

From vromero at openjdk.org  Mon May  1 16:48:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 May 2023 16:48:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v8]
In-Reply-To: <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
Message-ID: <IERXDrGo8Dcxp3H94x2kveD9ucGDJqiiTpfIQ5K4dT8=.313430b1-625e-4812-8942-30f4ef2d1693@github.com>

On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ternary operator
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

good to see this one done, thanks to all!

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

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1529923659

From vromero at openjdk.org  Mon May  1 16:48:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 May 2023 16:48:55 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v8]
In-Reply-To: <9zxTtvwvKntdl1Cv01PD6OXwMNYInDfGlusMsVX1er8=.d6a40924-c18a-4263-9372-dbff6fc98a46@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
 <9zxTtvwvKntdl1Cv01PD6OXwMNYInDfGlusMsVX1er8=.d6a40924-c18a-4263-9372-dbff6fc98a46@github.com>
Message-ID: <mCldJ1Ycbxdq_OJktolZr8V2KaDjDSarBsW02t1Rqz4=.610889f6-1c06-43ab-94d5-4fcd25e2d5c1@github.com>

On Sun, 30 Apr 2023 08:56:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Haha, glad to have been of help
> 
> Now, if only someone would also take a look at my javac patch for the JNI header generator... :(

what's the PR for that one?

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

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1529924116

From jwaters at openjdk.org  Mon May  1 16:48:56 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 1 May 2023 16:48:56 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v8]
In-Reply-To: <mCldJ1Ycbxdq_OJktolZr8V2KaDjDSarBsW02t1Rqz4=.610889f6-1c06-43ab-94d5-4fcd25e2d5c1@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
 <9zxTtvwvKntdl1Cv01PD6OXwMNYInDfGlusMsVX1er8=.d6a40924-c18a-4263-9372-dbff6fc98a46@github.com>
 <mCldJ1Ycbxdq_OJktolZr8V2KaDjDSarBsW02t1Rqz4=.610889f6-1c06-43ab-94d5-4fcd25e2d5c1@github.com>
Message-ID: <83vlAP86eh-7qkBGECeXvb2Sq8t4JdmE3w5ECtJpQK8=.0808b65a-26f4-45f5-955f-0fd72c260d1e@github.com>

On Mon, 1 May 2023 16:30:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > Haha, glad to have been of help
> > Now, if only someone would also take a look at my javac patch for the JNI header generator... :(
> 
> what's the PR for that one?

Ah, sorry for the trouble, I was mildly joking for that one, but the corresponding PR is https://github.com/openjdk/jdk/pull/13457

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

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1529932401

From vromero at openjdk.org  Mon May  1 17:33:59 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 May 2023 17:33:59 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v8]
In-Reply-To: <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
Message-ID: <ATstMYEM5Lzhhu10O2dVDSzwOpPYUxoXIgOZS-4rEf4=.e689f5c7-0829-4b93-b964-b34e6cf4018e@github.com>

On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ternary operator
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

> > > Haha, glad to have been of help
> > > Now, if only someone would also take a look at my javac patch for the JNI header generator... :(
> > 
> > 
> > what's the PR for that one?
> 
> Ah, sorry for the trouble, I was mildly joking for that one, but the corresponding PR is #13457

I see, it seems like it is already being looked at

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

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1529968082

From abimpoudis at openjdk.org  Mon May  1 22:29:27 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:29:27 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v8]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <pHIzCdIv1Df6qXfNBnxDB0WlFhCUI4J-vXvPhxAeg2Q=.0128fac3-0229-4a8f-9441-0b11ce15734a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Address comments around JavacParser (remove identOrFlagUnderscore)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/e39dd6dd..47d738bb

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

  Stats: 39 lines in 1 file changed: 12 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Mon May  1 22:29:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:29:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <FtwLB9zDe9eY-EiqQRoZQQ0tuqmRpBtcUTpsqZD6enY=.bb123da2-db8a-4a44-92d1-1a61eba54205@github.com>

On Fri, 28 Apr 2023 08:56:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 839:
> 
>> 837:     }
>> 838: 
>> 839:     private UnnamedDetails identOrFlagUnderscore(JCModifiers mods) {
> 
> I'm not 100% sure this is required - the main use seems to be in `variableDeclarator` - but in that method you already have a token to look at, and a set of modifiers that you can augment - so why not just doing everything in that method (instead of preprocessing it?)

Good point. That was an artifact of code evolution. Everything is integrated in `variableDeclarator` now.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3555:
> 
>> 3553:      */
>> 3554:     JCVariableDecl variableDeclarator(JCModifiers mods, JCExpression type, boolean reqInit, Comment dc, boolean localDecl) {
>> 3555:         UnnamedDetails result = identOrFlagUnderscore(mods);
> 
> Why do we need to get the "unnamed details" here, instead of letting the code flow to `variableDeclaratorRest` and do it there?

Indeed. I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181937000
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181937191

From abimpoudis at openjdk.org  Mon May  1 22:32:31 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:32:31 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>

On Fri, 28 Apr 2023 09:07:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:
> 
>> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
>> 1776:                             }
>> 1777:                         } else if (guard != null) {
> 
> I guess this is caused by something like:
> 
> case _ when ...
> 
> If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.

Actually this is for the case where we have `case A(_), B(C _) when ... `. In that case we are sure that the only scope we can use is the switch environment (since no bindings are introduced). Hm, I don't see another way of refactoring this without depending on `labels.tail.isEmpty()`

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:
> 
>> 824:                 //type test pattern:
>> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
>> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));
> 
> Do you think we can delegate to `variableDeclarator` here?

The behavior I observe is that `variableDeclarator` does not behave well when we have a `var` instead of a type in a type pattern. `variableDeclarator` is well suited for variable declarations but not for type patterns. But I can investigate further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938984
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938402

From jjg at openjdk.org  Mon May  1 23:03:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 1 May 2023 23:03:10 GMT
Subject: RFR: JDK-8307123: Fix deprecation warnings in DPrinter
Message-ID: <6rSeWRzbI8BZ33d400uerrSxitH0s2qe0irKFzw6CRc=.e4629a3a-6f9a-4a70-a5e1-ad884a7dab2e@github.com>

Please review a trivial test clean to fix some deprecation warnings in the test/langtools DPrinter class.

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

Commit messages:
 - JDK-8307123: Fix deprecation warnings in DPrinter

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

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

From vromero at openjdk.org  Tue May  2 03:23:15 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 2 May 2023 03:23:15 GMT
Subject: RFR: JDK-8307123: Fix deprecation warnings in DPrinter
In-Reply-To: <6rSeWRzbI8BZ33d400uerrSxitH0s2qe0irKFzw6CRc=.e4629a3a-6f9a-4a70-a5e1-ad884a7dab2e@github.com>
References: <6rSeWRzbI8BZ33d400uerrSxitH0s2qe0irKFzw6CRc=.e4629a3a-6f9a-4a70-a5e1-ad884a7dab2e@github.com>
Message-ID: <BdBkeENFeWTB2jCn9ax5jcbnRUnB_AjgcpxKZZPKz-I=.782f779a-c3b4-42c9-a816-5d7e5091513e@github.com>

On Mon, 1 May 2023 22:56:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial test clean to fix some deprecation warnings in the test/langtools DPrinter class.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13747#pullrequestreview-1408338632

From jwaters at openjdk.org  Tue May  2 07:56:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 2 May 2023 07:56:38 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v8]
In-Reply-To: <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <R37KmH7gJTxkaQnVnquXpFaPx8ivYEK1-TIOXzbexIE=.31a2d5fd-b355-40b2-82ee-07039b6d3a8b@github.com>
Message-ID: <RFrqAi8Tc5RENRZD0PDd3-0hmpPqfXEjGlsZ2jr238M=.934370ad-8f23-4c1a-a35f-d2a4edc34bb3@github.com>

On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ternary operator
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

It was yeah, Jan hasn't come back to reviewing it in quite a while unfortunately :/

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

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1531037537

From abimpoudis at openjdk.org  Tue May  2 08:20:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 08:20:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <xt8H4lrxPjRJhcOEnGU65EcRJ3NRtWdsSjljmRyItM4=.d495fcbc-a254-45ca-a918-7273d0e34978@github.com>

On Fri, 28 Apr 2023 08:59:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3660:
> 
>> 3658:         int pos = token.pos;
>> 3659:         Name name;
>> 3660:         if (allowThisIdent ||
> 
> I note that now the error re. underscore on lambda is no longer given even if preview features are disabled. But I guess that's ok. (instead you will probably get an error that unnamed parameters are a preview feature)

Yes, indeed.


~/dev/jdk unnamed !1 > javac Unnamed.java
Unnamed.java:61: error: unnamed variables are a preview feature and are disabled by default.
        TwoParams p1 = (_, _) -> {};
                        ^
  (use --enable-preview to enable unnamed variables)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182230562

From abimpoudis at openjdk.org  Tue May  2 08:27:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 08:27:20 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <B7qDd8v-AsvIyMeq2UPHLDb848br6nlRGXhfxWp1PXQ=.63596e87-fca8-4e97-b3b5-136d03687260@github.com>

On Fri, 28 Apr 2023 09:20:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746:
> 
>> 744: 
>> 745:         sealed interface PatternDescription {
>> 746:             public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) {
> 
> Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription.

@lahodaj WDYT? Looks like it can be easily refactored and it is used only in one place (apart from the recursive call). I can refactor it in this PR or u can do it in #13074.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182237560

From abimpoudis at openjdk.org  Tue May  2 09:49:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 09:49:38 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v9]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Address comments around JavacParser (reuse variableDeclaratorRest in parsePattern)
 - Add new lines and revise comment in Unnamed.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/47d738bb..3d83fa14

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

  Stats: 49 lines in 4 files changed: 8 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Tue May  2 09:49:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 09:49:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
 <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
Message-ID: <u0__tyRjxt0bQNcwXuKQV4mimQ096EAk0HqdFKuFyLE=.b68eba17-ecbb-4a4f-a09f-420699fd62b5@github.com>

On Mon, 1 May 2023 22:28:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:
>> 
>>> 824:                 //type test pattern:
>>> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
>>> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));
>> 
>> Do you think we can delegate to `variableDeclarator` here?
>
> The behavior I observe is that `variableDeclarator` does not behave well when we have a `var` instead of a type in a type pattern. `variableDeclarator` is well suited for variable declarations but not for type patterns. But I can investigate further.

What about reusing `variableDeclaratorRest`? 

https://github.com/openjdk/jdk/pull/13528/commits/3d83fa14ae26981d5b6fc75faa0d3ba9336952b1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182329080

From cushon at openjdk.org  Tue May  2 15:19:32 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 2 May 2023 15:19:32 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v6]
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <IMinNsE_y46ijCWJBDY7asLzrfNlcnnPVXnu7LsvZB4=.51fd50c9-5073-4317-8be8-82b72273b6ed@github.com>

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

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 six additional commits since the last revision:

 - Merge branch 'master' into JDK-8303784
 - Use Feature enum for version checks
 - Add a test case with no --release flag
 - Make fix contingent on --release 14
   
   based on discussion in CSR.
 - Move test under `test/langtools/tools/javac/annotations/typeAnnotations`
 - 8303784: no- at Target annotations should be applicable to type parameter declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12914/files
  - new: https://git.openjdk.org/jdk/pull/12914/files/749af3cc..6b03a477

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

  Stats: 495182 lines in 4948 files changed: 389506 ins; 65649 del; 40027 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12914/head:pull/12914

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

From jjg at openjdk.org  Tue May  2 16:57:23 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 2 May 2023 16:57:23 GMT
Subject: Integrated: JDK-8307123: Fix deprecation warnings in DPrinter
In-Reply-To: <6rSeWRzbI8BZ33d400uerrSxitH0s2qe0irKFzw6CRc=.e4629a3a-6f9a-4a70-a5e1-ad884a7dab2e@github.com>
References: <6rSeWRzbI8BZ33d400uerrSxitH0s2qe0irKFzw6CRc=.e4629a3a-6f9a-4a70-a5e1-ad884a7dab2e@github.com>
Message-ID: <1Owalr1EgZuLqk5pR0_IgeOVgTm_QN1gnZVDMM2g2mw=.3a9a6080-553e-4bab-82a6-d52eb4dc0c98@github.com>

On Mon, 1 May 2023 22:56:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial test clean to fix some deprecation warnings in the test/langtools DPrinter class.

This pull request has now been integrated.

Changeset: b76f320e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b76f320e76f0fb58c598fdd7a5937f1b5bb1de15
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8307123: Fix deprecation warnings in DPrinter

Reviewed-by: vromero

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

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

From cushon at openjdk.org  Tue May  2 18:22:32 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 2 May 2023 18:22:32 GMT
Subject: Integrated: 8303784: no-@Target annotations should be applicable to
 type parameter declarations
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <Ari7ja3WSinU1BF2INrLtQHqGv10cU46CW6sHh8namI=.61b7786e-d75d-4220-a3bd-13c6855bfe23@github.com>

On Wed, 8 Mar 2023 00:06:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

This pull request has now been integrated.

Changeset: 8c106b0c
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c106b0c8e4562a44ecd1e069c0911acfc428ecf
Stats:     49 lines in 4 files changed: 48 ins; 0 del; 1 mod

8303784: no- at Target annotations should be applicable to type parameter declarations

Reviewed-by: vromero

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

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

From abimpoudis at openjdk.org  Tue May  2 19:27:12 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 19:27:12 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v10]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <IpUNY7S3XYB4Z2GmnMj_jZzw7Tt4yakwDlPFhetEmIE=.f2db4c6a-d920-4afb-8d58-6d669bb5e7b8@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Remove flag
  
  - Fixes unnamed errors
  - Fixes missing test in TestUnnamedVariableElement
  - Removes scope elements from erroneous source file tests in TestGetScopeResult (names.empty is used to signify error when we mix and match implicit and explicit parameters in lambdas)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/3d83fa14..5c9314d3

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

  Stats: 29 lines in 9 files changed: 8 ins; 11 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Tue May  2 19:27:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 19:27:16 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v9]
In-Reply-To: <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>
Message-ID: <eU-tJk0lkGw5x8k28sWCcHPfKbgg1tVPYkwhHLIoYIE=.074f124e-ba76-4c80-8bfb-90b495216833@github.com>

On Tue, 2 May 2023 09:49:38 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address comments around JavacParser (reuse variableDeclaratorRest in parsePattern)
>  - Add new lines and revise comment in Unnamed.java

@mcimadamore 
@vicente-romero-oracle 
Flag removed in https://github.com/openjdk/jdk/pull/13528/commits/5c9314d3f39dc0e3084c80b7f2ff06e70a363425

re-requesting review ? 

cc-ing @lahodaj

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1532022476

From abimpoudis at openjdk.org  Tue May  2 22:34:15 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 22:34:15 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var
In-Reply-To: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
Message-ID: <h_p3NBLqsCwqMjYAP6W2Ev2WHcDAxc9CGsJaJuZUl8M=.ae2d3c67-7f35-46b8-9ebe-7fefd78c185b@github.com>

On Tue, 4 Apr 2023 17:34:27 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
> 
> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`

Small fix, looking for a reviewer ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13331#issuecomment-1532237887

From jjg at openjdk.org  Wed May  3 00:00:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 3 May 2023 00:00:13 GMT
Subject: RFR: JDK-8068925: Add @Override in javax.tools classes
Message-ID: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>

Please review a simple update to add `@Override` annotations where appropriate in the `javax.tools` API, and one other minor opportunistic cleanup to use an `instanceof` pattern.

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

Commit messages:
 - JDK-8068925: Add @Override in javax.tools classes

Changes: https://git.openjdk.org/jdk/pull/13766/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13766&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8068925
  Stats: 21 lines in 4 files changed: 17 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13766/head:pull/13766

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

From darcy at openjdk.org  Wed May  3 00:40:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 May 2023 00:40:16 GMT
Subject: RFR: JDK-8068925: Add @Override in javax.tools classes
In-Reply-To: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
References: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
Message-ID: <0dOq3gH30pL3b0SlirauHQKb0m7dxKhRAko_n2bxDd4=.c99dfe0c-e033-4802-be2c-75ec067a5856@github.com>

On Tue, 2 May 2023 23:53:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update to add `@Override` annotations where appropriate in the `javax.tools` API, and one other minor opportunistic cleanup to use an `instanceof` pattern.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13766#pullrequestreview-1410044906

From acobbs at openjdk.org  Wed May  3 01:37:19 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 3 May 2023 01:37:19 GMT
Subject: RFR: 8278856: javac documentation does not mention use of Manifest
 class-path attribute
In-Reply-To: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
References: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
Message-ID: <6gqOqSCzzzxD0yCWh2lId3KzuEi9yL7ljb_2H3GOR98=.68fcd605-0e49-4da6-9026-602d330f842e@github.com>

On Tue, 4 Apr 2023 17:45:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> JAR files appearing in `--class-path` are implicitly scanned for manifest `Class-Path` attributes, but this behavior is not documented.
> 
> This patch adds a blurb to the `javac(1)` man page.

/?

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

PR Comment: https://git.openjdk.org/jdk/pull/13332#issuecomment-1532350855

From iris at openjdk.org  Wed May  3 03:57:13 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 May 2023 03:57:13 GMT
Subject: RFR: JDK-8068925: Add @Override in javax.tools classes
In-Reply-To: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
References: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
Message-ID: <N8GScsTWppGxWw-L0HyVk7QMJDttqfZk2LUC-01PljE=.6140052c-52cf-4431-a7eb-ba048d774eaf@github.com>

On Tue, 2 May 2023 23:53:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update to add `@Override` annotations where appropriate in the `javax.tools` API, and one other minor opportunistic cleanup to use an `instanceof` pattern.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13766#pullrequestreview-1410153726

From abimpoudis at openjdk.org  Wed May  3 14:29:23 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 May 2023 14:29:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v11]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <Ho2Jw4chf6MFi3CZimytOd7KcqRimKecY3GsoRxc-p0=.f5b3d099-d073-4a7e-b3ac-df4b13636416@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Add guard test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/5c9314d3..e95465ed

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

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

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

From abimpoudis at openjdk.org  Wed May  3 15:41:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 May 2023 15:41:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <jwyMS6mf5hWnF03GAi-kSZpkqvKE-TX8V8MSEvrFslg=.c4501fe4-db20-4da1-a298-3a4851d9ffd8@github.com>

On Fri, 28 Apr 2023 09:16:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295:
> 
>> 293:                 : tree.vartype.type;
>> 294:         Name name;
>> 295:         if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && (tree.mods.flags & UNNAMED) != 0) {
> 
> Not 100% sure what this code does. E.g. shouldn't we just set the name of the variable as the name stored in the tree? It seems more economical if we could just set in the parser the name as empty (if preview features are enabled etc.) - and then all these special cases can disappear. After all, you still have the flag (and even then, do we need a flag? Can't we just see whether the name is empty to see that it's unnamed?)

This is still needed because we want to have a different name for the Tree API (_) and the symbol (empty).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1183863324

From jjg at openjdk.org  Wed May  3 17:35:21 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 3 May 2023 17:35:21 GMT
Subject: Integrated: JDK-8068925: Add @Override in javax.tools classes
In-Reply-To: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
References: <fiNIYaKT92HikM2BPHCL-o66hsuGWDJjbqpZcK9dHVA=.a91dbd64-e0b7-4f71-9ed3-ce64a3ac8e18@github.com>
Message-ID: <au22_yBw0IXPpeQy4ZCKKXrZk7MDfv49uARFt8_Bj4s=.5307a9a2-d59b-4958-b65b-ba88a5aab909@github.com>

On Tue, 2 May 2023 23:53:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update to add `@Override` annotations where appropriate in the `javax.tools` API, and one other minor opportunistic cleanup to use an `instanceof` pattern.

This pull request has now been integrated.

Changeset: 3930709a
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3930709af40c2524622f379e16b90a0226bedf2a
Stats:     21 lines in 4 files changed: 17 ins; 2 del; 2 mod

8068925: Add @Override in javax.tools classes

Reviewed-by: darcy, iris

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

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

From abimpoudis at openjdk.org  Thu May  4 15:08:21 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 15:08:21 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  8307444: java.lang.AssertionError when using unnamed patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/e95465ed..12ce9e19

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

  Stats: 18 lines in 2 files changed: 15 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From mcimadamore at openjdk.org  Thu May  4 17:23:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 17:23:26 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
Message-ID: <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>

On Thu, 4 May 2023 15:08:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307444: java.lang.AssertionError when using unnamed patterns

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4165:

> 4163:         tree.type = tree.var.type = type;
> 4164:         Name name = tree.var.name;
> 4165:         if (name == names.underscore) name = names.empty;

Why isn't the parser doing this?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295:

> 293:                 : tree.vartype.type;
> 294:         Name name = tree.name;
> 295:         if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && name == names.underscore) name = names.empty;

Same, I believe the parser should have set the right name on this

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:

> 3589:                 }
> 3590:             }
> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));

I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.

Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185294832
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185295283
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185299587

From abimpoudis at openjdk.org  Thu May  4 17:48:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 17:48:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/12ce9e19..ffae4e0e

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

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

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

From vromero at openjdk.org  Thu May  4 17:51:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 17:51:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
Message-ID: <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>

On Thu, 4 May 2023 17:20:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8307444: java.lang.AssertionError when using unnamed patterns
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:
> 
>> 3589:                 }
>> 3590:             }
>> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));
> 
> I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.
> 
> Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.

yep I agree with this, the parser should set the right name as soon as it sees a `_`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185327903

From abimpoudis at openjdk.org  Thu May  4 18:23:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 18:23:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
Message-ID: <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>

On Thu, 4 May 2023 17:48:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:
>> 
>>> 3589:                 }
>>> 3590:             }
>>> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));
>> 
>> I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.
>> 
>> Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.
>
> yep I agree with this, the parser should set the right name as soon as it sees a `_`

We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185358285

From vromero at openjdk.org  Thu May  4 18:55:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 18:55:21 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java line 54:

> 52: 
> 53:     /**
> 54:      * Returns the name of the variable being declared or `_` if the variable

I guess if we go full for the empty name then this will need to change too

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 69:

> 67: import com.sun.tools.javac.util.Names;
> 68: 
> 69: import java.util.*;

nit: I think we prefer not using star imports, this was probably done by the IDE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185336672
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185393785

From vromero at openjdk.org  Thu May  4 19:33:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 19:33:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <RJpTnXC2Mia4Nmj9GIF0jg22cpjKXNi300Y3LOP-FyI=.a0d946c1-e6fa-4ade-9149-5c6d440a020b@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 535:

> 533:                 if (clearedPatterns.size() > 1) {
> 534:                     validCaseLabelList = clearedPatterns.stream().allMatch(cP -> cP.hasTag(Tag.PATTERNCASELABEL));
> 535:                 } else validCaseLabelList = clearedPatterns.size() == 1 && clearedPatterns.head.hasTag(Tag.PATTERNCASELABEL);

style: I would use `{}` for the code in the `else` branch here, same way as it has been done for the `then` branch. Also in the `else` branch isn't the `clearedPatterns.size() == 1` condition always true?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185430664

From darcy at openjdk.org  Thu May  4 20:01:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 20:01:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
Message-ID: <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>

On Thu, 4 May 2023 18:20:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> yep I agree with this, the parser should set the right name as soon as it sees a `_`
>
> We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?

> 

In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185457942

From vromero at openjdk.org  Thu May  4 20:07:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 20:07:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:

> 86:  * or deletion without notice.</b></p>
> 87:  */
> 88: @SuppressWarnings("preview")

isn't it better to apply the annotation to the method below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185463034

From darcy at openjdk.org  Thu May  4 20:50:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 20:50:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:

> 436:     }
> 437: 
> 438:     public boolean isUnnamed() {

Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185497754

From mcimadamore at openjdk.org  Thu May  4 20:53:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 20:53:32 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695

From james.laskey at oracle.com  Thu May  4 20:56:22 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 4 May 2023 20:56:22 +0000
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>
Message-ID: <C0A39153-4582-43D4-92BF-550D3FC9FF49@oracle.com>

I suppose that?s a possibility. But is it more informative to have the class print with the synthetic flag?

?

> On May 4, 2023, at 5:54 PM, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
> 
> ?On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>>> Add flexible main methods and anonymous main classes to the Java language.
>> 
>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>> - Anonymous main classes renamed to unnamed classes
>> - Add test
> 
> The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ?
> 
> -------------
> 
> Marked as reviewed by mcimadamore (Reviewer).
> 
> PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695

From darcy at openjdk.org  Thu May  4 21:00:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:00:25 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <HLMuveBJGifEIxiIwoQ_cdiOJT_1dMF1SewbtfuM7ns=.8a76f8d8-2a6e-486d-a569-f73f760f030d@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java line 114:

> 112:      */
> 113:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED, reflective = true)
> 114:     default boolean isUnnamed() { return false; }

Looking at the various sources more closely, I'll revise my previous guidance and recommend the default method be defined as:
return getSimpleName().isEmpty()
which would also avoid the strict need to override the method in Symbol.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185505824

From darcy at openjdk.org  Thu May  4 21:06:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:06:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <gIiLCKY63xXvwZQYsfRf5_1GLOffHamTSAjdDv_c5MY=.449e53ae-5769-46f4-9c7a-af6d65073ab0@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 724:

> 722:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED, reflective = true)
> 723:     default boolean isUnnamed(Element element) {
> 724:         return false;

Analogous suggestion to switch to "return element.getSimpleName().isEmpty();"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185512905

From jjg at openjdk.org  Thu May  4 21:29:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 4 May 2023 21:29:25 GMT
Subject: RFR: 8278856: javac documentation does not mention use of Manifest
 class-path attribute
In-Reply-To: <6gqOqSCzzzxD0yCWh2lId3KzuEi9yL7ljb_2H3GOR98=.68fcd605-0e49-4da6-9026-602d330f842e@github.com>
References: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
 <6gqOqSCzzzxD0yCWh2lId3KzuEi9yL7ljb_2H3GOR98=.68fcd605-0e49-4da6-9026-602d330f842e@github.com>
Message-ID: <NERgvVHGah0sQsZPpcVOHHkAtETBzeG-L90LvS9U4Bc=.1b6b47e3-3d73-481a-8c6e-f9c675445897@github.com>

On Wed, 3 May 2023 01:34:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> JAR files appearing in `--class-path` are implicitly scanned for manifest `Class-Path` attributes, but this behavior is not documented.
>> 
>> This patch adds a blurb to the `javac(1)` man page.
>
> /?

@archiecobbs 
Regrettably, this is *not* the way/place to document this.

The true source of the man page is upstream in an internal repo. The `.1` file here is a derived file that will get overridden.
See this hint at the top of the file:

> ." Automatically generated by Pandoc 2.19.2

The edit needs to be applied by an Oracle engineer with access to the upstream source. (Sorry about this.)

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

PR Comment: https://git.openjdk.org/jdk/pull/13332#issuecomment-1535433900

From acobbs at openjdk.org  Thu May  4 21:40:21 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 May 2023 21:40:21 GMT
Subject: RFR: 8278856: javac documentation does not mention use of Manifest
 class-path attribute
In-Reply-To: <NERgvVHGah0sQsZPpcVOHHkAtETBzeG-L90LvS9U4Bc=.1b6b47e3-3d73-481a-8c6e-f9c675445897@github.com>
References: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
 <6gqOqSCzzzxD0yCWh2lId3KzuEi9yL7ljb_2H3GOR98=.68fcd605-0e49-4da6-9026-602d330f842e@github.com>
 <NERgvVHGah0sQsZPpcVOHHkAtETBzeG-L90LvS9U4Bc=.1b6b47e3-3d73-481a-8c6e-f9c675445897@github.com>
Message-ID: <aKpoYFTccEukBL3QBRBhKAvKR-D6y_nYJ6mPS7PoWjs=.18dad293-7a74-4b99-944f-ca6d04a7772d@github.com>

On Thu, 4 May 2023 21:24:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The true source of the man page is upstream in an internal repo.

Ah, got it - thanks for the heads-up. Not my problem then :)

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

PR Comment: https://git.openjdk.org/jdk/pull/13332#issuecomment-1535444786

From acobbs at openjdk.org  Thu May  4 21:40:23 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 May 2023 21:40:23 GMT
Subject: Withdrawn: 8278856: javac documentation does not mention use of
 Manifest class-path attribute
In-Reply-To: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
References: <dflxLfV5A5zmo6m7u5N59fxJNXie7hpvsdtCgNTFuEk=.22301f82-1423-4560-9084-40f1cd110c1a@github.com>
Message-ID: <a3YmQ-2aQTh2umsKLc78gSeGg2Ju1DO2bA_3srcU_z4=.c73d767e-e32d-4a20-81ec-f2b3aaf2dc7f@github.com>

On Tue, 4 Apr 2023 17:45:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> JAR files appearing in `--class-path` are implicitly scanned for manifest `Class-Path` attributes, but this behavior is not documented.
> 
> This patch adds a blurb to the `javac(1)` man page.

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Thu May  4 21:43:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:43:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
Message-ID: <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>

On Thu, 4 May 2023 19:58:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?
>
>> 
> 
> In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.

> 

For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.

I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185544462

From vromero at openjdk.org  Thu May  4 22:04:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 22:04:20 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <4dcjzbL_QNyX1L-n4dCOlV6ZvWQBsnrlqbHhDEku8jg=.0c82bcea-6c43-45c5-9e4b-f64aa914bc59@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java line 496:

> 494:     @DefinedBy(Api.COMPILER_TREE)
> 495:     public JCTree visitAnyPattern(AnyPatternTree node, P p) {
> 496:         JCBindingPattern t = (JCBindingPattern) node;

not sure this is correct, are we returning a JCBindingPattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185555175

From vromero at openjdk.org  Thu May  4 22:08:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 22:08:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <zCPYJ9cNf4ubrT0fdfmGagOFoZsqOQUNMuBViqrk3kA=.4c0b09f7-62f0-48e4-8570-772f88c302d2@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

test/langtools/tools/javac/patterns/Unnamed.java line 4:

> 2: 
> 3: /**
> 4:  * @test /nodynamiccopyright/

there is no golden file for this test so full copyright will be needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185559074

From abimpoudis at openjdk.org  Thu May  4 23:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 23:28:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v14]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  8307482: Compiler should accept var _ in nested patterns in switch case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/ffae4e0e..888297ef

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

  Stats: 49 lines in 4 files changed: 35 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Thu May  4 23:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 23:28:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
 <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
Message-ID: <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>

On Thu, 4 May 2023 21:40:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> 
>> 
>> In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.
>
>> 
> 
> For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.
> 
> I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.

Recently, I realized that `names.empty` also signifies an error in `variableDeclaratorId` in some occasion around lambdas:  https://github.com/openjdk/jdk/blob/ffae4e0e97b19b1c1ad2865ed618ba380a861b7e/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3688-L3697
I don't believe that this would be a blocker but it could pose a possible minor challenge.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185595137

From jlahoda at openjdk.org  Fri May  5 06:14:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 06:14:45 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v9]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <VE0hqJV3MlHHbr7R-F6KAx0jowVUqSfh9IkpsKP-7Uk=.b0608601-8950-4735-bfe7-cf0aa4a816e3@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Updating MatchException javadoc.
 - Merge branch 'master' into JDK-8300543
 - Reverting use of record patterns in enhanced for loop.
 - Cleanup: reflecting review feedback.
 - Merge branch 'master' into JDK-8300543
 - Reflecting review changes.
 - Adding test.
 - Removing redundant continue, as noted on the review.
 - Replacing use of mutable callsite with a mutable state.
 - Reflecting review feedback.
 - ... and 32 more: https://git.openjdk.org/jdk/compare/a87262ef...79bbd717

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

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=08
  Stats: 4262 lines in 159 files changed: 2025 ins; 1722 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

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

From abimpoudis at openjdk.org  Fri May  5 08:44:23 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 08:44:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
Message-ID: <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>

On Thu, 4 May 2023 20:04:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:
> 
>> 86:  * or deletion without notice.</b></p>
>> 87:  */
>> 88: @SuppressWarnings("preview")
> 
> isn't it better to apply the annotation to the method below?

Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185840546

From jlahoda at openjdk.org  Fri May  5 09:29:35 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v14]
In-Reply-To: <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>
Message-ID: <3eNbxZ47pN094c130bnXzkaRcts92buDBG_EPBM4DJg=.3d354d72-17c5-4f5f-8c78-2166e56455c6@github.com>

On Thu, 4 May 2023 23:28:29 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307482: Compiler should accept var _ in nested patterns in switch case

src/jdk.compiler/share/classes/com/sun/source/tree/AnyPatternTree.java line 32:

> 30:  *
> 31:  */
> 32: public interface AnyPatternTree extends PatternTree {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java line 227:

> 225:          * @since 21
> 226:          */
> 227:         ANY_PATTERN(AnyPatternTree.class),

@PreviewFeature here.

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 267:

> 265:      * @since 21
> 266:      */
> 267:     R visitAnyPattern(AnyPatternTree node, P p);

@PreviewFeature here.

src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java line 641:

> 639:      */
> 640:     @Override
> 641:     public R visitAnyPattern(AnyPatternTree node, P p) {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java line 773:

> 771:      */
> 772:     @Override
> 773:     public R visitAnyPattern(AnyPatternTree node, P p) {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 329:

> 327:                 nestedBinding = nestedDesugared.primaryPattern();
> 328:                 allowNull = false;
> 329:             } else if (nestedPattern instanceof JCAnyPattern nestedRecordPattern) {

Nit: `nestedRecordPattern` -> `nestedAnyPattern`?

test/langtools/tools/javac/patterns/Unnamed.java line 8:

> 6:  * @summary Compiler Implementation for Unnamed patterns and variables
> 7:  * @enablePreview
> 8:  * @compile --enable-preview -source ${jdk.version} Unnamed.java

+1 on keeping the `@compile` tag, but `--enable-preview -source ${jdk.version}` shouldn't be needed when `@enablePreview` is present.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185805923
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807097
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807170
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807989
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185808102
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185819402
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185871609

From jlahoda at openjdk.org  Fri May  5 09:29:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:40 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>
Message-ID: <4GXVg3R1xzO-tFQenVIh_6FGWvSeXUfs5-17WDaM6m0=.ab0ae8c0-9fd0-4f2d-aade-d841f8fbece7@github.com>

On Thu, 4 May 2023 17:56:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java line 54:
> 
>> 52: 
>> 53:     /**
>> 54:      * Returns the name of the variable being declared or `_` if the variable
> 
> I guess if we go full for the empty name then this will need to change too

Maybe also add a mention that unnamed is a preview feature?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 535:
> 
>> 533:                 if (clearedPatterns.size() > 1) {
>> 534:                     validCaseLabelList = clearedPatterns.stream().allMatch(cP -> cP.hasTag(Tag.PATTERNCASELABEL));
>> 535:                 } else validCaseLabelList = clearedPatterns.size() == 1 && clearedPatterns.head.hasTag(Tag.PATTERNCASELABEL);
> 
> style: I would use `{}` for the code in the `else` branch here, same way as it has been done for the `then` branch. Also in the `else` branch isn't the `clearedPatterns.size() == 1` condition always true?

True - if I read the code correctly, the list should never be empty at this place.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java line 496:
> 
>> 494:     @DefinedBy(Api.COMPILER_TREE)
>> 495:     public JCTree visitAnyPattern(AnyPatternTree node, P p) {
>> 496:         JCBindingPattern t = (JCBindingPattern) node;
> 
> not sure this is correct, are we returning a JCBindingPattern?

+1

> test/langtools/tools/javac/patterns/Unnamed.java line 4:
> 
>> 2: 
>> 3: /**
>> 4:  * @test /nodynamiccopyright/
> 
> there is no golden file for this test so full copyright will be needed

Also, it is a custom that the comment with `@test` is before any imports, AFAIK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807820
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185823113
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185870099
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185871058

From jlahoda at openjdk.org  Fri May  5 09:29:49 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:49 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
 <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
 <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>
Message-ID: <0lJobZbHgtHyGKnoyvKcj8COkObRQo448AlEJxwIzIw=.5061dc4b-0900-4e6c-a36a-93c444c3effd@github.com>

On Thu, 4 May 2023 23:19:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>>> 
>> 
>> For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.
>> 
>> I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.
>
> Recently, I realized that `names.empty` also signifies an error in `variableDeclaratorId` in some occasion around lambdas:  https://github.com/openjdk/jdk/blob/ffae4e0e97b19b1c1ad2865ed618ba380a861b7e/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3688-L3697
> I don't believe that this would be a blocker but it could pose a possible minor challenge.

FWIW, I don't have a strong opinion on whether the name in the AST should be empty or underscore. (But I agree empty name is more consistent in the Language Model.) For missing names where names are expected (which is the above case), we could revisit later, there are more cases like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185869588

From jlahoda at openjdk.org  Fri May  5 09:29:47 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:47 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
 <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
Message-ID: <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>

On Fri, 5 May 2023 08:41:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:
>> 
>>> 86:  * or deletion without notice.</b></p>
>>> 87:  */
>>> 88: @SuppressWarnings("preview")
>> 
>> isn't it better to apply the annotation to the method below?
>
> Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.

IIRC the error is reported on the class level (with position on the class), so suppressing the warning on the method is not sufficient. We might want to review if the warning could have a better position, but we probably should not do it under this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185855689

From jlahoda at openjdk.org  Fri May  5 09:29:42 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
Message-ID: <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>

On Thu, 4 May 2023 20:47:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:
> 
>> 436:     }
>> 437: 
>> 438:     public boolean isUnnamed() {
> 
> Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?

+1 (I am a bit surprised the tests don't complain, that might be something to look at as well)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185809422

From jlahoda at openjdk.org  Fri May  5 09:29:44 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
 <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
Message-ID: <q5L_oTxXA2Be2acqCjSZDSqaGfIuwFjeXd4qcQ0WKJ4=.9fd24291-bccf-41a8-a6f7-64e517bfc1b7@github.com>

On Mon, 1 May 2023 22:29:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:
>> 
>>> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
>>> 1776:                             }
>>> 1777:                         } else if (guard != null) {
>> 
>> I guess this is caused by something like:
>> 
>> case _ when ...
>> 
>> If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.
>
> Actually this is for the case where we have `case A(_), B(C _) when ... `. In that case we are sure that the only scope we can use is the switch environment (since no bindings are introduced). Hm, I don't see another way of refactoring this without depending on `labels.tail.isEmpty()`

I was looking into this again, and I am afraid this is not quite correct. One of the issues is that this attrib will place any binding variables from the guard into the current `matchBindings`, and when the guard is attributed again, the variables in the `matchBindings` will collide. For example:

    String unnamedGuardAddsBindings(Object o1, Object o2) {
        return switch (o1) {
            case String _, Object _ when o2 instanceof String s: yield s;
            case Object _: yield "any";
        };
    }


My current proposal would be to (try to):
 - attribute the guard when handling the first pattern (so that we can detect whether or not it is constant)
 - but, do not merge the bindings from the guard immediately, but only after all the patterns are handled

It could look like this:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index e9c3ca27f1c..bade6b530eb 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -1688,7 +1688,7 @@ public class Attr extends JCTree.Visitor {
                     wasError = true;
                 }
                 MatchBindings currentBindings = null;
-                boolean wasUnconditionalPattern = hasUnconditionalPattern;
+                MatchBindings guardBindings = null;
                 for (List<JCCaseLabel> labels = c.labels; labels.nonEmpty(); labels = labels.tail) {
                     JCCaseLabel label = labels.head;
                     if (label instanceof JCConstantCaseLabel constLabel) {
@@ -1761,7 +1761,7 @@ public class Attr extends JCTree.Visitor {
                         checkCastablePattern(pat.pos(), seltype, primaryType);
                         Type patternType = types.erasure(primaryType);
                         JCExpression guard = c.guard;
-                        if (labels.tail.isEmpty() && guard != null) {
+                        if (labels == c.labels && guard != null) {
                             MatchBindings afterPattern = matchBindings;
                             Env<AttrContext> bodyEnv = bindingEnv(switchEnv, matchBindings.bindingsWhenTrue);
                             try {
@@ -1769,14 +1769,13 @@ public class Attr extends JCTree.Visitor {
                             } finally {
                                 bodyEnv.info.scope.leave();
                             }
-                            matchBindings = matchBindingsComputer.caseGuard(c, afterPattern, matchBindings);
+
+                            guardBindings = matchBindings;
+                            matchBindings = afterPattern;
 
                             if (TreeInfo.isBooleanWithValue(guard, 0)) {
                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
                             }
-                        } else if (guard != null) {
-                            // if the label has multiple patterns and a guard (with binding from the switch environment)
-                            attribExpr(guard, switchEnv, syms.booleanType);
                         }
                         boolean unguarded = TreeInfo.unguardedCase(c) && !pat.hasTag(RECORDPATTERN);
                         boolean unconditional =
@@ -1799,6 +1798,10 @@ public class Attr extends JCTree.Visitor {
                     currentBindings = matchBindingsComputer.switchCase(label, currentBindings, matchBindings);
                 }
 
+                if (guardBindings != null) {
+                    currentBindings = matchBindingsComputer.caseGuard(c, currentBindings, guardBindings);
+                }
+
                 Env<AttrContext> caseEnv =
                         bindingEnv(switchEnv, c, currentBindings.bindingsWhenTrue);
                 try {


(I didn't run tests on this, though.)

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746:
>> 
>>> 744: 
>>> 745:         sealed interface PatternDescription {
>>> 746:             public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) {
>> 
>> Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription.
>
> @lahodaj WDYT? Looks like it can be easily refactored and it is used only in one place (apart from the recursive call). I can refactor it in this PR or u can do it in #13074.

I somewhat liked the "factory method" aspect to this, but I admit the parameter list is getting longer. So, up to you, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185881273
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185817955

From jpai at openjdk.org  Fri May  5 09:33:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:33:22 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139:

> 137:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
> 138:         try {
> 139:             Method mainMethod = mainClass.getMethod("main", String[].class);

Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142:

> 140: 
> 141:             if (mainMethod.getDeclaringClass() != mainClass) {
> 142:                 System.err.println("WARNING: static main in super class will be deprecated.");

Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like:
> WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185882851
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185885497

From jpai at openjdk.org  Fri May  5 09:42:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:42:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152:

> 150: 
> 151:             List<Method> mains = new ArrayList<>();
> 152:             gatherMains(mainClass, mainClass, mains);

The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class.

So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158:

> 156:             }
> 157: 
> 158:             mains.sort(MainMethodFinder::compareMethods);

Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185890136
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185892782

From jpai at openjdk.org  Fri May  5 09:48:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:48:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70:

> 68:                         correctArgs(method) &&
> 69:                         // Only statics in the declaring class
> 70:                         (!isStatic(method) || declc == refc)

Should this also exclude `abstract` and `native` methods named `main`?

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:

> 132: 
> 133:     /**
> 134:      * {@return priority main method or null if none found}

I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185896198
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185898281

From jpai at openjdk.org  Fri May  5 09:55:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:55:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:

> 870:         Method mainMethod = null;
> 871:         try {
> 872:             mainMethod = MainMethodFinder.findMainMethod(mainClass);

The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like:

} catch (NoSuchMethodException nsme) {
   if (!PreviewFeatures.isEnabled()) {
                  // invalid main or not FX application, abort with an error
            abort(null, "java.launcher.cls.error4", mainClass.getName(),
                  JAVAFX_APPLICATION_CLASS_NAME);
   } else {
       // abort with something more clear error?
   }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185905158

From jpai at openjdk.org  Fri May  5 10:00:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:00:41 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <G9xRuFXqN1UwWrR8rI0AIyakHTbwOl5JqjIwJkls3jk=.cd1a8983-5b55-4c91-a738-05682bdca80a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893:

> 891:          * findMainMethod (above) will choose the correct method, based
> 892:          * on its name and parameter type, however, we still have to
> 893:          * ensure that the method is static (non-preview) and returns a void.

I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. 
What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185908021

From jpai at openjdk.org  Fri May  5 10:10:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:10:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <0IFuexmcfMhpT8nlQ02H-NNhUWzOvzdyMaklwlMR93k=.c674102a-00f1-4a26-ac87-8cd121ceb10f@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419:

> 417:     private static boolean isStatic(Method method) {
> 418:         return method != null && Modifier.isStatic(method.getModifiers());
> 419:     }

It looks like these new methods aren't being used.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440:

> 438:             int mods = mainMethod.getModifiers();
> 439:             boolean isStatic = Modifier.isStatic(mods);
> 440:             boolean isPublic = Modifier.isStatic(mods);

This looks like a typo. This should have been `Modifier.isPublic(mods);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185918190
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185917271

From jpai at openjdk.org  Fri May  5 10:18:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:18:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457:

> 455:             if (isStatic) {
> 456:                 if (noArgs) {
> 457:                     mainMethod.invoke(appClass);

Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185924903

From jpai at openjdk.org  Fri May  5 10:25:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:25:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <8Q_VdzphUbJgaiyTigSlBztROntOa5lz0oeMhrMcvRU=.2ce70574-d520-49be-91de-e2059c6062ce@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

test/jdk/tools/launcher/InstanceMainTest.java line 33:

> 31: public class InstanceMainTest extends TestHelper {
> 32: 
> 33:     @Test

Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185930904

From abimpoudis at openjdk.org  Fri May  5 10:41:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 10:41:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
Message-ID: <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>

On Fri, 5 May 2023 08:06:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:
>> 
>>> 436:     }
>>> 437: 
>>> 438:     public boolean isUnnamed() {
>> 
>> Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?
>
> +1 (I am a bit surprised the tests don't complain, that might be something to look at as well)

Note that `Element` does not declare `isUnnamed`.

`isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185944024

From jlaskey at openjdk.org  Fri May  5 11:56:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 11:56:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v3]
In-Reply-To: <aXXmw3MI3RKxzdvKBAgRPBfnEiQJWodtbizzX9k9m9I=.18eb38ed-3591-4b65-bd33-1eb7df7d982a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
 <aXXmw3MI3RKxzdvKBAgRPBfnEiQJWodtbizzX9k9m9I=.18eb38ed-3591-4b65-bd33-1eb7df7d982a@github.com>
Message-ID: <aGCkmAjy0Spx9uRPsdQUevkzlhdlaHN29IOLDoSWfr0=.511d6ed1-9c3d-4fd6-a769-eb3564ac4272@github.com>

On Thu, 27 Apr 2023 20:51:53 GMT, Maurizio Cimadamore <mcimadamore 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 14 commits:
>> 
>>  - Merge branch 'master' into 8306112
>>  - PreviewFeatures.isEnabled()
>>  - Clean up isPreview
>>  - Missing exception
>>  - Corrections
>>  - Update VM.java
>>  - Clean up testing
>>  - Update TestJavacTaskScanner.java
>>  - Merge branch 'master' into 8306112
>>  - Clean up
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d
>
> test/jdk/tools/launcher/OnrampMainTest.java line 31:
> 
>> 29:  * @run main OnrampMainTest
>> 30:  */
>> 31: public class OnrampMainTest extends TestHelper {
> 
> Should more tests be added for inherited methods?

Test added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186003544

From jlaskey at openjdk.org  Fri May  5 15:17:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:17:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
Message-ID: <RGKtTY66shAVBNXOd8sTf_SPkZtqS_c_J_xPs_vtsHM=.dbd38a99-ac48-42d8-82f7-dddebb8d2bc2@github.com>

On Fri, 5 May 2023 09:28:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139:
> 
>> 137:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
>> 138:         try {
>> 139:             Method mainMethod = mainClass.getMethod("main", String[].class);
> 
> Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method.

The problem with modifying behaviour that has existed since JDK 1.0 is that it has to be compatible in unexpected ways. If you look at the code modification:


-            mainMethod = mainClass.getMethod("main", String[].class);
+           mainMethod = MainMethodFinder.findMainMethod(mainClass);


you can see that nothing has really changed. The mainMethod was always possibly non-static and the caller produced an appropriate error message if that was the case. There is the rub.  If I didn't do it the way I have, I would also have to modify 130+ tests that expect to fail with a "method is not static" message as oppose to a "method not found" error message (there are other related issues to args and return types). After spending several days wading through a handful of these ancient tests, I realized I did not have time to complete the modifications necessary before targeting. And, there is also the issue of what happens to tests and expectations downstream. For a preview feature, behaviour has to remain the same when preview is not enabled.

I was also hopeful to be able to unify the _java launcher_ and the _source code launcher_. Similar problem with error messaging, though the tests for the source code launcher are fewer and newer. 

Unifying the launchers would also introduce another downstream issue. Since launching would occur from Java code, addition frames appear on the stack. Seems there are a several tests, tools and debuggers that rely on "main" being the first frame (even if hidden by printStackTrace). Ugh.

Before the next cycle, I hope to unify the messaging, have someone clean up the tests and figure out a scheme that unifies the launching.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186216248

From jlaskey at openjdk.org  Fri May  5 15:24:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:24:50 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
Message-ID: <6Rr-jSur-o5l60DNHYg-1GoZS7LO9Fc8S9d83Zs4Q7g=.58c21be6-a3b0-48be-9fff-74ad1c1f43dd@github.com>

On Fri, 5 May 2023 09:30:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142:
> 
>> 140: 
>> 141:             if (mainMethod.getDeclaringClass() != mainClass) {
>> 142:                 System.err.println("WARNING: static main in super class will be deprecated.");
> 
> Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like:
>> WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated.

Yes this is an oversight on my part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186223626

From jlaskey at openjdk.org  Fri May  5 15:28:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:28:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>
Message-ID: <cYUTlEko14g4NHZAyuNvud-ttBiNsdKtzGLCwWjFvLA=.b85426a1-9965-49ff-bb06-eec72e4b3046@github.com>

On Fri, 5 May 2023 09:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158:
> 
>> 156:             }
>> 157: 
>> 158:             mains.sort(MainMethodFinder::compareMethods);
> 
> Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`?

Likely negligible difference since it's interpreted code, but what the hey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186227774

From jlaskey at openjdk.org  Fri May  5 15:50:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:50:26 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>
Message-ID: <McxWY5003NdIXyU_nvdLI_J4LR33I4BLGzH9CnE8UyM=.98843605-fbda-4f7f-9e67-219afecff815@github.com>

On Fri, 5 May 2023 09:43:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70:
> 
>> 68:                         correctArgs(method) &&
>> 69:                         // Only statics in the declaring class
>> 70:                         (!isStatic(method) || declc == refc)
> 
> Should this also exclude `abstract` and `native` methods named `main`?

abstract would be overshadowed by its implementation and native is fair game.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:
> 
>> 132: 
>> 133:     /**
>> 134:      * {@return priority main method or null if none found}
> 
> I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method.

Changing

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152:
> 
>> 150: 
>> 151:             List<Method> mains = new ArrayList<>();
>> 152:             gatherMains(mainClass, mainClass, mains);
> 
> The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class.
> 
> So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy.

It doesn't skip, it just adds the super members first. However, I should move the `gatherMains` to the end since the sort pushes the best candidate to the top  and (was originally taking the last one with an opposite sort order). The sort order is

- static trumps non-static
- public trumps protected/package-protected
- arguments trumps no arguments
- depth in hierarchy

Let's say we have a hierarchy of `B` inherits from `A`.  If `B` contains `public void main()` and `A` contains `public void main(String... args)`,  `A`'s `main` trumps `B` `main` since it has  arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186247702
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186249703
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186245072

From abimpoudis at openjdk.org  Fri May  5 16:01:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 16:01:00 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Address comments
  
  - Annotate with Preview
  - Fix isUnnamed hierarchy
  - Flow names.empty for underscore in both model and API
  - Adjust pretty printing and annotation pretty printing
  - Fix guard bindings (great catch and thx @lahodaj!)
  - Fix TreeVisitor
  - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
  - Various adjustments
  
  Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/888297ef..5d9a1ba7

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

  Stats: 348 lines in 25 files changed: 189 ins; 102 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From jlaskey at openjdk.org  Fri May  5 16:02:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:02:39 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>
Message-ID: <J8kxyHI9Xwf3yE_McDMbO3xgx-imO3T1BSo1Q0cAp6w=.0b6f193f-063c-40fd-8ca3-dfddb3587952@github.com>

On Fri, 5 May 2023 09:52:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:
> 
>> 870:         Method mainMethod = null;
>> 871:         try {
>> 872:             mainMethod = MainMethodFinder.findMainMethod(mainClass);
> 
> The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like:
> 
> } catch (NoSuchMethodException nsme) {
>    if (!PreviewFeatures.isEnabled()) {
>                   // invalid main or not FX application, abort with an error
>             abort(null, "java.launcher.cls.error4", mainClass.getName(),
>                   JAVAFX_APPLICATION_CLASS_NAME);
>    } else {
>        // abort with something more clear error?
>    }

Not convinced that anything has changed or that the message is confusing.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893:
> 
>> 891:          * findMainMethod (above) will choose the correct method, based
>> 892:          * on its name and parameter type, however, we still have to
>> 893:          * ensure that the method is static (non-preview) and returns a void.
> 
> I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. 
> What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used.

I agree, but from my early commentary we have to hold off until later.

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419:
> 
>> 417:     private static boolean isStatic(Method method) {
>> 418:         return method != null && Modifier.isStatic(method.getModifiers());
>> 419:     }
> 
> It looks like these new methods aren't being used.

Remnants - removing

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440:
> 
>> 438:             int mods = mainMethod.getModifiers();
>> 439:             boolean isStatic = Modifier.isStatic(mods);
>> 440:             boolean isPublic = Modifier.isStatic(mods);
> 
> This looks like a typo. This should have been `Modifier.isPublic(mods);`

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186258290
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259446
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186261107
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259830

From abimpoudis at openjdk.org  Fri May  5 16:07:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 16:07:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
Message-ID: <QE9egEYTs7akFN2hRD-4KrpTBojPHsZ916LoNPw34uI=.70dc2aa5-5bf3-4120-acf2-511cc683d522@github.com>

On Fri, 5 May 2023 16:01:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments
>   
>   - Annotate with Preview
>   - Fix isUnnamed hierarchy
>   - Flow names.empty for underscore in both model and API
>   - Adjust pretty printing and annotation pretty printing
>   - Fix guard bindings (great catch and thx @lahodaj!)
>   - Fix TreeVisitor
>   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
>   - Various adjustments
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

Addressed all comments in https://github.com/openjdk/jdk/pull/13528/commits/5d9a1ba74aad4ee95dad6892d40e0aa68e04af18

Thx @lahodaj, @vicente-romero-oracle, @mcimadamore, @jddarcy ???

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1536469342

From jlaskey at openjdk.org  Fri May  5 16:08:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:08:22 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>
Message-ID: <K13hX3nRLojC9OmU33jAODsRp-OCi21G8jzIxpzRgD0=.7ec1cca9-5fdf-4a5a-8532-5f7a3c95fb5c@github.com>

On Fri, 5 May 2023 10:15:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457:
> 
>> 455:             if (isStatic) {
>> 456:                 if (noArgs) {
>> 457:                     mainMethod.invoke(appClass);
> 
> Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`?

Nostalgia and a useful reminder.

> test/jdk/tools/launcher/InstanceMainTest.java line 33:
> 
>> 31: public class InstanceMainTest extends TestHelper {
>> 32: 
>> 33:     @Test
> 
> Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....`

Same package

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186263733
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186265984

From jlaskey at openjdk.org  Fri May  5 16:18:42 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:18:42 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes #2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/ff7cd4c7..788b4e5a

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

  Stats: 22 lines in 2 files changed: 9 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From vromero at openjdk.org  Fri May  5 17:11:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 17:11:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
Message-ID: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>

On Fri, 5 May 2023 16:18:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recommended changes #2

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138:

> 136:      * @param mainClass main class
> 137:      *
> 138:      * @throws NoSuchMethodException when not and preview and no method found

wording here? `when not and preview`?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:

> 3997:         Name name = names.fromString(simplename);
> 3998:         JCModifiers anonMods = F.at(primaryPos)
> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());

I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186299301
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186323116

From jlaskey at openjdk.org  Fri May  5 17:31:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 17:31:27 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/788b4e5a..0c8add65

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

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

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

From jlaskey at openjdk.org  Fri May  5 17:31:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 17:31:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
Message-ID: <bPXSzL8v3HwRKq6i7MwckEnsMNUMOhSB_JOBTbApHTc=.07edf14b-a80e-4e64-9a61-bde003b6c5bb@github.com>

On Fri, 5 May 2023 16:42:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes #2
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138:
> 
>> 136:      * @param mainClass main class
>> 137:      *
>> 138:      * @throws NoSuchMethodException when not and preview and no method found
> 
> wording here? `when not and preview`?

oops - never on a Friday

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186337652

From forax at openjdk.org  Fri May  5 17:31:31 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 5 May 2023 17:31:31 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
Message-ID: <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>

On Fri, 5 May 2023 17:08:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes #2
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:
> 
>> 3997:         Name name = names.fromString(simplename);
>> 3998:         JCModifiers anonMods = F.at(primaryPos)
>> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());
> 
> I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag

`Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186335538

From vromero at openjdk.org  Fri May  5 17:38:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 17:38:25 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
 <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
Message-ID: <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>

On Fri, 5 May 2023 17:22:03 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:
>> 
>>> 3997:         Name name = names.fromString(simplename);
>>> 3998:         JCModifiers anonMods = F.at(primaryPos)
>>> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());
>> 
>> I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag
>
> `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.

good point

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186346149

From forax at openjdk.org  Fri May  5 17:50:21 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 5 May 2023 17:50:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
 <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
 <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>
Message-ID: <fsPFJ4Zb1p0Kt8MyFX4mGrzvRHYErSVbLIwMduKDjxc=.15bc9531-efa7-4010-b79a-bdb9b85463cc@github.com>

On Fri, 5 May 2023 17:35:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.
>
> good point

Just to be clear, here, Flags.UNNAMED_CLASS is needed because an an unnamed class must have a main(), which is tested later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186357338

From vromero at openjdk.org  Fri May  5 18:18:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 18:18:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
Message-ID: <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>

On Fri, 5 May 2023 17:31:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466:

> 464:         } catch (ClassNotFoundException e) {
> 465:             throw new Fault(Errors.CantFindClass(mainClassName));
> 466:         } catch (NoSuchMethodException e) {

`getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186379230

From jlaskey at openjdk.org  Fri May  5 18:32:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 18:32:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
 <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>
Message-ID: <pQvR3GdNCRDZGCEyqcn9Q_nW__MF3POeYU9b5h93UGs=.d8524d19-a3f0-4b1d-9351-fb28a37f4fe5@github.com>

On Fri, 5 May 2023 18:15:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466:
> 
>> 464:         } catch (ClassNotFoundException e) {
>> 465:             throw new Fault(Errors.CantFindClass(mainClassName));
>> 466:         } catch (NoSuchMethodException e) {
> 
> `getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor

I was avoiding moving things so not to change behaviour when not in preview, but I think I really need to break it down into separate try blocks; get method, get constructor, execute method. Let me attempt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186390633

From jlaskey at openjdk.org  Fri May  5 19:17:53 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 19:17:53 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v11]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Refactor source code launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/0c8add65..b91e75aa

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

  Stats: 76 lines in 2 files changed: 43 ins; 22 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From vromero at openjdk.org  Fri May  5 20:16:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 20:16:26 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v11]
In-Reply-To: <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>
Message-ID: <V6L8UNgbBplOvV8Tbw9bR_Msn-bGHMOnjuHjqvQSwDw=.893c3270-4664-4e59-8b8e-a40fae1b1e39@github.com>

On Fri, 5 May 2023 19:17:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor source code launcher

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1415400703

From darcy at openjdk.org  Fri May  5 21:25:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 May 2023 21:25:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
Message-ID: <tjmx6Hf7yOOJByMsOYVJbGhAvvqdCHOSXYy_tCwnzUc=.d246ea05-03c6-4805-9486-74a8879bca0e@github.com>

On Fri, 5 May 2023 16:01:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments
>   
>   - Annotate with Preview
>   - Fix isUnnamed hierarchy
>   - Flow names.empty for underscore in both model and API
>   - Adjust pretty printing and annotation pretty printing
>   - Fix guard bindings (great catch and thx @lahodaj!)
>   - Fix TreeVisitor
>   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
>   - Various adjustments
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1788:

> 1786:         }
> 1787: 
> 1788:         @Override @DefinedBy(Api.LANGUAGE_MODEL)

It's not incorrect to have this override, but I don't think it is necessary now either with the update to the default method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1186509423

From jjg at openjdk.org  Sat May  6 01:22:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 6 May 2023 01:22:40 GMT
Subject: RFR: JDK-8307563: make most fields final in `JavacTrees`
Message-ID: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>

Please review a small cleanup fix to address a comment left a long time back.

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

Commit messages:
 - JDK-8307563: make most fields final in `JavacTrees`

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

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

From liach at openjdk.org  Sat May  6 01:22:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 May 2023 01:22:40 GMT
Subject: RFR: JDK-8307563: make most fields final in `JavacTrees`
In-Reply-To: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
References: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
Message-ID: <EnVt8NSuO-k7scoO63LMuuAMxBysj_p85AIj4rw38bc=.5b85b5ca-4eb3-46a6-abac-70fdfe139d7a@github.com>

On Fri, 5 May 2023 22:08:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small cleanup fix to address a comment left a long time back.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 221:

> 219:         fileManager = context.get(JavaFileManager.class);
> 220:         var task = context.get(JavacTask.class);
> 221:         javacTaskImpl = (task instanceof JavacTaskImpl taskImpl) ? taskImpl : null;

Suggestion:

        javacTaskImpl = context.get(JavacTask.class) instanceof JavacTaskImpl taskImpl
                ? taskImpl : null;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13847#discussion_r1186530983

From darcy at openjdk.org  Sat May  6 02:44:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:44:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:

> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186599844

From darcy at openjdk.org  Sat May  6 02:57:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:57:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/StringTemplate.java line 427:

> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
> 426:      * as if invoking {@link String#valueOf(Object)}.
> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every

IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.

Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186601013

From abimpoudis at openjdk.org  Sat May  6 21:23:32 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 6 May 2023 21:23:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Remove @Override from VarSymbol.isUnnamed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/5d9a1ba7..482dbfa2

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

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

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

From abimpoudis at openjdk.org  Mon May  8 10:17:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 10:17:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
Message-ID: <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>

On Sat, 6 May 2023 21:23:32 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @Override from VarSymbol.isUnnamed

BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly. 

By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
index 631b0ce61ac..dc84c89f88e 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
@@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
         public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
             return v.visitVarSymbol(this, p);
         }
-
-        @DefinedBy(Api.LANGUAGE_MODEL)
-        public boolean isUnnamed() {
-            return name.isEmpty();
-        }
     }
 
     public static class RecordComponent extends VarSymbol implements RecordComponentElement {
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index 986f2e9fe89..26ef1c41156 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Attr extends JCTree.Visitor {
     protected static final Context.Key<Attr> attrKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
index 725a8a5e37d..537635a9490 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
@@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Check {
     protected static final Context.Key<Check> checkKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
index 452a823a46e..997ae7e3d81 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
@@ -203,6 +203,7 @@ import static java.util.stream.Collectors.groupingBy;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Flow {
     protected static final Context.Key<Flow> flowKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
index 13a4dd6c2cd..220aaf220d0 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
@@ -53,6 +53,7 @@ import static com.sun.tools.javac.code.TypeTag.TYPEVAR;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class MemberEnter extends JCTree.Visitor {
     protected static final Context.Key<MemberEnter> memberEnterKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
index 44ea3f904bd..cdf7d18b599 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
@@ -113,6 +113,7 @@ import com.sun.tools.javac.util.List;
 /**
  * This pass translates pattern-matching constructs, such as instanceof <pattern>.
  */
+ at SuppressWarnings("preview")
 public class TransPatterns extends TreeTranslator {
 
     protected static final Context.Key<TransPatterns> transPatternsKey = new Context.Key<>();

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1538121683

From abimpoudis at openjdk.org  Mon May  8 12:05:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 12:05:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v17]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <avAPtvy1DwzSBKKJNSq3td6c4RmOdOAunzZJP4BS27g=.5a706ca1-21bc-4cb5-82f3-01a6117dd268@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Remove isUnnamed from VarSymbol

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/482dbfa2..a46b674a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=15-16

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

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

From mcimadamore at openjdk.org  Mon May  8 12:15:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 12:15:36 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
 <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
Message-ID: <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>

On Mon, 8 May 2023 10:13:24 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly.
> 
> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
> 
> ```
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> index 631b0ce61ac..dc84c89f88e 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>              return v.visitVarSymbol(this, p);
>          }
> -
> -        @DefinedBy(Api.LANGUAGE_MODEL)
> -        public boolean isUnnamed() {
> -            return name.isEmpty();
> -        }
>      }
>  
>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> index 986f2e9fe89..26ef1c41156 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Attr extends JCTree.Visitor {
>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> index 725a8a5e37d..537635a9490 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Check {
>      protected static final Context.Key<Check> checkKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> index 452a823a46e..997ae7e3d81 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> @@ -203,6 +203,7 @@ import static java.util.stream.Collectors.groupingBy;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Flow {
>      protected static final Context.Key<Flow> flowKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> index 13a4dd6c2cd..220aaf220d0 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> @@ -53,6 +53,7 @@ import static com.sun.tools.javac.code.TypeTag.TYPEVAR;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class MemberEnter extends JCTree.Visitor {
>      protected static final Context.Key<MemberEnter> memberEnterKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> index 44ea3f904bd..cdf7d18b599 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> @@ -113,6 +113,7 @@ import com.sun.tools.javac.util.List;
>  /**
>   * This pass translates pattern-matching constructs, such as instanceof <pattern>.
>   */
> + at SuppressWarnings("preview")
>  public class TransPatterns extends TreeTranslator {
>  
>      protected static final Context.Key<TransPatterns> transPatternsKey = new Context.Key<>();
> ```

One thing we did in other places was to have a private equivalent of some public API method, so that we can call it internally from the compiler, w/o too much hassle (the internal version doesn't need to be marked as preview).

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1538257990

From jlaskey at openjdk.org  Mon May  8 12:51:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:51:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
Message-ID: <YJrw2TYcIl3YSbBUhC8lZkj80rjtMCCRbdxd9wK8sqM=.2b8176bd-a66d-4256-b407-9b9ea7529f01@github.com>

On Sat, 6 May 2023 02:42:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:
> 
>> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }
> 
> I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187407224

From jlaskey at openjdk.org  Mon May  8 12:53:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:53:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
Message-ID: <u3aYXVcsp34hfkaxT-GO3Q5czUxnrxeSis416oflJQI=.8685258b-3c9d-404f-a98d-c6a512c044a0@github.com>

On Sat, 6 May 2023 02:53:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 427:
> 
>> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
>> 426:      * as if invoking {@link String#valueOf(Object)}.
>> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every
> 
> IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.
> 
> Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187409617

From abimpoudis at openjdk.org  Mon May  8 13:27:55 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 13:27:55 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v18]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <oqsa2uw1baTZcyqwRWTH2576kAOiuwuq6HAffDUvubk=.3b3c9396-b4a1-48a1-9762-a4d7c3cf4404@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/a46b674a..8def897a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=16-17

  Stats: 15 lines in 7 files changed: 4 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Mon May  8 13:43:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 13:43:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v19]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <MhxtZfvyhKq5p3yOul_oB3bhOXBjCVRsnqtDkx7WqMs=.3d29e90b-9ea2-4deb-8355-f64258906014@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/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 44 commits:

 - Merge branch 'JDK-8300543' into unnamed
 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.
 - Remove isUnnamed from VarSymbol
 - Remove @Override from VarSymbol.isUnnamed
 - Address comments
   
   - Annotate with Preview
   - Fix isUnnamed hierarchy
   - Flow names.empty for underscore in both model and API
   - Adjust pretty printing and annotation pretty printing
   - Fix guard bindings (great catch and thx @lahodaj!)
   - Fix TreeVisitor
   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
   - Various adjustments
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
 - 8307482: Compiler should accept var _ in nested patterns in switch case
 - Add test
 - 8307444: java.lang.AssertionError when using unnamed patterns
 - Add guard test
 - ... and 34 more: https://git.openjdk.org/jdk/compare/79bbd717...c9387a26

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=18
  Stats: 1536 lines in 49 files changed: 1217 ins; 144 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Mon May  8 14:07:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 14:07:16 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v20]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Doc adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/c9387a26..2580f603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=18-19

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

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

From vromero at openjdk.org  Mon May  8 17:35:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 May 2023 17:35:36 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v20]
In-Reply-To: <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>
Message-ID: <-W_OQ97X7IF57Q5y8_-X3lyEWq8dGhtxglrDYG5dP30=.23bcb69d-b2c4-4188-a8d6-4889032b2f52@github.com>

On Mon, 8 May 2023 14:07:16 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13528#pullrequestreview-1417214589

From jlaskey at openjdk.org  Mon May  8 19:13:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 19:13:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v66]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <q4SwaaWMYKvgNUafmFVdnuH4ZbvRWQ6sUBbiccMQ6ag=.18c6b403-544a-417b-ad05-a7901ecf97df@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/fb406d23..53f6280d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64-65

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

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

From abimpoudis at openjdk.org  Mon May  8 20:15:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 20:15:46 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v21]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <f95zuqChwUB5NtD18YizwoPEZvbd7eqLXHjjGwuGFN8=.1839431d-a064-46cb-83b5-07cf4180481f@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/2580f603..19870563

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=19-20

  Stats: 52 lines in 4 files changed: 1 ins; 49 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Mon May  8 20:36:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 20:36:02 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Add at since tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/19870563..0437b20f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=20-21

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

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

From darcy at openjdk.org  Tue May  9 02:12:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:12:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
Message-ID: <DU9C7ecpeVbBcmjVDtRLXG2jhPTlhm0GK7nUUS2x5uE=.a0a2653a-8b82-40e0-ad6d-572d3e46c709@github.com>

On Mon, 8 May 2023 20:36:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add at since tag

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 28:

> 26: package javax.lang.model.util;
> 27: 
> 28: import jdk.internal.javac.PreviewFeature;

I believe this import can now be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188046153

From darcy at openjdk.org  Tue May  9 02:35:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
 <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
Message-ID: <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>

On Fri, 5 May 2023 10:38:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Note that `Element` does not declare `isUnnamed`.
> 
> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.

I think it is preferable for VarSymbol.isUnnamed to be deleted; it is functionally the same as the default method defined on VariableElement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188054212

From darcy at openjdk.org  Tue May  9 02:35:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:31 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
 <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
 <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>
Message-ID: <JxVFVwfQnH1cjHA11r3x7g0fgRwhuzJg4vNnVRG3g4o=.0e22a0df-8679-4af5-bb6e-2b0f4d15a36f@github.com>

On Tue, 9 May 2023 02:29:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Note that `Element` does not declare `isUnnamed`.
>> 
>> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.
>
>> Note that `Element` does not declare `isUnnamed`.
>> 
>> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.
> 
> I think it is preferable for VarSymbol.isUnnamed to be deleted; it is functionally the same as the default method defined on VariableElement.

> 

PS Just saw the additional discussion on this point below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188055782

From darcy at openjdk.org  Tue May  9 02:35:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
 <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
 <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>
Message-ID: <gskM_p4YyCK3H6WTdrVsU220uzGNgKukiJb-ZRzzhTs=.b7a6d52d-76dd-4a4c-b5e2-b175391e686d@github.com>

On Fri, 5 May 2023 08:57:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.
>
> IIRC the error is reported on the class level (with position on the class), so suppressing the warning on the method is not sufficient. We might want to review if the warning could have a better position, but we probably should not do it under this patch.

I think the suppress warnings annotation can be deleted now that the isUnnamed method has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188055506

From darcy at openjdk.org  Tue May  9 02:40:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:40:25 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
Message-ID: <-4RKGiOsEIAs4izpQO8bpM90d2N-0sWIilYEtMxlh3s=.ed7e1e05-f29a-4f41-9776-229d3ac32436@github.com>

On Mon, 8 May 2023 20:36:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add at since tag

Modulo the few nits noted, the javax.lang.model changes look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13528#pullrequestreview-1417754881

From abimpoudis at openjdk.org  Tue May  9 09:15:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 9 May 2023 09:15:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v23]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <6s6Gpc-w89RTMO6yAQqb3PKmaelt59nvpOoZK0ZSfCM=.a1e933d4-e3e5-496d-b8f6-dbae2f8048a0@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/0437b20f..a0e04e93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=21-22

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

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

From jlaskey at openjdk.org  Tue May  9 12:54:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:54:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v67]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <l7J5wI3ZLIVlZLDWAOSqMm43O9LPr7wZMEAlXpAz3ek=.15f31874-1c70-45ac-b63b-97a262b0fd51@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/53f6280d..8e83e10d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65-66

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

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

From jlaskey at openjdk.org  Tue May  9 12:58:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:58:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Dangling <p>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/8e83e10d..2ac6252b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66-67

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

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

From gli at openjdk.org  Tue May  9 14:11:18 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 9 May 2023 14:11:18 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
Message-ID: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>

Hi all,

When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
to solve this issue. And a corresponding test case is added.

Thanks for the review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8288619

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

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

From jjg at openjdk.org  Tue May  9 14:21:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 May 2023 14:21:27 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags.   That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.

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

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1418759322

From gli at openjdk.org  Tue May  9 14:36:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 9 May 2023 14:36:24 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
Message-ID: <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>

On Tue, 9 May 2023 14:17:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.

If there is something between the tag name and the quoted string, 
the method `quotedString` is never invoked by method `TagParser::parse`.
So such case seems not related to this bug. Do I miss anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1540248594

From jjg at openjdk.org  Tue May  9 14:47:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 May 2023 14:47:27 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
 <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
Message-ID: <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>

On Tue, 9 May 2023 14:33:50 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> > Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
> 
> If there is something between the tag name and the quoted string, the method `quotedString` is never invoked by method `TagParser::parse`. So such case seems not related to this bug. Do I miss anything?

I was just trying to imagine a case where `newline` might be true after the tag name has been read.

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1540267331

From asotona at openjdk.org  Tue May  9 15:03:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 15:03:00 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v2]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <h7axRpiKl8505vW21XplkwgrMwjby9GTXanWpxnixbQ=.f499bbd2-ddbb-4c4e-bc67-d0ae36519c45@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> 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 215 commits:

 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - Merge branch 'master' into JDK-8294969-javap
 - fixed tools/javap/TestClassNameWarning.java
 - fixed tools/javap/T6866657.java and tools/javap/T7186925.java
 - ... and 205 more: https://git.openjdk.org/jdk/compare/672bade5...7d18b761

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=01
  Stats: 3766 lines in 39 files changed: 904 ins; 1723 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From darcy at openjdk.org  Tue May  9 16:04:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 16:04:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <FZfpnNgeSWv_zBF2Zi_t9N__2HRiPM9om-prQVYkQPo=.0f6bb954-3f1e-499d-9967-cad643fb6548@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1418983197

From jlaskey at openjdk.org  Tue May  9 16:24:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:24:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:

 - Merge branch 'master' into 8285932
 - Dangling <p>
 - Recommended changes
 - Requested changes
 - CSR recommendations
 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68
  Stats: 9330 lines in 73 files changed: 9233 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From liach at openjdk.org  Tue May  9 16:26:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:26:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <cC6vWaC5XidjKv1fz6EfLtnEJSwFegkRZE_RKgc07VI=.2b746469-a931-4895-bb79-60871bb91afd@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

TestJavacTaskScanner is failing because of the new `setPrevToken` added that changes the total element count. Just need to update the count to take the changes to `Scanner` into account.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540490098

From jlaskey at openjdk.org  Tue May  9 16:37:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:37:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
Message-ID: <VpUv5E3jOqLwYbNZ1xOWJ66XkPl27KYKeoIZBXIaoh0=.ee44084f-cdb4-4808-befb-5b0d7fabe20e@github.com>

On Tue, 9 May 2023 16:24:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Dangling <p>
>  - Recommended changes
>  - Requested changes
>  - CSR recommendations
>  - Merge branch 'master' into 8285932
>  - Spacing
>  - Tidy up
>  - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
>  - Typo
>  - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

Thanks for the heads up.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540506421

From jlaskey at openjdk.org  Tue May  9 16:43:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:43:15 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v70]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9L5IuWB-IyF4NqldYaPlYKVt-29_ykeIwOu8z-x9jbk=.bb0ecc60-87aa-4a92-a6a0-d67cdf61050c@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update TestJavacTaskScanner.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f4f26611..6b09d2e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68-69

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

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

From jlaskey at openjdk.org  Wed May 10 11:38:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 10 May 2023 11:38:34 GMT
Subject: Integrated: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BRO6F0Nwun-KAL86AIlKg6QjPxW-8E4_-wWH8VpPu0M=.e092c60c-021c-455d-b85e-f1265fd65082@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

This pull request has now been integrated.

Changeset: 4aa65cbe
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aa65cbeefe44f29fbe6ea013809dcee579df9ff
Stats:     9331 lines in 74 files changed: 9233 ins; 23 del; 75 mod

8285932: Implementation of JEP 430 String Templates (Preview)

Reviewed-by: mcimadamore, rriggs, darcy

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

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

From jjg at openjdk.org  Wed May 10 22:06:44 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 10 May 2023 22:06:44 GMT
Subject: RFR: JDK-8307563: make most fields final in `JavacTrees`
In-Reply-To: <EnVt8NSuO-k7scoO63LMuuAMxBysj_p85AIj4rw38bc=.5b85b5ca-4eb3-46a6-abac-70fdfe139d7a@github.com>
References: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
 <EnVt8NSuO-k7scoO63LMuuAMxBysj_p85AIj4rw38bc=.5b85b5ca-4eb3-46a6-abac-70fdfe139d7a@github.com>
Message-ID: <jykvkY6o95b6sbuBftxweBjXIN4neZ88pysFh2eFKPY=.0185f63d-7375-4a25-b7bb-eaad6246e585@github.com>

On Fri, 5 May 2023 22:10:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review a small cleanup fix to address a comment left a long time back.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 221:
> 
>> 219:         fileManager = context.get(JavaFileManager.class);
>> 220:         var task = context.get(JavacTask.class);
>> 221:         javacTaskImpl = (task instanceof JavacTaskImpl taskImpl) ? taskImpl : null;
> 
> Suggestion:
> 
>         javacTaskImpl = context.get(JavacTask.class) instanceof JavacTaskImpl taskImpl
>                 ? taskImpl : null;

I don't see that as a significant improvement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13847#discussion_r1190433247

From vromero at openjdk.org  Wed May 10 22:21:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 May 2023 22:21:43 GMT
Subject: RFR: JDK-8307563: make most fields final in `JavacTrees`
In-Reply-To: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
References: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
Message-ID: <O8B4rCp08OVGCL8DcroCbcrLoz_e87ppBIK71DGxOmg=.cb14a532-5efd-4488-94a7-48e13add36c6@github.com>

On Fri, 5 May 2023 22:08:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small cleanup fix to address a comment left a long time back.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13847#pullrequestreview-1421444755

From jjg at openjdk.org  Wed May 10 22:26:50 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 10 May 2023 22:26:50 GMT
Subject: Integrated: JDK-8307563: make most fields final in `JavacTrees`
In-Reply-To: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
References: <kYHHojz7anvScybzlyXwmFf4CzQE-crANncBtkA5YUw=.7c3622f8-1b93-473d-9c98-7b3187c791b8@github.com>
Message-ID: <t2qT0B55KGQFD3d9twxQIQBsEITWTln2EHtcwz8JyKI=.9d837634-f78f-405d-92e8-725b11c7f364@github.com>

On Fri, 5 May 2023 22:08:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small cleanup fix to address a comment left a long time back.

This pull request has now been integrated.

Changeset: 958d4a75
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/958d4a750537320bf4e4f5cedd2e1a9a2e52ae33
Stats:     43 lines in 1 file changed: 16 ins; 25 del; 2 mod

8307563: make most fields final in `JavacTrees`

Reviewed-by: vromero

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

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

From jlaskey at openjdk.org  Thu May 11 10:54:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 May 2023 10:54:12 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v12]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <2hfZpzvDkrICXlLe0Dl09tcVut4zF8ahGixTc8I3yHo=.0b0786e1-d364-4b44-b815-a29ecb2d304a@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - Recommended changes #2
 - Anonymous main classes renamed to unnamed classes
 - Add test
 - Move AnonymousMainClass to parser
 - Revert java launch
 - Leave exception alone
 - Unused variables
 - ... and 16 more: https://git.openjdk.org/jdk/compare/cc396895...c3cfa837

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=11
  Stats: 1234 lines in 28 files changed: 1068 ins; 77 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlaskey at openjdk.org  Thu May 11 11:25:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 May 2023 11:25:51 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update VirtualParser.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/c3cfa837..90b1e981

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

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

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

From jlahoda at openjdk.org  Thu May 11 16:49:14 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 May 2023 16:49:14 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v10]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <VdzI_aIXl52wVPehiTFZQPi7dXg8s57kF_fjwTCPm0E=.7beaa138-09e8-4a9f-961e-cbf37ab64293@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge branch 'master' into JDK-8300543
 - Updating MatchException javadoc.
 - Merge branch 'master' into JDK-8300543
 - Reverting use of record patterns in enhanced for loop.
 - Cleanup: reflecting review feedback.
 - Merge branch 'master' into JDK-8300543
 - Reflecting review changes.
 - Adding test.
 - Removing redundant continue, as noted on the review.
 - Replacing use of mutable callsite with a mutable state.
 - ... and 33 more: https://git.openjdk.org/jdk/compare/2bf7ac58...69ba2a57

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

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=09
  Stats: 4256 lines in 158 files changed: 2027 ins; 1716 del; 513 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

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

From darcy at openjdk.org  Thu May 11 18:26:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 May 2023 18:26:39 GMT
Subject: Integrated: JDK-8307954: Update string template regression tests to be
 robust on release updates
Message-ID: <Uv22VecvI9aIxprGUCkBAZfhqRKO5RmzpN9G1khF07A=.cd88fffb-9910-4d73-bfd4-e33e098ed30c@github.com>

Change the string template diagnostic tests to use the preferred ${jdk.version} idiom rather than hard-coding a particular release value.

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

Commit messages:
 - JDK-8307954: Update string template regression tests to be robust on release updates

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

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

From jlaskey at openjdk.org  Thu May 11 18:26:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 May 2023 18:26:41 GMT
Subject: Integrated: JDK-8307954: Update string template regression tests
 to be robust on release updates
In-Reply-To: <Uv22VecvI9aIxprGUCkBAZfhqRKO5RmzpN9G1khF07A=.cd88fffb-9910-4d73-bfd4-e33e098ed30c@github.com>
References: <Uv22VecvI9aIxprGUCkBAZfhqRKO5RmzpN9G1khF07A=.cd88fffb-9910-4d73-bfd4-e33e098ed30c@github.com>
Message-ID: <0pCeyTt2Gt2G8WR_gqlHqrm9igXcazILzinYfxN8Ivw=.0fd79449-681c-4ded-834b-507d9f7cc639@github.com>

On Thu, 11 May 2023 18:13:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change the string template diagnostic tests to use the preferred ${jdk.version} idiom rather than hard-coding a particular release value.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13936#pullrequestreview-1423184251

From darcy at openjdk.org  Thu May 11 18:26:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 May 2023 18:26:42 GMT
Subject: Integrated: JDK-8307954: Update string template regression tests to be
 robust on release updates
In-Reply-To: <Uv22VecvI9aIxprGUCkBAZfhqRKO5RmzpN9G1khF07A=.cd88fffb-9910-4d73-bfd4-e33e098ed30c@github.com>
References: <Uv22VecvI9aIxprGUCkBAZfhqRKO5RmzpN9G1khF07A=.cd88fffb-9910-4d73-bfd4-e33e098ed30c@github.com>
Message-ID: <-fFXzP5T4WYzERb81m8xwkdNCTDXN2vMiG5RnDkh78s=.b8040daf-7ca5-4cab-8794-353a3e7553ff@github.com>

On Thu, 11 May 2023 18:13:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change the string template diagnostic tests to use the preferred ${jdk.version} idiom rather than hard-coding a particular release value.

This pull request has now been integrated.

Changeset: 29b8242e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29b8242e07b3e85887e916bc76f37eefb4403e1d
Stats:     6 lines in 6 files changed: 0 ins; 0 del; 6 mod

8307954: Update string template regression tests to be robust on release updates

Reviewed-by: jlaskey

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

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

From jjg at openjdk.org  Thu May 11 20:05:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 May 2023 20:05:39 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v6]
In-Reply-To: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
 <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com>
Message-ID: <XOb58-cLiw0ulATQykA0C6EY7t-GDIMPtq3GrcFKyFk=.4cb7559e-1e03-4fb9-bf28-404f9fac1916@github.com>

On Wed, 19 Apr 2023 14:17:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.
>> 
>> **Note:** This is dependent on PR #13362, to convert `DocCommentParser` to use enhanced switch.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

(keep alive comment).  Still need to respond to feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/13431#issuecomment-1544601330

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

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

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

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

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From abimpoudis at openjdk.org  Thu May 11 22:13:58 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 11 May 2023 22:13:58 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v24]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <NEx410enYnZTe9EFA_72R0bNKU3A8khekwdySUwV8W0=.2e053850-81bb-4a7e-9601-e6691e91a203@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/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 49 commits:

 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed
 - Doc adjustments
 - Merge branch 'JDK-8300543' into unnamed
 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.
 - Remove isUnnamed from VarSymbol
 - Remove @Override from VarSymbol.isUnnamed
 - ... and 39 more: https://git.openjdk.org/jdk/compare/69ba2a57...94997d16

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=23
  Stats: 1480 lines in 46 files changed: 1159 ins; 144 del; 177 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From duke at openjdk.org  Fri May 12 11:28:45 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Fri, 12 May 2023 11:28:45 GMT
Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when
 list is empty
In-Reply-To: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
Message-ID: <ugY5UROEvIgDrRwmN5Cj6XeuGPZeJvYQrl7FYPLduuo=.fca8a194-c5bb-4633-8499-86011beaa510@github.com>

On Mon, 10 Apr 2023 14:40:00 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers.
> 
> <img width="1045" alt="image" src="https://user-images.githubusercontent.com/6304496/230922012-d9c8f63f-beba-4e8a-a33c-367fb3cbf147.png">
> 
> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings.
> 
> <img width="943" alt="image" src="https://user-images.githubusercontent.com/6304496/230922383-e0363eca-bc87-4ad2-8465-ca1e801bd164.png">
> 
> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix.
> 
> Let me know what you think.
> 
> Cheers,
> Christoph

Is there anyone willing to sponsor this? Would be highly appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/13407#issuecomment-1545594327

From jjg at openjdk.org  Fri May 12 17:12:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 17:12:47 GMT
Subject: RFR: JDK-8308015: Syntax of "import static" is incorrect in
 com.sun.source.tree.ImportTree.java
Message-ID: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>

Please review a trivial change to fix a bug in a non-normative part of the spec for `ImportTree`

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

Commit messages:
 - JDK-8308015: Syntax of "import static" is incorrect in com.sun.source.tree.ImportTree.java

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

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

From jlaskey at openjdk.org  Fri May 12 17:21:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 12 May 2023 17:21:58 GMT
Subject: RFR: JDK-8308015: Syntax of "import static" is incorrect in
 com.sun.source.tree.ImportTree.java
In-Reply-To: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
References: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
Message-ID: <AeqxQOcd8tzYxrsin-6wRFyYbh91CfwHK-VJzn8eVAE=.a7b4ce2b-8fe5-4420-9ad5-ba4142a852fb@github.com>

On Fri, 12 May 2023 17:05:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial change to fix a bug in a non-normative part of the spec for `ImportTree`

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13960#pullrequestreview-1424889772

From darcy at openjdk.org  Fri May 12 17:21:59 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 May 2023 17:21:59 GMT
Subject: RFR: JDK-8308015: Syntax of "import static" is incorrect in
 com.sun.source.tree.ImportTree.java
In-Reply-To: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
References: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
Message-ID: <Ev8ClHyAThCZMdl32XxrznaBvc3cDeU5ZgbneS11H5o=.0bb262d0-d073-4f1a-9f34-95199e4cdcf4@github.com>

On Fri, 12 May 2023 17:05:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial change to fix a bug in a non-normative part of the spec for `ImportTree`

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13960#pullrequestreview-1424892545

From jjg at openjdk.org  Fri May 12 17:22:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 17:22:00 GMT
Subject: Integrated: JDK-8308015: Syntax of "import static" is incorrect in
 com.sun.source.tree.ImportTree.java
In-Reply-To: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
References: <SlVbW7RNNEzhbY9yLsQpIKeZsp-6Lc122PuugOCG4UU=.a225e42a-972c-491d-a1d4-be75ab89273a@github.com>
Message-ID: <6yKN3P8b0ipef16buj1TJfufx9nMcY_cNqmvkrVRbic=.4ce47264-c9c1-47da-9b34-55a5644fda27@github.com>

On Fri, 12 May 2023 17:05:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial change to fix a bug in a non-normative part of the spec for `ImportTree`

This pull request has now been integrated.

Changeset: 7455bb23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7455bb23c1d18224e48e91aae4f11fe114d04fab
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308015: Syntax of "import static" is incorrect in com.sun.source.tree.ImportTree.java

Reviewed-by: jlaskey, darcy

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

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

From jjg at openjdk.org  Fri May 12 20:19:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 20:19:40 GMT
Subject: RFR: JDK-8306607: Apply 80-column output to javac supported version
 output
Message-ID: <xnLdtXiZ5xIYukRJBcQJODoZovGIgz2FZvgbP7-KkV0=.4ecc7099-9df3-4d98-9370-08c3c3634cbe@github.com>

Please review a trivial `noreg-doc` output to fix a "long lines" issue.
The solution should be good enough for at least a few years, and by then, we may have pruned the list of supported releases :-)

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

Commit messages:
 - JDK-8306607: Apply 80-column output to javac supported version output

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

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

From attila.kelemen85 at gmail.com  Fri May 12 20:21:52 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Fri, 12 May 2023 22:21:52 +0200
Subject: NPE in javac 11.0.18 while infering exception type in lambda
Message-ID: <CAKDaPBdwMB=VtAtqj48GZ2WRPRTp4sFveyaQjVduzeBdqgCU0g@mail.gmail.com>

The following code causes javac to throw an NPE:

```
public class JavacBug {
  interface MyFunction<E extends Throwable> {
    Object apply(Object arg) throws E;
  }

  <E extends Throwable> Object withObj(MyFunction<E> f) throws E {
    return f.apply("X");
  }

  void dummyCall(Object arg) {
  }

  void test() {
    withObj(obj1 -> {
      return withObj(obj2 -> {
        dummyCall(obj1);
        return null;
      });
    });
  }
}
```

I have only tried this with 17 (aside from 11.0.18), but 17 compiles it fine.

The workaround to this issue is to explicitly declare the generic
parameter of the inner `withObj` call.

Attila

From darcy at openjdk.org  Fri May 12 20:28:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 May 2023 20:28:43 GMT
Subject: RFR: JDK-8306607: Apply 80-column output to javac supported
 version output
In-Reply-To: <xnLdtXiZ5xIYukRJBcQJODoZovGIgz2FZvgbP7-KkV0=.4ecc7099-9df3-4d98-9370-08c3c3634cbe@github.com>
References: <xnLdtXiZ5xIYukRJBcQJODoZovGIgz2FZvgbP7-KkV0=.4ecc7099-9df3-4d98-9370-08c3c3634cbe@github.com>
Message-ID: <6stzY6Pj-skz8ssNJFghpGhlgHTFfVhAVQZ1-4YPPHw=.8bfb7e78-7956-47e6-8069-b04066270c2d@github.com>

On Fri, 12 May 2023 20:13:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial `noreg-doc` output to fix a "long lines" issue.
> The solution should be good enough for at least a few years, and by then, we may have pruned the list of supported releases :-)

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13965#pullrequestreview-1425113186

From jjg at openjdk.org  Fri May 12 20:32:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 20:32:55 GMT
Subject: Integrated: JDK-8306607: Apply 80-column output to javac supported
 version output
In-Reply-To: <xnLdtXiZ5xIYukRJBcQJODoZovGIgz2FZvgbP7-KkV0=.4ecc7099-9df3-4d98-9370-08c3c3634cbe@github.com>
References: <xnLdtXiZ5xIYukRJBcQJODoZovGIgz2FZvgbP7-KkV0=.4ecc7099-9df3-4d98-9370-08c3c3634cbe@github.com>
Message-ID: <wil4z9pegqrgW-As9mfv-VSoX3hFiZ1xpLTwVTQsap4=.b43b0f81-f6ff-432a-a4af-5f06430e0923@github.com>

On Fri, 12 May 2023 20:13:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial `noreg-doc` output to fix a "long lines" issue.
> The solution should be good enough for at least a few years, and by then, we may have pruned the list of supported releases :-)

This pull request has now been integrated.

Changeset: 9842ff41
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9842ff4129b756abb5761cdca71126508224875f
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8306607: Apply 80-column output to javac supported version output

Reviewed-by: darcy

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

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

From vromero at openjdk.org  Fri May 12 20:35:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 May 2023 20:35:51 GMT
Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when
 list is empty
In-Reply-To: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
Message-ID: <1JaONUxaQeucMQ_SRszfpLByiA_uoWW83cGyk7W342U=.ad04eaa7-7679-4c32-9f0e-f0fcbd2a3f0c@github.com>

On Mon, 10 Apr 2023 14:40:00 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers.
> 
> <img width="1045" alt="image" src="https://user-images.githubusercontent.com/6304496/230922012-d9c8f63f-beba-4e8a-a33c-367fb3cbf147.png">
> 
> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings.
> 
> <img width="943" alt="image" src="https://user-images.githubusercontent.com/6304496/230922383-e0363eca-bc87-4ad2-8465-ca1e801bd164.png">
> 
> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix.
> 
> Let me know what you think.
> 
> Cheers,
> Christoph

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13407#pullrequestreview-1425119401

From jjg at openjdk.org  Fri May 12 21:18:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:18:43 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

I see the problem reported in the JBS issue, but the proposed fix is not the best one.

It would be better to set the `newline` flag to false earlier, perhaps at the beginning of `blockTag`

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

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1425165029

From jjg at openjdk.org  Fri May 12 21:35:45 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:35:45 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

test/langtools/tools/javac/doctree/SeeTest.java line 59:

> 57:      * @see "{@code}"
> 58:      */
> 59:     void at_sign_in_quote_string() { }

(minor) add `d` after `quote` in method name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1192810666

From jjg at openjdk.org  Fri May 12 21:35:46 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:35:46 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
Message-ID: <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>

On Fri, 12 May 2023 21:31:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
>> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
>> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
>> to solve this issue. And a corresponding test case is added.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> test/langtools/tools/javac/doctree/SeeTest.java line 59:
> 
>> 57:      * @see "{@code}"
>> 58:      */
>> 59:     void at_sign_in_quote_string() { }
> 
> (minor) add `d` after `quote` in method name

Also, add a test case for this, with a newline after the tag:

    /**
     * abc.
     * @see
     *    "{@code ...}"
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1192811508

From jwaters at openjdk.org  Sun May 14 12:07:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 May 2023 12:07:45 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <cRlp7OEICNDoKpcU8WP9nxNVBO29rp-oLzZ_1UKaaDM=.6176f9ee-c1a0-4b00-8d3e-dd395a63c105@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <cRlp7OEICNDoKpcU8WP9nxNVBO29rp-oLzZ_1UKaaDM=.6176f9ee-c1a0-4b00-8d3e-dd395a63c105@github.com>
Message-ID: <dMPNJJfsCectuK-onZ_Rxf3RoDBOHfTpE8Hz5KUXVk4=.c14b20a0-6470-4162-8af1-61efe164f6ce@github.com>

On Thu, 13 Apr 2023 11:58:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> I think I'd like to understand more about "Visual C++ no longer requires" - since when, how (un-)realistic is it that people would still be using a C++ compiler that would require the workaround, etc.
> 
> Because, as far as I know, the `JNIWriter` is used by users to generate the headers, and those users may be using various compilers, so I think we should verify we won't break the users.

Bumping @lahodaj?

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1546884384

From gli at openjdk.org  Mon May 15 05:05:46 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:05:46 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <HXd2WFYguc4iyB0RPGhQ8C0PGa7bxq7jzmcT7jWv61o=.cd658190-4829-42eb-a9ad-ad6e7f2993cf@github.com>

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:

 - Add test case.
 - Set newline as false at blockTag. Fix typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13888/files
  - new: https://git.openjdk.org/jdk/pull/13888/files/89f4323a..904c800f

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

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

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

From gli at openjdk.org  Mon May 15 05:05:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:05:48 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
 <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>
Message-ID: <9DnYgyTK0HGKmfNui5qjYu7lsRJS7aJ0d8OaWOIqOy4=.69ad7b8f-af1a-4199-b72a-4bb3a3e1e88b@github.com>

On Fri, 12 May 2023 21:32:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/tools/javac/doctree/SeeTest.java line 59:
>> 
>>> 57:      * @see "{@code}"
>>> 58:      */
>>> 59:     void at_sign_in_quote_string() { }
>> 
>> (minor) add `d` after `quote` in method name
>
> Also, add a test case for this, with a newline after the tag:
> 
>     /**
>      * abc.
>      * @see
>      *    "{@code ...}"
>      */

> (minor) add `d` after `quote` in method name

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1193327514

From gli at openjdk.org  Mon May 15 05:11:47 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:11:47 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>
Message-ID: <bGuehDVpqgMmFg7mmxpq6gHz33sd2IAcjVTVjqBqODc=.bad5c4b7-e62f-43ba-be30-9578057e3b62@github.com>

On Fri, 12 May 2023 21:15:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> It would be better to set the `newline` flag to false earlier, perhaps at the beginning of `blockTag`

Fixed.

> Here is another test case:
> 
> ```
>     /**
>      * case 2.
>      * @see
>      *    "{@code ...}"
>      */
>     public void m2() { }
> ```

I add this test case. But it fails with the following error message. The `DocCommentTester#PrettyChecker` doesn't seem to work as expected?


METHOD new_line_before_quoted_string PrettyChecker
Error: mismatch
*** expected:
Test_new_line_before_quoted_string.
@see
____"{@code}"
*** found:
Test_new_line_before_quoted_string.
@see_"{@code}"

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1547198907

From alanb at openjdk.org  Mon May 15 07:52:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 May 2023 07:52:05 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
Message-ID: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>

On Thu, 11 May 2023 11:25:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update VirtualParser.java

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35:

> 33: public class MainMethodFinder {
> 34:     private static boolean isPrivate(Method method) {
> 35:         return method != null && Modifier.isPrivate(method.getModifiers());

Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38:

> 36:     }
> 37: 
> 38:     private static boolean isPublic(Method method) {

Is this left over from a previous iteration, it doesn't seem to be used.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53:

> 51: 
> 52:     /**
> 53:      * Gather all the "main" methods in the class heirarchy.

heirarchy -> hierarchy

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:

> 132: 
> 133:     /**
> 134:      * {@return priority main method or null if none found}

"or null if none found", is that out of date?

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:

> 144: 
> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");

I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156:

> 154: 
> 155:             List<Method> mains = new ArrayList<>();
> 156:             gatherMains(mainClass, mainClass, mains);

Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162:

> 160:             }
> 161: 
> 162:             if (1 < mains.size()) {

Checking if mains.size() > 1 might be easier on the eyes.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:

> 870: 
> 871:     // Check the existence and signature of main and abort if incorrect
> 872:     public static void validateMainClass(Class<?> mainClass) {

Is there a reason that this is changed to public, maybe left over from a previous iteration?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896:

> 894:          * findMainMethod (above) will choose the correct method, based
> 895:          * on its name and parameter type, however, we still have to
> 896:          * ensure that the method is static (non-preview) and returns a void.

Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904:

> 902: 
> 903:         if (!PreviewFeatures.isEnabled()) {
> 904:             if (!isStatic || !isPublic || noArgs) {

You can use && here and avoid the nested if.

test/jdk/tools/launcher/InstanceMainTest.java line 31:

> 29:  * @run main InstanceMainTest
> 30:  */
> 31: public class InstanceMainTest extends TestHelper {

Are you planning to add tests for the selection/precedence order?

Also wondering if we need a test to check that there is a warning when the main method in found in the super class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379090
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193378248
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379468
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193415367
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193385008
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193440438
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193419331
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193444639
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193455653
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193443762
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193390566

From hannesw at openjdk.org  Mon May 15 14:49:55 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 15 May 2023 14:49:55 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
Message-ID: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>

Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 

With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.

The error message for the warning was enhanced to refer to the default style for the `<a>` element.

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

Commit messages:
 - JDK-8292157: Improve warning messages
 - Merge branch 'master' into JDK-8292157
 - JDK-8292157: Incorrect error: "block element not allowed within inline element <a>"

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

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

From jlaskey at openjdk.org  Mon May 15 17:01:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:01:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <pZHEJvRKpYMVIYC-EPIRX_FoDVCrswLxH0syakUGRos=.4a4fc275-8e9a-4abd-8e00-172cd38ffddc@github.com>

On Mon, 15 May 2023 06:31:40 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 VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35:
> 
>> 33: public class MainMethodFinder {
>> 34:     private static boolean isPrivate(Method method) {
>> 35:         return method != null && Modifier.isPrivate(method.getModifiers());
> 
> Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens.

Remnant of previous usage. Changed.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38:
> 
>> 36:     }
>> 37: 
>> 38:     private static boolean isPublic(Method method) {
> 
> Is this left over from a previous iteration, it doesn't seem to be used.

Changed

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53:
> 
>> 51: 
>> 52:     /**
>> 53:      * Gather all the "main" methods in the class heirarchy.
> 
> heirarchy -> hierarchy

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194107274
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194105447
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194108052

From jlaskey at openjdk.org  Mon May 15 17:09:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:09:02 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>

On Mon, 15 May 2023 06:45:45 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 VirtualParser.java
>
> test/jdk/tools/launcher/InstanceMainTest.java line 31:
> 
>> 29:  * @run main InstanceMainTest
>> 30:  */
>> 31: public class InstanceMainTest extends TestHelper {
> 
> Are you planning to add tests for the selection/precedence order?
> 
> Also wondering if we need a test to check that there is a warning when the main method in found in the super class.

InstanceMainTest does check precedence. Are you expecting a test for all combinations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194117636

From jlaskey at openjdk.org  Mon May 15 17:21:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:21:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>

On Mon, 15 May 2023 06:38:48 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 VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:
> 
>> 144: 
>> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
>> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");
> 
> I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".

JEP 445 is not deprecating this. No advanced notice has been given.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162:
> 
>> 160:             }
>> 161: 
>> 162:             if (1 < mains.size()) {
> 
> Checking if mains.size() > 1 might be easier on the eyes.

I never ever use > symbol. least to greatest left to right (maths).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194132127
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194133518

From jlaskey at openjdk.org  Mon May 15 17:29:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:29:57 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <etSqgB9HDg8Ojy8axURx44i1hUVgr6SSgmEZ-Grpvvw=.b3644814-6af3-48ec-a0b6-d9c6ff8af880@github.com>

On Mon, 15 May 2023 07:13:49 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 VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:
> 
>> 132: 
>> 133:     /**
>> 134:      * {@return priority main method or null if none found}
> 
> "or null if none found", is that out of date?

Changed

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156:
> 
>> 154: 
>> 155:             List<Method> mains = new ArrayList<>();
>> 156:             gatherMains(mainClass, mainClass, mains);
> 
> Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main.

99.99% of the time it will be a single method in a shallow hierarchy, so cost its low. Only reason I broke out public static main was to ensure performance for existing code was the same.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:
> 
>> 870: 
>> 871:     // Check the existence and signature of main and abort if incorrect
>> 872:     public static void validateMainClass(Class<?> mainClass) {
> 
> Is there a reason that this is changed to public, maybe left over from a previous iteration?

Remnant. Changed.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904:
> 
>> 902: 
>> 903:         if (!PreviewFeatures.isEnabled()) {
>> 904:             if (!isStatic || !isPublic || noArgs) {
> 
> You can use && here and avoid the nested if.

Easier to see when removing preview code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194138214
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194137852
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141538
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141140

From jlaskey at openjdk.org  Mon May 15 17:37:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:37:58 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <lBowlr6Mc6C4PUEPwSiiEfsapnIcvZoBk5B1M8z758E=.6dce05a5-0a2e-4d23-bf88-3d9f3d2889da@github.com>

On Mon, 15 May 2023 07:48:26 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 VirtualParser.java
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896:
> 
>> 894:          * findMainMethod (above) will choose the correct method, based
>> 895:          * on its name and parameter type, however, we still have to
>> 896:          * ensure that the method is static (non-preview) and returns a void.
> 
> Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking.

At some point I would like to fold both launchers into a single launcher. To do so would require having the source code launcher use the same error reporting and adapting downstream accordingly (tests et al). There is also a separate project to support multi-file source code launcher and I didn't want to disrupt the flow of that project at this point in time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194149300

From jlaskey at openjdk.org  Mon May 15 18:08:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 18:08:16 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v14]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <I0TIWBz6DE147ML4eJ8PcczUPuQ-dv0wLEQ4YE4OY9M=.c6d940b1-8f5e-4548-9286-28e4bf6990f0@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested Changes #2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/90b1e981..2b625a39

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

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

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

From alanb at openjdk.org  Mon May 15 18:39:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 May 2023 18:39:57 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
 <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>
Message-ID: <qlS8-vnYvL8JDMCme_TZAGGDYmbx9bVDWj_C4bj_xTM=.726c7680-9ec4-44fa-ae66-a274c5fa5ab1@github.com>

On Mon, 15 May 2023 17:18:01 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:
>> 
>>> 144: 
>>> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
>>> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");
>> 
>> I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".
>
> JEP 445 is not deprecating this. No advanced notice has been given.

Ah, I thought it was being deprecated. The JEP currently has "We deprecate the existing behavior that the launcher searches for a public static void main(String[] args) method in a superclass if one is not found in the launched class, issuing a runtime warning if such a method is found".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194220442

From duke at openjdk.org  Tue May 16 09:54:54 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Tue, 16 May 2023 09:54:54 GMT
Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when
 list is empty
In-Reply-To: <1JaONUxaQeucMQ_SRszfpLByiA_uoWW83cGyk7W342U=.ad04eaa7-7679-4c32-9f0e-f0fcbd2a3f0c@github.com>
References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
 <1JaONUxaQeucMQ_SRszfpLByiA_uoWW83cGyk7W342U=.ad04eaa7-7679-4c32-9f0e-f0fcbd2a3f0c@github.com>
Message-ID: <oFRFrcTVE4rKW3QrraiNy3kI8zYCFpxp4kFA2Vlm5AI=.305d3605-5605-4f6a-ad3b-c48dd05e79e6@github.com>

On Fri, 12 May 2023 20:32:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi,
>> 
>> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers.
>> 
>> <img width="1045" alt="image" src="https://user-images.githubusercontent.com/6304496/230922012-d9c8f63f-beba-4e8a-a33c-367fb3cbf147.png">
>> 
>> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings.
>> 
>> <img width="943" alt="image" src="https://user-images.githubusercontent.com/6304496/230922383-e0363eca-bc87-4ad2-8465-ca1e801bd164.png">
>> 
>> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix.
>> 
>> Let me know what you think.
>> 
>> Cheers,
>> Christoph
>
> looks good

@vicente-romero-oracle Thanks for sponsoring this. Highly appreciated ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13407#issuecomment-1549351369

From vromero at openjdk.org  Tue May 16 14:26:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 May 2023 14:26:57 GMT
Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when
 list is empty
In-Reply-To: <1JaONUxaQeucMQ_SRszfpLByiA_uoWW83cGyk7W342U=.ad04eaa7-7679-4c32-9f0e-f0fcbd2a3f0c@github.com>
References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
 <1JaONUxaQeucMQ_SRszfpLByiA_uoWW83cGyk7W342U=.ad04eaa7-7679-4c32-9f0e-f0fcbd2a3f0c@github.com>
Message-ID: <_U1fd9ek13MutPklv44-EVWiXCCTPO8MsbaeojlufKg=.cadea50e-ed9c-435b-82a7-c6f1004e0c80@github.com>

On Fri, 12 May 2023 20:32:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi,
>> 
>> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers.
>> 
>> <img width="1045" alt="image" src="https://user-images.githubusercontent.com/6304496/230922012-d9c8f63f-beba-4e8a-a33c-367fb3cbf147.png">
>> 
>> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings.
>> 
>> <img width="943" alt="image" src="https://user-images.githubusercontent.com/6304496/230922383-e0363eca-bc87-4ad2-8465-ca1e801bd164.png">
>> 
>> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix.
>> 
>> Let me know what you think.
>> 
>> Cheers,
>> Christoph
>
> looks good

> @vicente-romero-oracle Thanks for sponsoring this. Highly appreciated pray

sure, thanks to you

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

PR Comment: https://git.openjdk.org/jdk/pull/13407#issuecomment-1549779034

From duke at openjdk.org  Tue May 16 14:26:59 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Tue, 16 May 2023 14:26:59 GMT
Subject: Integrated: JDK-8306860: Avoid unnecessary allocation in List.map()
 when list is empty
In-Reply-To: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com>
Message-ID: <MzuM0SvKY_iEGNDxU8WN6jwCCIzIPTHtseue7Nv1tLQ=.81017623-96dc-40fc-b792-e57f4ca044b0@github.com>

On Mon, 10 Apr 2023 14:40:00 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers.
> 
> <img width="1045" alt="image" src="https://user-images.githubusercontent.com/6304496/230922012-d9c8f63f-beba-4e8a-a33c-367fb3cbf147.png">
> 
> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings.
> 
> <img width="943" alt="image" src="https://user-images.githubusercontent.com/6304496/230922383-e0363eca-bc87-4ad2-8465-ca1e801bd164.png">
> 
> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix.
> 
> Let me know what you think.
> 
> Cheers,
> Christoph

This pull request has now been integrated.

Changeset: 23cbb2d1
Author:    Christoph Dreis <christoph.dreis at freenet.de>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23cbb2d1709b5e7509e373d4642806d6436cbbcb
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8306860: Avoid unnecessary allocation in List.map() when list is empty

Reviewed-by: vromero

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

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

From alanb at openjdk.org  Tue May 16 18:34:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 May 2023 18:34:50 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
 <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>
Message-ID: <90pfraspjRWfTepdB2XMf4siiN6ZFqCTh2Byn8UoI_M=.5d15d232-1589-4455-8c9e-61d86ec013f6@github.com>

On Mon, 15 May 2023 17:05:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> InstanceMainTest does check precedence. Are you expecting a test for all combinations?

Sorry, we discussed this in previous comments, ignore my latest comment on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194221553

From jlaskey at openjdk.org  Tue May 16 18:34:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 16 May 2023 18:34:49 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v15]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <DATc1bDAoNCAu4N3OiscPyG4Pc5u-3XtLZBR1xVntlo=.166bf13f-33b5-4594-b7a8-9f1b1eb84ea5@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' into 8306112
 - Requested Changes #2
 - Update VirtualParser.java
 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - Recommended changes #2
 - Anonymous main classes renamed to unnamed classes
 - Add test
 - Move AnonymousMainClass to parser
 - ... and 19 more: https://git.openjdk.org/jdk/compare/316bc79e...185532a8

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=14
  Stats: 1234 lines in 28 files changed: 1069 ins; 77 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From acobbs at openjdk.org  Tue May 16 21:36:42 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 May 2023 21:36:42 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v3]
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: <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@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 incrementally with one additional commit since the last revision:

  Make "statements before super()" support a preview feature.
  
  Thanks to Jim Laskey for help with preview logic.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/0e638da2..3c9322b6

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

  Stats: 58 lines in 9 files changed: 55 ins; 0 del; 3 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 james.laskey at oracle.com  Tue May 16 21:49:02 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 16 May 2023 21:49:02 +0000
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v3]
In-Reply-To: <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@github.com>
Message-ID: <23BF8C74-F574-4330-B20F-02CCA7BD467A@oracle.com>

Don?t forget to update the tests to use the @enablePreview flag. 

?

> On May 16, 2023, at 6:37 PM, 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 incrementally with one additional commit since the last revision:
> 
>  Make "statements before super()" support a preview feature.
> 
>  Thanks to Jim Laskey for help with preview logic.
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.org/jdk/pull/13656/files
>  - new: https://git.openjdk.org/jdk/pull/13656/files/0e638da2..3c9322b6
> 
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=02
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=01-02
> 
>  Stats: 58 lines in 9 files changed: 55 ins; 0 del; 3 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 acobbs at openjdk.org  Wed May 17 02:32:02 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 May 2023 02:32:02 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
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: <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@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 incrementally with one additional commit since the last revision:

  Use @enablePreview in tests in preference to explicit command line flags.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/3c9322b6..73bb3270

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

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 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 abimpoudis at openjdk.org  Wed May 17 11:30:05 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 May 2023 11:30:05 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v25]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <BuJO2SrKJN14TNLZNjc1KMIji4uQosxlJExh3e5cKCo=.f2161afb-1bf3-4d42-92d6-585cd1abd735@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Fix compiler bugs
  
  - Fix skipped errors when using unnamed locals without initializer
  - Fix lambdas with mix unnamed and named parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/94997d16..175d6459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=23-24

  Stats: 50 lines in 5 files changed: 41 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Wed May 17 14:23:37 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 May 2023 14:23:37 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Simplify `LambdaClassifier`
  
  Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/175d6459..804d41af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=24-25

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

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

From mcimadamore at openjdk.org  Wed May 17 23:34:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 23:34:03 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
Message-ID: <lNGhPpdMDZ3wMShy4JV3zUV3a3Es6-sRjDD_Y4Yig3s=.4453c0d0-1915-471a-8616-50cbc6e61a85@github.com>

On Wed, 17 May 2023 14:23:37 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `LambdaClassifier`
>   
>   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2070:

> 2068: 
> 2069:         /**
> 2070:          * analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to

Many thanks for adding these precious comments!

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2083:

> 2081:             if (param.name == names.error) {
> 2082:                 reduce(LambdaParameterKind.IMPLICIT);
> 2083:                 return;

could we use if/else if/else and get rid of return?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197162301
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197162518

From mcimadamore at openjdk.org  Wed May 17 23:42:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 23:42:04 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
Message-ID: <3k5XTy1xj90EuCWIY-2F8I2yU_dT1a1T7M4n__m9nt8=.f25a7007-8d3f-4f8b-8d3c-7a8404c9da2c@github.com>

On Wed, 17 May 2023 14:23:37 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `LambdaClassifier`
>   
>   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2071:

> 2069:         /**
> 2070:          * analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to
> 2071:          * two consecutive identifiers. adding an erroneous parameter (one that

Shouldn't the second sentence say something more like:

Because of that (<explicit lambda>), the parser will always attempt to parse a type, followed by a name.
If the lambda contains an illegal mix of implicit and explicit parameters, it is possible for the parser to see a `,` when expecting a name, in which case the variable is created with an erroneous name.
The logic below makes sure that the lambda parameters are all declared with either an explicit type (e.g. `String x`), or with an inferred type (using `var x`).
Any other combination is rejected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197166447

From gli at openjdk.org  Thu May 18 05:22:49 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 18 May 2023 05:22:49 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Exclude the PrettyChecker.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13888/files
  - new: https://git.openjdk.org/jdk/pull/13888/files/904c800f..7bd28103

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

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

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

From darcy at openjdk.org  Thu May 18 06:26:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 May 2023 06:26:18 GMT
Subject: RFR: JDK-8308245: Add -proc:full to describe current default
 annotation processing policy
Message-ID: <tG5bHo4F-yfff4SkYJKWnkJeJShObPXOB1uO0I31QoM=.ed702ebd-adc7-4b02-b0ca-290e2ac4a108@github.com>

Quick note on this PR: it proposes to add "-proc:full" as a recognized option to explicitly name the current default policy of performing both annotation processing and subsequent compilation.

(It is possible that in a future release, the default will change, in which case having the -proc:full as an option now will was any transition to a new default.)

I tried to write regressions tests to verify that "-proc:none,full" was rejected by javac; it was duly rejected, but rejected with an Error such that the usual compile/fail jtreg tags to did allow the case to pass.

As "-proc:full" corresponds to the current default, there is no new implementation of this policy in the body of the compiler.

Please also review the CSR [JDK-8308346](https://bugs.openjdk.org/browse/JDK-8308346); the CSR lists proposed updates to the javac "man page."

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

Commit messages:
 - JDK-8308245: Add -proc:full to describe current default annotation processing policy

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

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

From jlahoda at openjdk.org  Thu May 18 13:28:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 May 2023 13:28:50 GMT
Subject: RFR: 8305225: A service broken error despite annotation processor
 generating it if directives listed
Message-ID: <TQLzFVYWrFYcW2HQMCmIYOzUSx6oQ3J9JjtSGgV8A60=.ea3a0960-00c2-45b6-bd92-77cbf340c6ef@github.com>

Consider code like:

module m {
     provides api.Api with impl.Impl; //impl.Impl is not in sources, but is generated by an annotation processor
}


This works fine, until the processor asks for the given module's directives, in which case the build fails with an error like:

testCreateProvidesWithAP/src/m/module-info.java:2: error: the service implementation does not have a default constructor: Test
    provides api.Api with test.Test;


The cause for this error is that when the directive is analyzed, the `test.Test` is attributed (and any errors from that are delayed due to the annotation processing), but even though it attributes to an erroneous type, it will still be checked whether it has the appropriate constructor, etc.

The proposal is to skip the additional checks when the type is an erroneous type. Errors for it should have been reported and handled appropriately (i.e. ignored if resolved by an AP, or reported if not), there does not seem to be any reason to produce any further errors related to the missing type.

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

Commit messages:
 - 8305225: A service broken error despite annotation processor generating it if directives listed

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

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

From vromero at openjdk.org  Thu May 18 16:31:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 May 2023 16:31:52 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var
In-Reply-To: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
Message-ID: <iCJz74bHJulDV7BROBjGxf1gXHRrgIhfAkDvxs0i5L8=.fbe8ccde-5edd-4522-8c13-ee7a93db147b@github.com>

On Tue, 4 Apr 2023 17:34:27 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
> 
> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4199:

> 4197:         Type site;
> 4198: 
> 4199:         if (tree.deconstructor == null) {

my question here would be, this situation can only happen if there are `var`(s) in the record pattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13331#discussion_r1198031790

From vromero at openjdk.org  Thu May 18 16:54:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 May 2023 16:54:53 GMT
Subject: RFR: JDK-8308245: Add -proc:full to describe current default
 annotation processing policy
In-Reply-To: <tG5bHo4F-yfff4SkYJKWnkJeJShObPXOB1uO0I31QoM=.ed702ebd-adc7-4b02-b0ca-290e2ac4a108@github.com>
References: <tG5bHo4F-yfff4SkYJKWnkJeJShObPXOB1uO0I31QoM=.ed702ebd-adc7-4b02-b0ca-290e2ac4a108@github.com>
Message-ID: <7JBzRjwnuLV31LUfwac6R05RoRUL7zO7n7kn2fIa7uI=.9e127380-dd17-46c1-bf3f-d5dab1918841@github.com>

On Thu, 18 May 2023 06:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Quick note on this PR: it proposes to add "-proc:full" as a recognized option to explicitly name the current default policy of performing both annotation processing and subsequent compilation.
> 
> (It is possible that in a future release, the default will change, in which case having the -proc:full as an option now will was any transition to a new default.)
> 
> I tried to write regressions tests to verify that "-proc:none,full" was rejected by javac; it was duly rejected, but rejected with an Error such that the usual compile/fail jtreg tags to did allow the case to pass.
> 
> As "-proc:full" corresponds to the current default, there is no new implementation of this policy in the body of the compiler.
> 
> Please also review the CSR [JDK-8308346](https://bugs.openjdk.org/browse/JDK-8308346); the CSR lists proposed updates to the javac "man page."

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14044#pullrequestreview-1433078088

From abimpoudis at openjdk.org  Thu May 18 16:56:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 16:56:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v27]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <eClQHeZBw5oLORObD6QDhNciuiBbf6AU_h0XkwRm0XY=.6743f023-82e8-4e4c-ae0f-2338618dc90f@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Improve error reporting
 - Address review around `LambdaClassifier`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/804d41af..04e8029f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=25-26

  Stats: 240 lines in 12 files changed: 99 ins; 2 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Thu May 18 16:57:06 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 16:57:06 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
 <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
 <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>
Message-ID: <wcgRdpsEYWuSWvjJ9BRsX8VJAwfjIh_79bMEmMG_BWE=.a7908a03-78b7-41b4-8c1a-4296d8166e8a@github.com>

On Mon, 8 May 2023 12:12:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly. 
>> 
>> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
>> 
>> 
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> index 631b0ce61ac..dc84c89f88e 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>>              return v.visitVarSymbol(this, p);
>>          }
>> -
>> -        @DefinedBy(Api.LANGUAGE_MODEL)
>> -        public boolean isUnnamed() {
>> -            return name.isEmpty();
>> -        }
>>      }
>>  
>>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> index 986f2e9fe89..26ef1c41156 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Attr extends JCTree.Visitor {
>>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>>  
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> index 725a8a5e37d..537635a9490 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Check {
>>      protected static final Context.Key<Check> checkKey = new Conte...
>
>> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly.
>> 
>> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
>> 
>> ```
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> index 631b0ce61ac..dc84c89f88e 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>>              return v.visitVarSymbol(this, p);
>>          }
>> -
>> -        @DefinedBy(Api.LANGUAGE_MODEL)
>> -        public boolean isUnnamed() {
>> -            return name.isEmpty();
>> -        }
>>      }
>>  
>>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> index 986f2e9fe89..26ef1c41156 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Attr extends JCTree.Visitor {
>>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>>  
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> index 725a8a5e37d..537635a9490 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Check {
>>      protected static ...

Thank you for the review @mcimadamore. 

I have also improved error reporting a bit; in the case `_` is present.

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1553341008

From darcy at openjdk.org  Thu May 18 17:09:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 May 2023 17:09:08 GMT
Subject: Integrated: JDK-8308245: Add -proc:full to describe current default
 annotation processing policy
In-Reply-To: <tG5bHo4F-yfff4SkYJKWnkJeJShObPXOB1uO0I31QoM=.ed702ebd-adc7-4b02-b0ca-290e2ac4a108@github.com>
References: <tG5bHo4F-yfff4SkYJKWnkJeJShObPXOB1uO0I31QoM=.ed702ebd-adc7-4b02-b0ca-290e2ac4a108@github.com>
Message-ID: <SwydTHMRlwnduLuGKXNvVeq2CIGZ91FV_LdGvIPTtEs=.473716e6-beff-4fa6-b60b-db6e6eb6e708@github.com>

On Thu, 18 May 2023 06:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Quick note on this PR: it proposes to add "-proc:full" as a recognized option to explicitly name the current default policy of performing both annotation processing and subsequent compilation.
> 
> (It is possible that in a future release, the default will change, in which case having the -proc:full as an option now will was any transition to a new default.)
> 
> I tried to write regressions tests to verify that "-proc:none,full" was rejected by javac; it was duly rejected, but rejected with an Error such that the usual compile/fail jtreg tags to did allow the case to pass.
> 
> As "-proc:full" corresponds to the current default, there is no new implementation of this policy in the body of the compiler.
> 
> Please also review the CSR [JDK-8308346](https://bugs.openjdk.org/browse/JDK-8308346); the CSR lists proposed updates to the javac "man page."

This pull request has now been integrated.

Changeset: 42ecc8a3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42ecc8a37ffc7e4ad7beb49cac7d821c00a5568e
Stats:     43 lines in 3 files changed: 41 ins; 0 del; 2 mod

8308245: Add -proc:full to describe current default annotation processing policy

Reviewed-by: vromero

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

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

From jlaskey at openjdk.org  Thu May 18 19:06:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 May 2023 19:06:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Give subclass priority

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/185532a8..83f31522

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

  Stats: 96 lines in 2 files changed: 43 ins; 30 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From darcy at openjdk.org  Thu May 18 20:41:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 May 2023 20:41:13 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
Message-ID: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>

Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).

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

Commit messages:
 - JDK-8308388: Update description of SourceVersion.RELEASE_21

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

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

From liach at openjdk.org  Thu May 18 20:53:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 May 2023 20:53:49 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
In-Reply-To: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
Message-ID: <HKR7reAxIsmCOfzEVRhjJwBHMUR0yBY6SZllAZHmOHs=.ffc9b1cb-42b8-4221-8a45-6209d90e61dd@github.com>

On Thu, 18 May 2023 20:33:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 76:

> 74:      *  21: pattern matching for switch and record patterns (string
> 75:      *      templates in preview, unnamed patterns and variables, unnamed
> 76:      *      classes and instance main methods in preview

Suggestion:

     *      classes and instance main methods in preview)

missing right parenthesis

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14051#discussion_r1198290931

From abimpoudis at openjdk.org  Thu May 18 21:03:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 21:03:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v28]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <zxWxMqhRQcaI2O3bzLFhNv-4-iV34QTEXhBbFTzd3YA=.64289f44-913c-44df-b0c9-d94a8407e4f1@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

  Reduce the error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/04e8029f..4d693c14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=26-27

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

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

From darcy at openjdk.org  Thu May 18 21:07:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 May 2023 21:07:16 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
 [v2]
In-Reply-To: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
Message-ID: <U4ji9hDoBweyEelf3vGUbYUX3__wOu1sDpemCDV7reo=.e9f2a5e7-8b01-4b34-b3de-a850a4c3682f@github.com>

> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14051/files
  - new: https://git.openjdk.org/jdk/pull/14051/files/6a376493..12754063

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

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

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

From darcy at openjdk.org  Thu May 18 21:07:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 May 2023 21:07:16 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
 [v2]
In-Reply-To: <HKR7reAxIsmCOfzEVRhjJwBHMUR0yBY6SZllAZHmOHs=.ffc9b1cb-42b8-4221-8a45-6209d90e61dd@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
 <HKR7reAxIsmCOfzEVRhjJwBHMUR0yBY6SZllAZHmOHs=.ffc9b1cb-42b8-4221-8a45-6209d90e61dd@github.com>
Message-ID: <SFt0R4tgLnIOGP0M4x5fEMnISw4A0ij0fuK75UANAi0=.cd7a891a-61f5-4e46-b69d-0d24ec8a9c38@github.com>

On Thu, 18 May 2023 20:50:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 76:
> 
>> 74:      *  21: pattern matching for switch and record patterns (string
>> 75:      *      templates in preview, unnamed patterns and variables, unnamed
>> 76:      *      classes and instance main methods in preview
> 
> Suggestion:
> 
>      *      classes and instance main methods in preview)
> 
> missing right parenthesis

Corrected; thanks @liach .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14051#discussion_r1198300273

From iris at openjdk.org  Thu May 18 22:21:49 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 May 2023 22:21:49 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
 [v2]
In-Reply-To: <U4ji9hDoBweyEelf3vGUbYUX3__wOu1sDpemCDV7reo=.e9f2a5e7-8b01-4b34-b3de-a850a4c3682f@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
 <U4ji9hDoBweyEelf3vGUbYUX3__wOu1sDpemCDV7reo=.e9f2a5e7-8b01-4b34-b3de-a850a4c3682f@github.com>
Message-ID: <CeGCzsmfpWtWpeDbTaCuoiiqxKkap1dH638mtkc_4gU=.9c2d729d-648d-4e0e-9762-f02148b05bde@github.com>

On Thu, 18 May 2023 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14051#pullrequestreview-1433528866

From jlahoda at openjdk.org  Thu May 18 22:22:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 May 2023 22:22:25 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v11]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

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

  Disallowing annotations on record patterns.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/69ba2a57..924ca58d

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

  Stats: 102 lines in 7 files changed: 101 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

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

From vromero at openjdk.org  Thu May 18 22:36:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 May 2023 22:36:07 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v11]
In-Reply-To: <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>
Message-ID: <L0P1h0U3ProED8YX9qpAyXV22caL26_XzOjD9pmBIuU=.02fccb99-7910-4ac0-987d-5a525b652a24@github.com>

On Thu, 18 May 2023 22:22:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

minor comment, looks good

test/langtools/tools/javac/T8297602.java line 28:

> 26:  * @bug 8297602
> 27:  * @summary Compiler crash with type annotation and generic record during pattern matching
> 28:  * @compile/fail/ref=T8297602.out -XDrawDiagnostics T8297602.java

I think that this test can be eliminated as new test AnnotationErrors supersedes it.

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1433538513
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1198364712

From abimpoudis at openjdk.org  Fri May 19 08:46:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 08:46:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v29]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <AkRAClXLsnHK9De11yfydeyDPaUZtvtqArwJI39V-1M=.705ce75e-2e22-4b8b-8bc1-cdaa1c07b3c3@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/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 55 commits:

 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed
 - ... and 45 more: https://git.openjdk.org/jdk/compare/924ca58d...9502c1e9

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=28
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Fri May 19 09:11:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 09:11:35 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v2]
In-Reply-To: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
Message-ID: <CIkgcT9luh9sboUZdZZ7Cq2ucibPBPTfcSkKQM-pV4s=.11e22fd7-43e6-4b18-8d9a-28d030b8ea2f@github.com>

> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
> 
> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`

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

  Add more tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13331/files
  - new: https://git.openjdk.org/jdk/pull/13331/files/d5e1624d..c13be556

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

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

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

From abimpoudis at openjdk.org  Fri May 19 09:18:52 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 09:18:52 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v2]
In-Reply-To: <iCJz74bHJulDV7BROBjGxf1gXHRrgIhfAkDvxs0i5L8=.fbe8ccde-5edd-4522-8c13-ee7a93db147b@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
 <iCJz74bHJulDV7BROBjGxf1gXHRrgIhfAkDvxs0i5L8=.fbe8ccde-5edd-4522-8c13-ee7a93db147b@github.com>
Message-ID: <Boft6SyiXmUZ79BJrufH-wZwKywgX1wMhba0LptSQIc=.0ad35d7e-fab0-49bb-8507-ea923bc1a671@github.com>

On Thu, 18 May 2023 16:28:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4199:
> 
>> 4197:         Type site;
>> 4198: 
>> 4199:         if (tree.deconstructor == null) {
> 
> my question here would be, this situation can only happen if there are `var`(s) in the record pattern?

I think so, yes:

https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L846-L869

Initially I thought I could capture this situation before line 816, but then I wouldn't be able to flow an erroneous type from parsing (`types.createErrorType(tree.record.type);`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13331#discussion_r1198737908

From jlahoda at openjdk.org  Fri May 19 12:42:22 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 May 2023 12:42:22 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v12]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

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

  Removing obsolette test, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/924ca58d..b641efca

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

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

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

From abimpoudis at openjdk.org  Fri May 19 13:22:12 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 13:22:12 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v30]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <e1E_3mWUKfkRj2jbBYduRp5bBBKsFuIJXLVtNkRkz7Q=.69781574-751b-4ceb-9529-da0ac9cebec6@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/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 56 commits:

 - Merge branch 'JDK-8300543' into unnamed
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - ... and 46 more: https://git.openjdk.org/jdk/compare/b641efca...87ac7412

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=29
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From vromero at openjdk.org  Fri May 19 20:34:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 May 2023 20:34:53 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v2]
In-Reply-To: <CIkgcT9luh9sboUZdZZ7Cq2ucibPBPTfcSkKQM-pV4s=.11e22fd7-43e6-4b18-8d9a-28d030b8ea2f@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
 <CIkgcT9luh9sboUZdZZ7Cq2ucibPBPTfcSkKQM-pV4s=.11e22fd7-43e6-4b18-8d9a-28d030b8ea2f@github.com>
Message-ID: <8pJWXY-THvoeHLnmZkikzGV6bX4_rve_rOxSAU30Srk=.75420ea9-75ef-4136-b6bf-93798e90a05e@github.com>

On Fri, 19 May 2023 09:11:35 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
>> 
>> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more tests

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13331#pullrequestreview-1435060241

From vromero at openjdk.org  Fri May 19 20:34:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 May 2023 20:34:55 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v2]
In-Reply-To: <Boft6SyiXmUZ79BJrufH-wZwKywgX1wMhba0LptSQIc=.0ad35d7e-fab0-49bb-8507-ea923bc1a671@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
 <iCJz74bHJulDV7BROBjGxf1gXHRrgIhfAkDvxs0i5L8=.fbe8ccde-5edd-4522-8c13-ee7a93db147b@github.com>
 <Boft6SyiXmUZ79BJrufH-wZwKywgX1wMhba0LptSQIc=.0ad35d7e-fab0-49bb-8507-ea923bc1a671@github.com>
Message-ID: <RvYvl3iPBxiunhH4B8grhGHmIEzfS5XcOPmiQqoh2yQ=.0ec36cb4-6b19-4510-a106-abb381c47cad@github.com>

On Fri, 19 May 2023 09:16:17 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4199:
>> 
>>> 4197:         Type site;
>>> 4198: 
>>> 4199:         if (tree.deconstructor == null) {
>> 
>> my question here would be, this situation can only happen if there are `var`(s) in the record pattern?
>
> I think so, yes:
> 
> https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L846-L869
> 
> Initially I thought I could capture this situation before line 816, but then I wouldn't be able to flow an erroneous type from parsing (`types.createErrorType(tree.record.type);`).

ok sounds good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13331#discussion_r1199346549

From darcy at openjdk.org  Fri May 19 21:23:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 May 2023 21:23:54 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
 [v3]
In-Reply-To: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
Message-ID: <vPn-2w-e-jCmacC_4BrRA7OEm18Op7omKftlhg9f2zw=.b60719fd-111b-4fd5-822b-09300ab001ba@github.com>

> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).

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

  Update comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14051/files
  - new: https://git.openjdk.org/jdk/pull/14051/files/12754063..4d15c09f

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

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

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

From iris at openjdk.org  Sat May 20 18:25:48 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 20 May 2023 18:25:48 GMT
Subject: RFR: JDK-8308388: Update description of SourceVersion.RELEASE_21
 [v3]
In-Reply-To: <vPn-2w-e-jCmacC_4BrRA7OEm18Op7omKftlhg9f2zw=.b60719fd-111b-4fd5-822b-09300ab001ba@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
 <vPn-2w-e-jCmacC_4BrRA7OEm18Op7omKftlhg9f2zw=.b60719fd-111b-4fd5-822b-09300ab001ba@github.com>
Message-ID: <DFIv9hZ9OGNOBlQd7UXgVUPHWzLI8HwS3tgM4D0a8vw=.49f59908-72e4-4e72-b5f9-995656fde19f@github.com>

On Fri, 19 May 2023 21:23:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14051#pullrequestreview-1435432956

From liach at openjdk.org  Mon May 22 04:19:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 May 2023 04:19:01 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
In-Reply-To: <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
Message-ID: <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>

On Wed, 17 May 2023 02:32:02 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 incrementally with one additional commit since the last revision:
> 
>   Use @enablePreview in tests in preference to explicit command line flags.

Quick question, since I don't know much about javac, I wonder what happens if you declare a local class or an anonymous class in the ctor prologue? Will that local/anonymous class have a mandated outer instance parameter in its constructor, and thus having access to a newly allocated but non-initialized object via `ClassName.this`?

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1556500408

From jlahoda at openjdk.org  Mon May 22 04:27:21 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 04:27:21 GMT
Subject: Integrated: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <kOU5f1WY3hB8FbzwhbLuh_r_s4gcPN68OXY_aCho-uA=.162483c0-1555-40ba-a077-fd0b68a65a79@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

This pull request has now been integrated.

Changeset: eaa80ad0
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eaa80ad08c949a05abcfa48897654ed52139145b
Stats:     4391 lines in 161 files changed: 2113 ins; 1755 del; 523 mod

8300543: Compiler Implementation for Pattern Matching for switch
8300545: Compiler Implementation for Record Patterns

Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, mcimadamore

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

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

From liangchenblue at gmail.com  Mon May 22 04:28:27 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 21 May 2023 23:28:27 -0500
Subject: javac to emit static flag for local and anonymous classes in static
 contexts
Message-ID: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>

Hello,
While looking at https://bugs.openjdk.org/browse/JDK-8162500 and
https://bugs.openjdk.org/browse/JDK-8162501 I realized that the static
flag in InnerClasses attribute alone is not sufficient to check if an
inner class is static; this flag is simply not emitted on local and
anonymous classes.

A simple workaround would be to check the EnclosingMethod attribute
and check if the enclosing method is static. However, this does not
always work:
Local/anonymous classes can be declared in an initializer block
(instance or static) and anonymous classes can be declared in variable
initialization statements.
In this case, the EnclosingMethod attribute can only report the
enclosing class, since the class appears in multiple methods (for
<init>) or non-reflectable method (<clinit>), and simple attempts to
guess will fail.
Moreover, with the upcoming JEP 447 that adds a pre-initialization
context, local/anonymous classes in the constructor may potentially be
static before the super constructor call, and be instance after the
super constructor call, which complicates the guessing problem.

Thus, I suggest emitting static flags for the InnerClasses attribute
of anonymous/local classes in static/pre-initialization contexts, in
order to allow core reflection to reliably detect the receiver class
of a local or anonymous class. It may also have a cascading effect on
the nested classes within these local/anonymous classes, as shown in
JDK-8162500.

Chen Liang

From abimpoudis at openjdk.org  Mon May 22 07:12:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 07:12:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v31]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <6NR-JJxTB2700ifm7aW-OtW1qgURlT7ge399YU4Zw_0=.59561eef-0dba-4573-a6ba-2bf37e4d8bb0@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/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 102 commits:

 - Merging master into unnamed
 - Merge branch 'JDK-8300543' into unnamed
 - Removing obsolette test, as suggested.
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Disallowing annotations on record patterns.
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - ... and 92 more: https://git.openjdk.org/jdk/compare/eaa80ad0...56686142

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=30
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Mon May 22 08:41:14 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 08:41:14 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v3]
In-Reply-To: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
Message-ID: <b6Em2jIMiBoU4ODgbWGd4xCqD5BVuTgQWJjA6zdvwNI=.c8c51597-946d-4ce4-b496-530671dd6e5e@github.com>

> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
> 
> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`

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

 - Update output for DeconstructionpatternsNonVar example
 - Add more tests
 - 8305582: Compiler crash when compiling record patterns with var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13331/files
  - new: https://git.openjdk.org/jdk/pull/13331/files/c13be556..be22af97

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

  Stats: 466878 lines in 5383 files changed: 381422 ins; 47679 del; 37777 mod
  Patch: https://git.openjdk.org/jdk/pull/13331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13331/head:pull/13331

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

From abimpoudis at openjdk.org  Mon May 22 08:56:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 08:56:29 GMT
Subject: Integrated: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview)
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <eRApHPho3p__GB72ETFQCz9fbPpQYVZIgnW8yG4HJoc=.2d8cbbd1-4eac-44f1-ba47-a8735a213d5c@github.com>

On Wed, 19 Apr 2023 09:47:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

This pull request has now been integrated.

Changeset: 8aa50288
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8aa50288a1a6a853bf4d8d97b1849d5744ed7a32
Stats:     1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod

8302344: Compiler Implementation for Unnamed patterns and variables (Preview)
8307444: java.lang.AssertionError when using unnamed patterns
8307482: Compiler should accept var _ in nested patterns in switch case
8307007: Implementation for javax.lang.model for unnamed variables (Preview)
8308312: Compiler should fail when a local variable declaration does not include an Identifier and does not have an initializer
8308309: Compiler should accept mixed masked and unmasked variables in lambda parameters

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, darcy

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

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

From asotona at openjdk.org  Mon May 22 10:09:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 22 May 2023 10:09:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
Message-ID: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>

This patch disables temporary use of language preview features in JDK.
Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
All redundant use of --enable-preview in the Classfile API tests are also removed.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8308093: Disable language preview features use in JDK

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

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

From abimpoudis at openjdk.org  Mon May 22 11:39:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 11:39:04 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v3]
In-Reply-To: <b6Em2jIMiBoU4ODgbWGd4xCqD5BVuTgQWJjA6zdvwNI=.c8c51597-946d-4ce4-b496-530671dd6e5e@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
 <b6Em2jIMiBoU4ODgbWGd4xCqD5BVuTgQWJjA6zdvwNI=.c8c51597-946d-4ce4-b496-530671dd6e5e@github.com>
Message-ID: <3j_iMAjThj-GVaCovfGW-WLZufUmy98nt31R1OEtVTM=.ff7af8ef-4cca-44fa-97c6-24c8022cae6c@github.com>

On Mon, 22 May 2023 08:41:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
>> 
>> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update output for DeconstructionpatternsNonVar example
>  - Add more tests
>  - 8305582: Compiler crash when compiling record patterns with var

(do not merge, something needs fixing after the rebase)

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

PR Comment: https://git.openjdk.org/jdk/pull/13331#issuecomment-1557060016

From liach at openjdk.org  Mon May 22 11:52:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 May 2023 11:52:50 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <qX58dhWRNH6VktuPwVW2vPwXmVmBNvUtGj2PU8agNT4=.a282ff03-b62c-4290-80f5-834122c6965e@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

The enable-preview for jmh benchmark compilation exists before Classfile API integration, so this should be it.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436460682

From abimpoudis at openjdk.org  Mon May 22 12:45:45 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 12:45:45 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v4]
In-Reply-To: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
Message-ID: <6TKJph0Bl_svXebZy9FAwRHjgA6KXPU6bPC1glnVRk8=.4dcd90f4-4454-47cc-af72-4da46ff6e736@github.com>

> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
> 
> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`

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

 - Introduce check in Flow
 - Merge branch 'master' into fix-#8305582
 - Update output for DeconstructionpatternsNonVar example
 - Add more tests
 - 8305582: Compiler crash when compiling record patterns with var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13331/files
  - new: https://git.openjdk.org/jdk/pull/13331/files/be22af97..cb399ea8

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

  Stats: 7385 lines in 198 files changed: 4251 ins; 2721 del; 413 mod
  Patch: https://git.openjdk.org/jdk/pull/13331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13331/head:pull/13331

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

From erikj at openjdk.org  Mon May 22 12:52:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 May 2023 12:52:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <HIsKi4fLu1ikw-T19ccsiPYu3Kgp172dhS8LJhNFhBA=.7002159b-69e4-46e7-9648-2179e6d96343@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436562362

From alanb at openjdk.org  Mon May 22 13:01:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 13:01:49 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <mrsrNAxweMnt-pB_0o5XkHsb-6MSNNzqpSIzYt11_z0=.28d8a7ab-2795-4e0c-ab4b-8ac51d2aa514@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436580302

From jlahoda at openjdk.org  Mon May 22 13:13:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 13:13:50 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <z6jU68LrWFtDJin3tQPtkHoNFXJyxJPw7ydkh-PMAuY=.68d2748f-179c-48a3-9d35-ec8a765b6d72@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Not sure if I am expert enough on this (just trying to find out if there's a potential we would break builds of users), but might be good to take this through the CSR, just to be sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1557197619

From acobbs at openjdk.org  Mon May 22 14:45:51 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 22 May 2023 14:45:51 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
In-Reply-To: <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
 <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>
Message-ID: <n37ZHmg3QUhLMGDwwHrBKLJnWWg7GMrZ4nIkf86m0CQ=.3bab8f16-70e1-4bdb-a86f-20be563b56ec@github.com>

On Mon, 22 May 2023 04:15:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> what happens if you declare a local class or an anonymous class in the ctor prologue?

You can declare such a class in the prologue, but you can't instantiate it there:

    public static class LocalTest {
        public LocalTest() {
            class Foo {
                Foo() {
                    LocalTest.this.hashCode();
                }
            }
            new Foo();    // ILLEGAL
            super();
            new Foo();    // ALLOWED 
        }
    }       


Note that:
* The prologue includes the statements prior to the superclass constructor *and* the parameter expressions within the superclass constructor invocation
* The rules that apply to the prologue are the *same rules* that previously applied only to parameter expressions within the superclass constructor invocation

So if we "backport" your question to JDK 20, you get the current behavior:

import java.util.concurrent.atomic.*;
public class LocalTest extends AtomicReference<Object> {
    public class Inner {
    }
    public LocalTest(int x) {
        super(new Inner());     // ILLEGAL
    }
    public LocalTest(char x) {
        super(null);
        new Inner();            // ALLOWED
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1557347709

From vromero at openjdk.org  Mon May 22 15:00:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 May 2023 15:00:51 GMT
Subject: RFR: 8305582: Compiler crash when compiling record patterns with
 var [v4]
In-Reply-To: <6TKJph0Bl_svXebZy9FAwRHjgA6KXPU6bPC1glnVRk8=.4dcd90f4-4454-47cc-af72-4da46ff6e736@github.com>
References: <V1cR3eXlNYW791QsFUzm5U7Xpr97KL31wNhO-jPzhxw=.8b6a209f-c7df-472e-95d2-f5e42e042da1@github.com>
 <6TKJph0Bl_svXebZy9FAwRHjgA6KXPU6bPC1glnVRk8=.4dcd90f4-4454-47cc-af72-4da46ff6e736@github.com>
Message-ID: <sClJqux67Oo_eoQXOh9WqqqNeCPbJ4oZcFp0-H0Tb0o=.94f32215-c7c4-4ca1-aadc-ef5d20db9c69@github.com>

On Mon, 22 May 2023 12:45:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> While `var` is not allowed in record pattern position the compiler was not checking it. This PR address this issue, by introducing the relevant error symbols and error types.
>> 
>> e.g., `if (o instanceof ColoredPoint(var(var x, var y), var c)) { }`
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Introduce check in Flow
>  - Merge branch 'master' into fix-#8305582
>  - Update output for DeconstructionpatternsNonVar example
>  - Add more tests
>  - 8305582: Compiler crash when compiling record patterns with var

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13331#pullrequestreview-1436830656

From jlahoda at openjdk.org  Mon May 22 15:20:10 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 15:20:10 GMT
Subject: RFR: 8307814: In the case of two methods with Record Patterns,
 the second one contains a line number from the first method
Message-ID: <AH5dZ4FX82sR4ORrriMxK6tklcePBSKUmWKIViquKGI=.b515a3ae-57a8-4c26-8ff2-6c3eda3b219f@github.com>

`TransPatterns` is not setting the position for `TreeMaker` when unrolling record patterns, leading to weird content of the `LineNumberTable`. The proposal is to set the position.

For tests, it attempts to make the tests more general/allow more strict checks on the LNT.

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

Commit messages:
 - 8307814: In the case of two methods with Record Patterns, the second one contains a line number from the first method

Changes: https://git.openjdk.org/jdk/pull/14087/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14087&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307814
  Stats: 144 lines in 4 files changed: 121 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14087.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14087/head:pull/14087

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

From darcy at openjdk.org  Mon May 22 16:28:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 May 2023 16:28:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <6W0aexRp4fpOKLKKklkPohKXNP6yGQEVHOAKaHotvPQ=.64d8fc08-4c59-4186-b031-b66b215710d6@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1437004246

From darcy at openjdk.org  Mon May 22 16:33:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 May 2023 16:33:57 GMT
Subject: Integrated: JDK-8308388: Update description of
 SourceVersion.RELEASE_21
In-Reply-To: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
References: <6zvMW7I0B69YhbsiQL6O7YNq6xUr3LIj9cC6-h_b0oU=.2d02ad28-8aa8-4020-80fc-c82cf9c844b8@github.com>
Message-ID: <6dqWXl7Xdl7mpFkIODbFXlhOTRBAV9qXs4dDAeUnZc0=.561833da-1188-42dd-ba13-9a914e0eb8fe@github.com>

On Thu, 18 May 2023 20:33:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update description of SourceVersion.RELEASE_21 for the new language features (once they are pushed).

This pull request has now been integrated.

Changeset: d77a4103
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d77a41033a162c2c9bf02d6b8da91f2825320ad8
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8308388: Update description of SourceVersion.RELEASE_21

Reviewed-by: iris

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

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

From vromero at openjdk.org  Mon May 22 16:39:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 May 2023 16:39:49 GMT
Subject: RFR: 8307814: In the case of two methods with Record Patterns,
 the second one contains a line number from the first method
In-Reply-To: <AH5dZ4FX82sR4ORrriMxK6tklcePBSKUmWKIViquKGI=.b515a3ae-57a8-4c26-8ff2-6c3eda3b219f@github.com>
References: <AH5dZ4FX82sR4ORrriMxK6tklcePBSKUmWKIViquKGI=.b515a3ae-57a8-4c26-8ff2-6c3eda3b219f@github.com>
Message-ID: <wJ-Nx52kz1y2Aeu-bMQIGuh1rKLP2wMP4UcoA567EJs=.dddbeebf-bcb6-48b7-add7-273730e4e96f@github.com>

On Mon, 22 May 2023 15:12:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `TransPatterns` is not setting the position for `TreeMaker` when unrolling record patterns, leading to weird content of the `LineNumberTable`. The proposal is to set the position.
> 
> For tests, it attempts to make the tests more general/allow more strict checks on the LNT.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14087#pullrequestreview-1437021254

From archie.cobbs at gmail.com  Mon May 22 17:16:15 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 22 May 2023 12:16:15 -0500
Subject: javac to emit static flag for local and anonymous classes in
 static contexts
In-Reply-To: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>
References: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>
Message-ID: <CANSoFxvmeVQf_A0fP8vimZRT5DAwdqRZoMZ1LwkOvU-AcBe-gg@mail.gmail.com>

Hi Liang,

On Sun, May 21, 2023 at 11:29?PM - <liangchenblue at gmail.com> wrote:

> Thus, I suggest emitting static flags for the InnerClasses attribute
> of anonymous/local classes in static/pre-initialization contexts,
>

Related to your question on PR#13656 ... local/anonymous classes in a
pre-initialization context (which we're now calling a "pre-construction"
context) are not static, they're just not instantiable until after
superclass construction.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230522/d3b9b2fb/attachment.htm>

From godin at openjdk.org  Mon May 22 17:28:53 2023
From: godin at openjdk.org (Evgeny Mandrikov)
Date: Mon, 22 May 2023 17:28:53 GMT
Subject: RFR: 8307814: In the case of two methods with Record Patterns,
 the second one contains a line number from the first method
In-Reply-To: <AH5dZ4FX82sR4ORrriMxK6tklcePBSKUmWKIViquKGI=.b515a3ae-57a8-4c26-8ff2-6c3eda3b219f@github.com>
References: <AH5dZ4FX82sR4ORrriMxK6tklcePBSKUmWKIViquKGI=.b515a3ae-57a8-4c26-8ff2-6c3eda3b219f@github.com>
Message-ID: <bbaPknio9s8NGIsfKNQ-1SMvdRIvL1IllCV-6h_8LX8=.c0d27a7d-2648-4b47-a870-f0f7107c0345@github.com>

On Mon, 22 May 2023 15:12:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `TransPatterns` is not setting the position for `TreeMaker` when unrolling record patterns, leading to weird content of the `LineNumberTable`. The proposal is to set the position.
> 
> For tests, it attempts to make the tests more general/allow more strict checks on the LNT.

Marked as reviewed by godin (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/14087#pullrequestreview-1437103357

From asotona at openjdk.org  Tue May 23 07:27:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 May 2023 07:27:05 GMT
Subject: Integrated: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <_GLlDTboTGCGkynUb5U62e-q8NksFwl0fSGfsBAQzl0=.5f1ef796-ec46-440a-9228-073fc3c2c471@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c4408278
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4408278d1012746c91ba4c31068538850c68d30
Stats:     24 lines in 12 files changed: 0 ins; 22 del; 2 mod

8308093: Disable language preview features use in JDK

Reviewed-by: liach, erikj, alanb, darcy

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

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

From duke at openjdk.org  Tue May 23 15:11:15 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Tue, 23 May 2023 15:11:15 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with digits
Message-ID: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>

Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).

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

Commit messages:
 - missed to remove old message
 - update "module [...] avoid terminal digits" warning

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

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

From alex.buckley at oracle.com  Tue May 23 16:24:13 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 May 2023 09:24:13 -0700
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
Message-ID: <50bf2189-bcc1-dab4-a74c-07ee1f68b9be@oracle.com>

Any warning or error message from javac is seen by tens of thousands of 
people every day, so discussion is warranted, especially if changing an 
older message.

The current message is:

   module name component {0} should avoid terminal digits

The term "module name component" is highly unusual, and the term 
"terminal digits" is hard to understand.

However, it appears the proposed message is:

   module name component {0} ends with a digit. Module names should not 
encode version information in module names

which preserves "module name component", reads strangely (because the 
term "module names" is used twice), and has a grammatical flaw (sentence 
does not end with a period).

Also, the message implies that the digits encode version information 
about the module itself, but that's not true in the rather unfortunate 
cases where an external brand/name is referenced, e.g., a module 
relating to the PKCS11 standard or to the Olympics 2024.

Also, multi-sentence messages are unusual in compiler.properties, so 
let's not have one here. Try this:

   module name {0} should not end with a number, since it may be wrongly 
interpreted as a version number

Alex

On 5/23/2023 8:11 AM, Sebastian Stenzel wrote:
> Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).
> 
> -------------
> 
> Commit messages:
>   - missed to remove old message
>   - update "module [...] avoid terminal digits" warning
> 
> Changes: https://git.openjdk.org/jdk/pull/14099/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14099&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8264488
>    Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>    Patch: https://git.openjdk.org/jdk/pull/14099.diff
>    Fetch: git fetch https://git.openjdk.org/jdk.git pull/14099/head:pull/14099
> 
> PR: https://git.openjdk.org/jdk/pull/14099

From alanb at openjdk.org  Tue May 23 18:05:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 18:05:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
Message-ID: <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>

On Thu, 18 May 2023 19:06:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Give subclass priority

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129:

> 127:      * @throws NoSuchMethodException when not preview and no method found
> 128:      */
> 129:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {

The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202796707

From jlaskey at openjdk.org  Tue May 23 18:12:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 23 May 2023 18:12:09 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
Message-ID: <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>

On Tue, 23 May 2023 18:02:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Give subclass priority
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129:
> 
>> 127:      * @throws NoSuchMethodException when not preview and no method found
>> 128:      */
>> 129:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
> 
> The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon?

Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202804732

From jlaskey at openjdk.org  Tue May 23 20:04:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 23 May 2023 20:04:45 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Fix missing constructor error messages and handle inner class launching
 - Merge branch 'master' into 8306112
 - Issue warning if traditional main not used.
 - Give subclass priority
 - Merge branch 'master' into 8306112
 - Requested Changes #2
 - Update VirtualParser.java
 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16
  Stats: 1235 lines in 28 files changed: 1071 ins; 32 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From acobbs at openjdk.org  Tue May 23 20:26:39 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 May 2023 20:26:39 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v5]
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: <w24poRstpvedWnFnH805ffHzCp0xhi_G3CzM91shl74=.9693d7c1-d4d4-4d21-81a0-6525fde01e39@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 22 commits:

 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - Merge branch 'master' into SuperInit
 - Use @enablePreview in tests in preference to explicit command line flags.
 - Make "statements before super()" support a preview feature.
   
   Thanks to Jim Laskey for help with preview logic.
 - Small refactoring to avoid redundant test.
 - Fix typo in comment.
 - Use for() loop instead of stream for efficiency.
 - Fix typo in comment.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/bddf4838...543a596a

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=04
  Stats: 1402 lines in 24 files changed: 1132 ins; 163 del; 107 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 darcy at openjdk.org  Tue May 23 20:36:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:36:11 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
Message-ID: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>

Time to get JDK 22 underway...

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

Commit messages:
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
 - Add symbol files.
 - Merge branch 'master' into JDK-8306584
 - Problem list failing langtools test.
 - Merge branch 'master' into JDK-8306584
 - ... and 9 more: https://git.openjdk.org/jdk/compare/8474e693...6047c2cb

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306584
  Stats: 5650 lines in 69 files changed: 5596 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From darcy at openjdk.org  Tue May 23 20:36:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:36:12 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <KdtVAlWGgFXRl1nlFdZ2DCSH47sji2MXXA1Y8EwsWe4=.ebf0678c-3174-4524-9522-308b8bee0957@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Typical start-of-JDK-next changes. As usual, the bulk of the PR is the symbol file information to support "javac --release 21".

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

PR Comment: https://git.openjdk.org/jdk/pull/13567#issuecomment-1560085911

From erikj at openjdk.org  Tue May 23 20:41:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 May 2023 20:41:58 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <Mp05bI_h03-YkavqrCuntjcrKjElMipkJFB4_FM08G4=.a8f4bff8-4ebb-4af1-b693-5e1777d77de1@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440532444

From jjg at openjdk.org  Tue May 23 20:42:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 May 2023 20:42:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

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

> 24: /*
> 25:  * @test
> 26:  * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453 8286035 8306586

At some point, this line should be wrapped

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

> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);

when do these get updated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202974585
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202976605

From darcy at openjdk.org  Tue May 23 20:52:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:52:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
Message-ID: <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>

On Tue, 23 May 2023 20:38:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> test/langtools/tools/javac/versions/Versions.java line 93:
> 
>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);
> 
> when do these get updated?

Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202991806

From iris at openjdk.org  Tue May 23 21:20:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 May 2023 21:20:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <Exzu8vMVI6iI5zUy2UC5QChQ-xBwLqp1OZSA4qeQcNA=.dd4263a5-5841-416b-8aac-2adf65f77956@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440582657

From duke at openjdk.org  Wed May 24 05:37:53 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Wed, 24 May 2023 05:37:53 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <50bf2189-bcc1-dab4-a74c-07ee1f68b9be@oracle.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <50bf2189-bcc1-dab4-a74c-07ee1f68b9be@oracle.com>
Message-ID: <PIZfYIrmfoKKFA4w1Vdbyt0O7p4VxF5M3rN4pi4Trs8=.c450369b-b85e-49b2-897d-ba93525e746e@github.com>

On Wed, 24 May 2023 02:33:40 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:

> module name {0} should not end with a number, since it may be wrongly interpreted as a version number

Still confusing: The warning is not to avoid module consumers from _wrongly interpreting_ terminal digits such as in PKCS11 as a version number. It rather warns the module publisher to not append any version number to the module name.

How about: `module name {0} ends on terminal digits, which must not encode a version number`

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

PR Comment: https://git.openjdk.org/jdk/pull/14099#issuecomment-1560482551

From duke at openjdk.org  Wed May 24 08:04:12 2023
From: duke at openjdk.org (Naoki Kishida)
Date: Wed, 24 May 2023 08:04:12 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
Message-ID: <XEicoJ7OAd0ACesTx7abd4s9AJd8Dw8_mBYVnVuTjOM=.cd4fdd9f-5802-4317-bf45-c2cc685cb4b8@github.com>

On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Fix missing constructor error messages and handle inner class launching
>  - Merge branch 'master' into 8306112
>  - Issue warning if traditional main not used.
>  - Give subclass priority
>  - Merge branch 'master' into 8306112
>  - Requested Changes #2
>  - Update VirtualParser.java
>  - Merge branch 'master' into 8306112
>  - Refactor source code launcher
>  - Typo
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

Can we use enum?


public class Main{
  enum Foo {A, B}
  void main() {
    System.out.println(Foo.A);
  }
}

? OK


enum Foo {A, B}
void main() {
  System.out.println(Foo.A);
}

?error(enumtest.java is the filename)

enumtest.java:1: Error : package enumtest does not exist
  enum Foo {A, B}
  ^

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

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560631740

From jlaskey at openjdk.org  Wed May 24 12:00:11 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 12:00:11 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
Message-ID: <S4B3WpuOGBcDRydBsbfDqMymBr7RLc5DsZWhAKGhST4=.f5fe57c9-5884-4887-803e-0052662ffb7e@github.com>

On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Fix missing constructor error messages and handle inner class launching
>  - Merge branch 'master' into 8306112
>  - Issue warning if traditional main not used.
>  - Give subclass priority
>  - Merge branch 'master' into 8306112
>  - Requested Changes #2
>  - Update VirtualParser.java
>  - Merge branch 'master' into 8306112
>  - Refactor source code launcher
>  - Typo
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

Good catch - will look into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560984490

From jlaskey at openjdk.org  Wed May 24 14:12:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 14:12:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v18]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <7v5CJ2-10s6fliOBRJw5y_QyZL-TNkBsi56E5vokdG8=.c0ffcd0c-6b8d-41f5-8b20-44e3270cdb9a@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Allow unqualified access to unnamed class (internally visible)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/b55f82f8..e590c736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16-17

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

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

From acobbs at openjdk.org  Wed May 24 14:37:00 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 May 2023 14:37:00 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v4]
In-Reply-To: <mBh6K54Fd-ecenOt_8j7-L8gZhjlLweAmyi9Yvn9Bk4=.07a9ba17-c6b6-4de1-a1c7-20c095fa2f4e@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <mBh6K54Fd-ecenOt_8j7-L8gZhjlLweAmyi9Yvn9Bk4=.07a9ba17-c6b6-4de1-a1c7-20c095fa2f4e@github.com>
Message-ID: <Qto_T041ircwY9JmDGyijIjkqfWZIL4MVApMF5bxFYY=.f9f77b5a-8ea7-4e91-a25e-0a8ccdf31b4a@github.com>

On Wed, 26 Apr 2023 02:58:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The fix for [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) created a new bug in which a program like this:
>> 
>> package p;;
>> 
>> would be rejected.
>> 
>> This is due to the previous fix swallowing all the semicolons. Instead, in the case of semicolons followed by EOF, it needs to swallow all but the last one.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8305671
>  - Consume extra semicolons in a more straightforward way.
>  - Merge branch 'master' into JDK-8305671
>  - Use ToolBox and add more tests per review suggestion.
>  - Allow a package declaration followed (only) by multiple commas.

pingbot

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

PR Comment: https://git.openjdk.org/jdk/pull/13361#issuecomment-1561279226

From jlaskey at openjdk.org  Wed May 24 15:42:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 15:42:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v19]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <tyAD2PL7pU50zkaaQgFOB8y-jYzlJMbJ6kak2Tt6cPM=.89dd834d-d5db-4a47-b181-e87d6a9715d3@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Ignore SKIPs (semicolon class declarations)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/e590c736..8ccb9502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17-18

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

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

From alex.buckley at oracle.com  Wed May 24 17:08:58 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 24 May 2023 10:08:58 -0700
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <PIZfYIrmfoKKFA4w1Vdbyt0O7p4VxF5M3rN4pi4Trs8=.c450369b-b85e-49b2-897d-ba93525e746e@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <50bf2189-bcc1-dab4-a74c-07ee1f68b9be@oracle.com>
 <PIZfYIrmfoKKFA4w1Vdbyt0O7p4VxF5M3rN4pi4Trs8=.c450369b-b85e-49b2-897d-ba93525e746e@github.com>
Message-ID: <1f70e51d-ac7a-25a9-57dc-f908a9e8c0e7@oracle.com>

On 5/23/2023 10:37 PM, Sebastian Stenzel wrote:
> On Wed, 24 May 2023 02:33:40 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
>> module name {0} should not end with a number, since it may be wrongly interpreted as a version number
> 
> Still confusing: The warning is not to avoid module consumers from _wrongly interpreting_ terminal digits such as in PKCS11 as a version number. It rather warns the module publisher to not append any version number to the module name.
> 
> How about: `module name {0} ends on terminal digits, which must not encode a version number`

"terminal digits" means "the digits at the end", so there's no need to 
say "ends on" -- it would just be "module name {0} has terminal digits". 
In any case, "terminal digits" is a dense phrase that appeals to the 
technical construct of "Java digit" without spelling it out -- this is 
hard work for readers -- "number" is more straightforward.

Also, the phrase "must not" is inappropriate for a warning message. 
"must not" is for error messages.

Here's a rewrite of your suggestion:

   module name {0} ends with a number, which should not encode a version

The good thing about this text is that it starts by stating a fact, and 
only then (after the comma) presenting a judgement. That's how we phrase 
run-time warnings for illegal reflective access and for dynamic 
installation of a Security Manager 
(https://openjdk.org/jeps/411#Issue-warnings). However, javac warnings 
need to be brief, and tend to skip directly to the judgement that X is bad.

Also, this text is pretty easy to read as saying that the number 
_currently_ encodes a version, which will confuse the org.foo.lib.pkcs11 
crowd whose number is not a version.

Here's a plainspoken warning to the module publisher about what they 
have done by calling their module `com.bar.lib_v2` or `org.baz.framework3`:

   module name {0} ends with a number that looks like a version

Alex

From abimpoudis at openjdk.org  Wed May 24 17:58:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 May 2023 17:58:02 GMT
Subject: RFR: 8308727: Compiler should accept final unnamed variables in
 try-with-resources
Message-ID: <6YIbKUrlvu2iDvXij7TXdqk5Xpi6YWTbeHdQBQqutQA=.a2ea986c-4ae0-4e3d-8779-073575e03f60@github.com>

This PR addresses the bug with `final` but also with annotations on local variables within try-with-resources.

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

Commit messages:
 - 8308727: Compiler should accept final unnamed variables in try-with-resources

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

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

From jlahoda at openjdk.org  Wed May 24 18:34:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 May 2023 18:34:56 GMT
Subject: RFR: 8308727: Compiler should accept final unnamed variables in
 try-with-resources
In-Reply-To: <6YIbKUrlvu2iDvXij7TXdqk5Xpi6YWTbeHdQBQqutQA=.a2ea986c-4ae0-4e3d-8779-073575e03f60@github.com>
References: <6YIbKUrlvu2iDvXij7TXdqk5Xpi6YWTbeHdQBQqutQA=.a2ea986c-4ae0-4e3d-8779-073575e03f60@github.com>
Message-ID: <90Ydvi3OulVOJJnLxE_pEvrDuYWQvouYiRHzpifmlpU=.a65a2ee9-04d3-4bda-a159-c64f2bc26442@github.com>

On Wed, 24 May 2023 17:51:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses the bug with `final` but also with annotations on local variables within try-with-resources.

Seems reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14130#pullrequestreview-1442527151

From jjg at openjdk.org  Wed May 24 20:02:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:02:59 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
Message-ID: <RGCbJI6iR3v4LMfFjsvUwDtOb6HS94uJMLXwX5P4KYk=.65f58098-d578-4386-9433-094b91c038eb@github.com>

On Tue, 23 May 2023 12:25:07 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

> Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1864:

> 1862: # 0: name
> 1863: compiler.warn.poor.choice.for.module.name=\
> 1864:     module name component {0} ends with a digit. Module names should not encode version information in module names

Duplicate text

_Module names_. should not ... in _module names_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14099#discussion_r1204697085

From jjg at openjdk.org  Wed May 24 20:09:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:09:00 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>
Message-ID: <5khCaXNZ5w1naNAF1mAOKR0Xez3YTrBSG9L6b1STy9g=.92dc074d-562e-41d1-8758-08100b2bd092@github.com>

On Thu, 18 May 2023 05:22:49 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
>> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
>> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
>> to solve this issue. And a corresponding test case is added.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude the PrettyChecker.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1442670406

From jjg at openjdk.org  Wed May 24 20:19:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:19:54 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
Message-ID: <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>

On Mon, 15 May 2023 14:43:15 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
> 
> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
> 
> The error message for the warning was enhanced to refer to the default style for the `<a>` element.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 80:

> 78: dc.tag.not.allowed = element not allowed in documentation comments: <{0}>
> 79: dc.tag.not.allowed.inline.element = block element not allowed within inline element <{1}>: {0}
> 80: dc.tag.not.allowed.element.default.style = block element not allowed within element <{1}> with default style: {0}

Is it possible to improve the wording?

As written, it is ambiguous/confusing: it seems like `{0}` is the default style, which I don't think is what you intend.
Also, inconsistent pointy brackets `<{1}>` but just `{0}`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13990#discussion_r1204716808

From gli at openjdk.org  Thu May 25 03:29:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 25 May 2023 03:29:08 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
 <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
 <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>
Message-ID: <VfNSjAwG1Wkn0VydTUERZeu9fb_D-s8HwyLuXTYyetk=.b798dd84-3be7-4512-b556-25035abd548d@github.com>

On Tue, 9 May 2023 14:44:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
>> 
>> If there is something between the tag name and the quoted string, 
>> the method `quotedString` is never invoked by method `TagParser::parse`.
>> So such case seems not related to this bug. Do I miss anything?
>
>> > Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
>> 
>> If there is something between the tag name and the quoted string, the method `quotedString` is never invoked by method `TagParser::parse`. So such case seems not related to this bug. Do I miss anything?
> 
> I was just trying to imagine a case where `newline` might be true after the tag name has been read.

@jonathan-gibbons Thanks for the review. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1562203426

From gli at openjdk.org  Thu May 25 03:29:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 25 May 2023 03:29:08 GMT
Subject: Integrated: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <29RnUtDlreM20sLXxbVoVShDtKgnQbGha0E8mZ_qyQk=.92ffe700-31df-489e-bf08-b71ef5fc7008@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: a291f002
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a291f002cdd3daffeccab36ec713d9e59fe50f16
Stats:     46 lines in 3 files changed: 43 ins; 0 del; 3 mod

8288619: Unexpected parsing for @see

Reviewed-by: jjg

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

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

From duke at openjdk.org  Thu May 25 04:26:54 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Thu, 25 May 2023 04:26:54 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <1f70e51d-ac7a-25a9-57dc-f908a9e8c0e7@oracle.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <1f70e51d-ac7a-25a9-57dc-f908a9e8c0e7@oracle.com>
Message-ID: <Z3MJ1CW4JIBWQD4_juvx0vqZn8vwcy0dGia2kZtq5iM=.59422a7a-2d8d-4a54-8833-7a6fd9b25990@github.com>

On Thu, 25 May 2023 00:45:39 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:

> "terminal digits" means "the digits at the end", so there's no need to say "ends on" -- it would just be "module name {0} has terminal digits". In any case, "terminal digits" is a dense phrase that appeals to the technical construct of "Java digit" without spelling it out -- this is hard work for readers -- "number" is more straightforward.

I agree on the "terminal" and "ends on" being redundant.

However, digits don't necessarily need to be a number. This depends on whether or not they are used to denote a numeric value (see example below). Without context, they are just a set of characters. Since we strive for a concise error message, we should be very precise here.

> Also, the phrase "must not" is inappropriate for a warning message. "must not" is for error messages.

Agreed, that's why the warning says "should not" to the digits, while pointing out that it "must not" be a version number.

> 
> Here's a rewrite of your suggestion:
> 
> module name {0} ends with a number, which should not encode a version

This would be incorrect, though. While ["the specification was revised to allow digits at the end of module names"](https://openjdk.org/projects/jigsaw/spec/minutes/2017-05-18#VersionsInModuleNames) for non-version cases, we still don't want to allow adding version numbers (according to my understanding of the whole discussion about it). Hence, "should not" in conjunction with "encode a version" is too soft.

> The good thing about this text is that it starts by stating a fact, and only then (after the comma) presenting a judgement. That's how we phrase run-time warnings for illegal reflective access and for dynamic installation of a Security Manager (https://openjdk.org/jeps/411#Issue-warnings). However, javac warnings need to be brief, and tend to skip directly to the judgement that X is bad.

If the compiler can be sure about its judgement, that is fine. In this case, the compiler can not really make such a judgement. It requires human intelligence to judge whether one or more digits denote a number and whether this number denotes a version:

| module name        | digit? | number? | version? | judgement |
|--------------------|--------|---------|----------|-----------|
| com.bar.f00        | ??      | ?       | ?        | allowed   |
| com.example.pkcs11 | ??      | ??       | ?        | allowed   |
| org.openjdk.java17 | ??      | ??       | ??        | forbidden |

Hence, directly skipping to the judgement without stating the fact might be a bit too hasty. But I believe we can put both, the observation and the cause of the problem in a very concise message without dropping any information.

> [...]
> module name {0} ends with a number that looks like a version

Quite good. But for the reasons stated above, let's stick to "terminal digits":

`terminal digits in module name {0} look like a version number`

Being semantically closer to the original warning also has the side effect that e.g. existing discussions on Stack Overflow [can easier be found](https://stackoverflow.com/search?q=terminal+digits+in+module+name) if devs look for help when when encountering the updated warning.

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

PR Comment: https://git.openjdk.org/jdk/pull/14099#issuecomment-1562245181

From asotona at openjdk.org  Thu May 25 07:52:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 07:52:39 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v3]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <SLTVrQBnbiRhp6qW3VJtrFlzJ7BzA877v-aRDY3_doc=.f7d3a15d-83a0-496e-98df-01531ff7f7a5@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> 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 217 commits:

 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - Merge branch 'master' into JDK-8294969-javap
 - ... and 207 more: https://git.openjdk.org/jdk/compare/bfcae68e...f704791a

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=02
  Stats: 3758 lines in 37 files changed: 896 ins; 1723 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From abimpoudis at openjdk.org  Thu May 25 08:13:06 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 May 2023 08:13:06 GMT
Subject: Integrated: 8308727: Compiler should accept final unnamed variables in
 try-with-resources
In-Reply-To: <6YIbKUrlvu2iDvXij7TXdqk5Xpi6YWTbeHdQBQqutQA=.a2ea986c-4ae0-4e3d-8779-073575e03f60@github.com>
References: <6YIbKUrlvu2iDvXij7TXdqk5Xpi6YWTbeHdQBQqutQA=.a2ea986c-4ae0-4e3d-8779-073575e03f60@github.com>
Message-ID: <mn8ce1aNVGXSITKtP_fklJlX_hm0EmTvhPmIut7zfWc=.b16adf1c-7a95-4947-aba4-757ca8c9e6ed@github.com>

On Wed, 24 May 2023 17:51:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses the bug with `final` but also with annotations on local variables within try-with-resources.

This pull request has now been integrated.

Changeset: 4500bb7a
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4500bb7a676b9208337590880cfde45f264e4baf
Stats:     11 lines in 2 files changed: 10 ins; 0 del; 1 mod

8308727: Compiler should accept final unnamed variables in try-with-resources

Reviewed-by: jlahoda

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

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

From cstein at openjdk.org  Thu May 25 09:01:21 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 May 2023 09:01:21 GMT
Subject: Integrated: 8144891: ToolBox should use java.nio.file.Path internally, 
 instead of java.io.File
Message-ID: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>

Please review this change set that gets rid of all direct `java.io.File` usages by introducing new constants in `ToolBox`, based on system property values.

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

Commit messages:
 - Update test/langtools/tools/lib/toolbox/ToolBox.java
 - Update JavacTask.java
 - 8144891: ToolBox should use java.nio.file.Path internally, instead of java.io.File

Changes: https://git.openjdk.org/jdk/pull/14015/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14015&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8144891
  Stats: 24 lines in 6 files changed: 5 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14015/head:pull/14015

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

From jjg at openjdk.org  Thu May 25 09:01:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 May 2023 09:01:22 GMT
Subject: Integrated: 8144891: ToolBox should use java.nio.file.Path
 internally, instead of java.io.File
In-Reply-To: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
References: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
Message-ID: <B2qrAghgwkSTW18sQTJYDNW0vO8OxxyC5lpP3RFNNxg=.45dccdf7-5ff2-4a0b-bb73-cd433b0ddce0@github.com>

On Tue, 16 May 2023 14:25:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set that gets rid of all direct `java.io.File` usages by introducing new constants in `ToolBox`, based on system property values.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14015#pullrequestreview-1442677070

From cstein at openjdk.org  Thu May 25 09:01:24 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 May 2023 09:01:24 GMT
Subject: Integrated: 8144891: ToolBox should use java.nio.file.Path
 internally, instead of java.io.File
In-Reply-To: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
References: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
Message-ID: <NVJg7SoXzMWk05aETMyUTtjiqN466_nY8eulUhuuw2k=.1b13a7f9-0053-49c7-a3df-d65ff841094e@github.com>

On Tue, 16 May 2023 14:25:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set that gets rid of all direct `java.io.File` usages by introducing new constants in `ToolBox`, based on system property values.

test/langtools/tools/lib/toolbox/ToolBox.java line 95:

> 93:     public static final String pathSeparator = System.getProperty("path.separator");
> 94:     /** The platform file separator character. */
> 95:     public static char fileSeparatorChar = System.getProperty("file.separator").toCharArray()[0];

Suggestion:

    public static char fileSeparatorChar = System.getProperty("file.separator").charAt(0);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14015#discussion_r1195410125

From cstein at openjdk.org  Thu May 25 09:01:26 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 May 2023 09:01:26 GMT
Subject: Integrated: 8144891: ToolBox should use java.nio.file.Path internally, 
 instead of java.io.File
In-Reply-To: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
References: <yBGSxYxqiQaT-NvRSjHjgnsBPzSamH4k31AujrnAWzU=.440c5427-560e-40ae-b1f4-f8a6e84d7da1@github.com>
Message-ID: <CZXl7xw62SDZO8Woe2QBWopgpotarpdQyJw2t_FZxDs=.191ef788-a155-492d-af9b-890a9b94f150@github.com>

On Tue, 16 May 2023 14:25:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set that gets rid of all direct `java.io.File` usages by introducing new constants in `ToolBox`, based on system property values.

This pull request has now been integrated.

Changeset: d8771344
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d87713440a1ddb830e87171b009efe9507e644cb
Stats:     24 lines in 6 files changed: 5 ins; 8 del; 11 mod

8144891: ToolBox should use java.nio.file.Path internally, instead of java.io.File

Reviewed-by: jjg

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

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

From jlaskey at openjdk.org  Thu May 25 14:32:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 25 May 2023 14:32:44 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
  
  Author: Jan Lahoda <jlahoda at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/8ccb9502..cfac821a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18-19

  Stats: 32 lines in 4 files changed: 24 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From alex.buckley at oracle.com  Thu May 25 17:29:27 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 25 May 2023 10:29:27 -0700
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <Z3MJ1CW4JIBWQD4_juvx0vqZn8vwcy0dGia2kZtq5iM=.59422a7a-2d8d-4a54-8833-7a6fd9b25990@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <1f70e51d-ac7a-25a9-57dc-f908a9e8c0e7@oracle.com>
 <Z3MJ1CW4JIBWQD4_juvx0vqZn8vwcy0dGia2kZtq5iM=.59422a7a-2d8d-4a54-8833-7a6fd9b25990@github.com>
Message-ID: <4bb4d7b0-0bb4-ba22-6719-d6b31face048@oracle.com>

On 5/24/2023 9:26 PM, Sebastian Stenzel wrote:
> Quite good. But for the reasons stated above, let's stick to
> "terminal digits":
> 
> `terminal digits in module name {0} look like a version number`
> 
> Being semantically closer to the original warning also has the side
> effect that e.g. existing discussions on Stack Overflow [can easier
> be
> found](https://stackoverflow.com/search?q=terminal+digits+in+module+name)
> if devs look for help when when encountering the updated warning.

So, from old:

   module name component {0} should avoid terminal digits

to new:

   terminal digits in module name {0} look like a version number

The new warning is good, for two reasons:

1. Saying that the terminal digits are _in_ the module name is smart. It 
clarifies that "terminal" means "at the end of the module name" rather 
than being a term of art for the Java language or module system. I can 
accept the use of "digits" much more easily now.

2. It is now clear that the warning is drawing a connection between the 
physical presence of digits and the logical presence of a version 
number. That's a big improvement over the old warning. The fact that the 
connection is _objectionable_ is implied by the warning being given in 
the first place, rather than stern words inside the warning.


Ideally, there would be a sibling warning in compiler.properties for 
when there's only one terminal digit:

   terminal digit in module name {0} looks like a version number

Alex

From darcy at openjdk.org  Fri May 26 06:10:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 06:10:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
Message-ID: <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>

On Thu, 25 May 2023 14:32:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
>   
>   Author: Jan Lahoda <jlahoda at openjdk.org>

test/jdk/tools/launcher/InstanceMainTest.java line 31:

> 29:  * @run main InstanceMainTest
> 30:  */
> 31: public class InstanceMainTest extends TestHelper {

By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
Are there tests for record and enum main method operation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206277064

From forax at openjdk.org  Fri May 26 06:23:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 26 May 2023 06:23:05 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
 <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
Message-ID: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>

On Fri, 26 May 2023 06:07:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
>>   
>>   Author: Jan Lahoda <jlahoda at openjdk.org>
>
> test/jdk/tools/launcher/InstanceMainTest.java line 31:
> 
>> 29:  * @run main InstanceMainTest
>> 30:  */
>> 31: public class InstanceMainTest extends TestHelper {
> 
> By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
> Are there tests for record and enum main method operation?

You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206285923

From jlaskey at openjdk.org  Fri May 26 13:08:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:08:08 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
 <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
 <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>
Message-ID: <sr8jTPL0cPzFBESgc16g0Ae9ZlgeWbhLjCWFHIyo57Y=.1be4f55a-f11a-4e94-86ad-c4fa631d434b@github.com>

On Fri, 26 May 2023 06:20:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> test/jdk/tools/launcher/InstanceMainTest.java line 31:
>> 
>>> 29:  * @run main InstanceMainTest
>>> 30:  */
>>> 31: public class InstanceMainTest extends TestHelper {
>> 
>> By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
>> Are there tests for record and enum main method operation?
>
> You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static.

updating tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206753443

From jlaskey at openjdk.org  Fri May 26 13:19:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:19:49 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v21]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <Lo-_0KThx6XDZgRAmRQu-cGegc39FG8ql8OARg525SY=.67fe43d3-40ae-49b0-8d25-8e49de6b2a0f@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add main  tests for inferface/enum/record

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/cfac821a..4e54c17a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19-20

  Stats: 128 lines in 2 files changed: 27 ins; 22 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlaskey at openjdk.org  Fri May 26 13:22:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:22:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v22]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/4e54c17a..06aa43ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20-21

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

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

From duke at openjdk.org  Fri May 26 14:36:56 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Fri, 26 May 2023 14:36:56 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <4bb4d7b0-0bb4-ba22-6719-d6b31face048@oracle.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <4bb4d7b0-0bb4-ba22-6719-d6b31face048@oracle.com>
Message-ID: <DGjLkuG39k-vjo6R_O4KXpm9PaxtHxBSV314-KYIf7g=.6b22457c-0242-433a-a86d-ac85600c393b@github.com>

On Fri, 26 May 2023 09:00:40 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:

> Ideally, there would be a sibling warning in compiler.properties for
> when there's only one terminal digit:
> 
> terminal digit in module name {0} looks like a version number

That would be smoother, but since this warning is not end-user-facing and its meaning is perfectly clear regardless of cardinality, I would argue it doesn't justify the added complexity to count the number of digits.

Would you sponsor this PR? Then I would change the message as discussed (with digits in plural form).

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

PR Comment: https://git.openjdk.org/jdk/pull/14099#issuecomment-1564489429

From alex.buckley at oracle.com  Fri May 26 15:35:10 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 26 May 2023 08:35:10 -0700
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <DGjLkuG39k-vjo6R_O4KXpm9PaxtHxBSV314-KYIf7g=.6b22457c-0242-433a-a86d-ac85600c393b@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <4bb4d7b0-0bb4-ba22-6719-d6b31face048@oracle.com>
 <DGjLkuG39k-vjo6R_O4KXpm9PaxtHxBSV314-KYIf7g=.6b22457c-0242-433a-a86d-ac85600c393b@github.com>
Message-ID: <0faf8f88-447b-1efa-26ec-b33fa96a6d53@oracle.com>

On 5/26/2023 7:36 AM, Sebastian Stenzel wrote:
> On Fri, 26 May 2023 09:00:40 GMT, Alex Buckley
> <alex.buckley at oracle.com> wrote:
> 
>> Ideally, there would be a sibling warning in compiler.properties
>> for when there's only one terminal digit:
>> 
>> terminal digit in module name {0} looks like a version number
> 
> That would be smoother, but since this warning is not end-user-facing
> and its meaning is perfectly clear regardless of cardinality, I would
> argue it doesn't justify the added complexity to count the number of
> digits.

"not end-user-facing"? Isn't this warning emitted by javac to 
potentially any Java developer? That's a lot of developers. Also, the 
text of any javac message guides how the creators of other tools (e.g., 
IDEs) present functionality related to the message (e.g., code hints 
about module names).

One of my colleagues will have to sponsor the PR. I'll leave it to them 
to decide whether a warning in singular form is worthwhile and/or has 
precedent in compiler.properties.

Alex

From acobbs at openjdk.org  Fri May 26 21:32:20 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 May 2023 21:32:20 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v6]
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: <cA2Ib1xUESlaN_rbKu0migmJCwnioAEuoakc6refeLQ=.49fe6bc9-91ef-4141-8df7-80e88f91359d@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 24 commits:

 - Fix mistake in previous merge commit 80ba6be4.
 - Merge branch 'master' into SuperInit
 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - Merge branch 'master' into SuperInit
 - Use @enablePreview in tests in preference to explicit command line flags.
 - Make "statements before super()" support a preview feature.
   
   Thanks to Jim Laskey for help with preview logic.
 - Small refactoring to avoid redundant test.
 - Fix typo in comment.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/c72b5474...276e449d

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=05
  Stats: 1400 lines in 24 files changed: 1132 ins; 163 del; 105 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 darcy at openjdk.org  Fri May 26 21:37:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 21:37:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v22]
In-Reply-To: <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>
Message-ID: <Lo3jFDnzX76d9nUPEoxPjXeUGpu0GJlV6qzPeZ0TuFE=.70f9877c-8823-4cb7-91dc-0369c70d44bb@github.com>

On Fri, 26 May 2023 13:22:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing whitespace

In case I overlooked them, it would be good to have some core reflection tests of what a unnamed class looks like reflectively, basically a core reflection analogue to the draft javac/javax.lang.model test:

https://github.com/openjdk/jdk/pull/14140/files#diff-106fc5b2c4d391546c7fa8a75e68fbd963733964f8f7ddf577606b5afda9b889

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

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1564983686

From jwaters at openjdk.org  Mon May 29 01:16:56 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 29 May 2023 01:16:56 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <hmXa9GRj9Rg7spZreZWx7YQ9O2Qv59Y6YKCf3sn0_fU=.6d6ae499-b9f6-4e5a-9e8d-0779b992ca1c@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

I've created the CSR in full, not sure what to do from here on though

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1566348087

From jwaters at openjdk.org  Mon May 29 02:55:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 29 May 2023 02:55:03 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <b8BgeibFU9L8BbAinCI4SFipMKFppO84pWKgU2za2_I=.82351034-061e-49f6-b0ab-4c88742536be@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Going to page @vicente-romero-oracle for help

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1566419958

From duke at openjdk.org  Mon May 29 15:50:55 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Mon, 29 May 2023 15:50:55 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <0faf8f88-447b-1efa-26ec-b33fa96a6d53@oracle.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <0faf8f88-447b-1efa-26ec-b33fa96a6d53@oracle.com>
Message-ID: <uR8e456fuQtdc4cS2fW2L5O7yGQUnMJNcTQcNXrCeII=.578f6c74-e088-4711-b789-7669e9eb59e3@github.com>

On Fri, 26 May 2023 19:30:39 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:

> Isn't this warning emitted by javac to
> potentially any Java developer?

If this was a message popping up at runtime to my grandma, I would tend to agree. However, as you said yourself: We are addressing developers, not end users. Name one single developer who hasn't at least once written some message like `%d new message(s) in your inbox`.

But if you are proposing to split the message into two and add complexity to the compiler just for nicer formatting, this would be both out of scope of the issue and also something that needs to be decided by somebody who is more involved with long term maintenance than me. Therefore please CC whoever is responsible for making such decisions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14099#issuecomment-1567293274

From abimpoudis at openjdk.org  Mon May 29 16:00:59 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 29 May 2023 16:00:59 GMT
Subject: RFR: 8309054: Parsing of erroneous patterns succeeds
Message-ID: <_ao5L32MXy38nGeGgj8dTErH7yV5SHcUTgU07P0oCN0=.9d965cf7-bf99-4cb0-bf5d-1015f44f4e84@github.com>

Moving the logic of type test pattern detection from `parsePattern` to `variableDeclaratorRest` makes the logic of the latter too complex. The regression in this JBS would be fixed by introducing two additional if-guards (e.g., `if (!typePattern)`); conditional on whether we are detecting a local variable or a type pattern. This PR removes this.

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

Commit messages:
 - 8309054: Parsing of erroneous patterns succeeds

Changes: https://git.openjdk.org/jdk/pull/14205/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309054
  Stats: 75 lines in 3 files changed: 38 ins; 9 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14205.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14205/head:pull/14205

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

From jlahoda at openjdk.org  Tue May 30 11:38:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 May 2023 11:38:56 GMT
Subject: RFR: 8309054: Parsing of erroneous patterns succeeds
In-Reply-To: <_ao5L32MXy38nGeGgj8dTErH7yV5SHcUTgU07P0oCN0=.9d965cf7-bf99-4cb0-bf5d-1015f44f4e84@github.com>
References: <_ao5L32MXy38nGeGgj8dTErH7yV5SHcUTgU07P0oCN0=.9d965cf7-bf99-4cb0-bf5d-1015f44f4e84@github.com>
Message-ID: <Mro0p9MFLBj9W74i2ccJI7vw9MeY0XmpZtH94EGZM0w=.c4e0066e-8793-4db7-bdc5-619425a831f7@github.com>

On Mon, 29 May 2023 15:53:48 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Moving the logic of type test pattern detection from `parsePattern` to `variableDeclaratorRest` in #13528 made the logic of the latter too complex. The regression in this JBS would be fixed by introducing two additional if-guards (e.g., `if (!typePattern)`); conditional on whether we are detecting a local variable or a type pattern. This PR removes this.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14205#pullrequestreview-1450730711

From abimpoudis at openjdk.org  Tue May 30 14:45:21 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 30 May 2023 14:45:21 GMT
Subject: RFR: 8309093: Underscore with brackets
Message-ID: <f0aKlVcOaJ338DZjkEsMD0R9uAKDDMqIU0FTzKx9kow=.c2c14876-e0ba-4955-a70c-a52db284b89d@github.com>

Currently `<type> _[]` passes compilation while it is prohibited by the [spec](https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html#jls-14.14.2). This PR addresses that.

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

Commit messages:
 - 8309093: Underscore with brackets

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

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

From alex.buckley at oracle.com  Tue May 30 16:52:12 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 30 May 2023 09:52:12 -0700
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <uR8e456fuQtdc4cS2fW2L5O7yGQUnMJNcTQcNXrCeII=.578f6c74-e088-4711-b789-7669e9eb59e3@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <0faf8f88-447b-1efa-26ec-b33fa96a6d53@oracle.com>
 <uR8e456fuQtdc4cS2fW2L5O7yGQUnMJNcTQcNXrCeII=.578f6c74-e088-4711-b789-7669e9eb59e3@github.com>
Message-ID: <875a93e6-93c9-f91a-fe8d-55ffab21ef09@oracle.com>

On 5/29/2023 8:50 AM, Sebastian Stenzel wrote:
> But if you are proposing to split the message into two and add
> complexity to the compiler just for nicer formatting, this would be
> both out of scope of the issue and also something that needs to be
> decided by somebody who is more involved with long term maintenance
> than me. Therefore please CC whoever is responsible for making such
> decisions.

My previous message alluded to the javac maintainers, all of whom are on 
this list:

"One of my colleagues will have to sponsor the PR. I'll leave it to them 
to decide whether a warning in singular form is worthwhile and/or has 
precedent in compiler.properties."

Alex

From acobbs at openjdk.org  Tue May 30 17:40:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 May 2023 17:40:57 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <5HP_Xes94cKxgkhIE4XjpeA1XFj85sq8oQ6Aw2PpbQs=.8f515216-891b-4db5-83bc-99f5ace1bb9b@github.com>

On Sun, 2 Apr 2023 15:06:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag. 
> 
> I have not done any performance testing or comparisons of `StringNameTable`; see also [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) which argues that a `String`-based implementation should be faster.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

I figured out how to run performance tests and ran tests using `SharedNameTable`, `UnsharedNameTable`, and the new `StringNameTable`.

The latter is about 17% faster:

Benchmark                         Mode  Cnt   Score   Error  Units
JavacNameTable.testSharedTable    avgt   25  52.601 ? 1.025  ms/op
JavacNameTable.testStringTable    avgt   25  43.331 ? 1.165  ms/op
JavacNameTable.testUnsharedTable  avgt   25  57.687 ? 1.728  ms/op

Here is the test I ran: [JavacNameTable.java](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1568819666

From darcy at openjdk.org  Tue May 30 18:35:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 18:35:44 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>

> Time to get JDK 22 underway...

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

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
 - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=01
  Stats: 5829 lines in 69 files changed: 5775 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From darcy at openjdk.org  Tue May 30 20:17:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 20:17:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
 <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
Message-ID: <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>

On Tue, 23 May 2023 20:49:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/versions/Versions.java line 93:
>> 
>>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
>>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);
>> 
>> when do these get updated?
>
> Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.

Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210778891

From darcy at openjdk.org  Tue May 30 20:20:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 20:20:21 GMT
Subject: RFR: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
Message-ID: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>

Augment the Versions.java test in the usual way for new language changes.

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

Commit messages:
 - JDK-8309134: Augment test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes

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

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

From jjg at openjdk.org  Tue May 30 21:14:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 May 2023 21:14:55 GMT
Subject: RFR: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
In-Reply-To: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
References: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
Message-ID: <_wfi1N9ZCnari61kwkpa9txS6c0s-Zh92lDQGoHx-Wk=.6c20785d-8145-46d9-9a9d-2ca39f02be1a@github.com>

On Tue, 30 May 2023 20:13:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augment the Versions.java test in the usual way for new language changes.

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

> 307:        expectedPass(args, List.of("New7.java", "New8.java", "New10.java", "New11.java",
> 308:                                   "New14.java", "New15.java", "New16.java", "New17.java"));
> 309:         expectedFail(args, List.of("New21.java"));

Looks like extra space

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

> 579: 
> 580:         /*
> 581:          * Create a file with a new feature in 17, not in 16 : sealed classes

Update comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14229#discussion_r1210827084
PR Review Comment: https://git.openjdk.org/jdk/pull/14229#discussion_r1210828082

From iris at openjdk.org  Tue May 30 21:25:01 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 May 2023 21:25:01 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>
Message-ID: <B-XYZjhrXGGL92jI8shCVNJ4tsIZv_2LI3EIHkh7fWo=.45790a24-157b-46f5-9631-ae55f7c61dc7@github.com>

On Tue, 30 May 2023 18:35:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1451837705

From darcy at openjdk.org  Tue May 30 21:48:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 21:48:52 GMT
Subject: RFR: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
 [v2]
In-Reply-To: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
References: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
Message-ID: <vKw2rxsEuGbCFhQXE0ivoC4jbxRD55YuBiBVov0C028=.7e46edd0-32fd-4ec4-910c-ed74d2bbcfc6@github.com>

> Augment the Versions.java test in the usual way for new language changes.

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

  Respond to review feedback; increase coverage of negative test cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14229/files
  - new: https://git.openjdk.org/jdk/pull/14229/files/31dbd1ee..32879ef4

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

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

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

From darcy at openjdk.org  Tue May 30 21:55:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 21:55:26 GMT
Subject: RFR: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
 [v3]
In-Reply-To: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
References: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
Message-ID: <xtnjcITqXs7g4YF_B3HydcKsvbqKOioI4SDmtTSWC_Y=.4cb9fbcc-9dae-443a-b452-6cfaabeac91b@github.com>

> Augment the Versions.java test in the usual way for new language changes.

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

  Fix whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14229/files
  - new: https://git.openjdk.org/jdk/pull/14229/files/32879ef4..b2a947af

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

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

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

From jjg at openjdk.org  Tue May 30 21:55:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 May 2023 21:55:27 GMT
Subject: RFR: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
 [v2]
In-Reply-To: <vKw2rxsEuGbCFhQXE0ivoC4jbxRD55YuBiBVov0C028=.7e46edd0-32fd-4ec4-910c-ed74d2bbcfc6@github.com>
References: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
 <vKw2rxsEuGbCFhQXE0ivoC4jbxRD55YuBiBVov0C028=.7e46edd0-32fd-4ec4-910c-ed74d2bbcfc6@github.com>
Message-ID: <W0gA_lDhXAJ48lxY1jUaBgK9dVuUzhGknf5eeloqv0c=.200e3038-1ff6-4c6a-baf7-7d22168954c8@github.com>

On Tue, 30 May 2023 21:48:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Augment the Versions.java test in the usual way for new language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; increase coverage of negative test cases.

Still an extra space on line 313

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14229#pullrequestreview-1451869541

From darcy at openjdk.org  Tue May 30 22:02:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 22:02:02 GMT
Subject: Integrated: JDK-8309134: Augment
 test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes
In-Reply-To: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
References: <ZFI29c7AswdRpmrvgXGbJSOuBzKP0E5uy7f0EoY0X44=.51fb77f2-7e6e-451f-9fee-ed5eb2a92789@github.com>
Message-ID: <Na1lZI9PYiy9wEWsPGsGwPH4cSa6f3b-6yQTWO0WNlc=.5fc3a083-0803-417c-94d0-eef2cc85d414@github.com>

On Tue, 30 May 2023 20:13:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augment the Versions.java test in the usual way for new language changes.

This pull request has now been integrated.

Changeset: cb40db05
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb40db052cef5e009fca2eb2d2287baedbad81e6
Stats:     45 lines in 1 file changed: 30 ins; 1 del; 14 mod

8309134: Augment test/langtools/tools/javac/versions/Versions.java for JDK 21 language changes

Reviewed-by: jjg

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

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

From darcy at openjdk.org  Tue May 30 22:16:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 22:16:08 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>

> Time to get JDK 22 underway...

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

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=02
  Stats: 5828 lines in 69 files changed: 5775 ins; 0 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From darcy at openjdk.org  Tue May 30 22:16:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 22:16:09 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
 <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
 <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>
Message-ID: <3jywj8fLCqTlr-mps0rsYBXgb4jhxQaDFNCcgXLpSUQ=.e0a59fa0-5307-4d4c-8b5e-87c9e4d42d74@github.com>

On Tue, 30 May 2023 20:14:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.
>
> Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229.

> Better to fix this omission in JDK 21; please see #14229.

Addressed by merge of JDK-8309134 into JDK 22; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210875483

From djelinski at openjdk.org  Wed May 31 07:37:57 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 May 2023 07:37:57 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <vpaEFqk8j0uJ_cFqqCAgPxDy9YlXQeUnn5hntr-P990=.4352f54c-2113-47ce-9e65-b9225d79306d@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

FWIW, here's the official documentation for VS2008 stating that LL is a supported suffix:
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/00a1awxf(v=vs.90)
I couldn't find a similar page for VS2005.

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1569653360

From dholmes at openjdk.org  Wed May 31 08:06:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 08:06:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
Message-ID: <PXBZ7zJTTlZqtJ04-3pVjDwmEMuhPMxTkO2mYT3qiaQ=.0c1114e8-30a8-451b-bf8d-eb3089f2a476@github.com>

On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1452455740

From abimpoudis at openjdk.org  Wed May 31 09:41:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 31 May 2023 09:41:16 GMT
Subject: Integrated: 8309054: Parsing of erroneous patterns succeeds
In-Reply-To: <_ao5L32MXy38nGeGgj8dTErH7yV5SHcUTgU07P0oCN0=.9d965cf7-bf99-4cb0-bf5d-1015f44f4e84@github.com>
References: <_ao5L32MXy38nGeGgj8dTErH7yV5SHcUTgU07P0oCN0=.9d965cf7-bf99-4cb0-bf5d-1015f44f4e84@github.com>
Message-ID: <a-0gCEHq5E5yX7eJ5uU24FJw89H5-5Sahe4DmHEB1-Y=.92259df4-847e-4912-a92d-9d292740412c@github.com>

On Mon, 29 May 2023 15:53:48 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Moving the logic of type test pattern detection from `parsePattern` to `variableDeclaratorRest` in #13528 made the logic of the latter too complex. The regression in this JBS would be fixed by introducing two additional if-guards (e.g., `if (!typePattern)`); conditional on whether we are detecting a local variable or a type pattern. This PR removes this.

This pull request has now been integrated.

Changeset: 4f3a95af
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f3a95af2f87756c87fa63d197176cfbb066ecdb
Stats:     75 lines in 3 files changed: 38 ins; 9 del; 28 mod

8309054: Parsing of erroneous patterns succeeds

Reviewed-by: jlahoda

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

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

From jlaskey at openjdk.org  Wed May 31 12:57:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 31 May 2023 12:57:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v23]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <LahlzTLMRfyNpCv0UAH9Yqkq2VTnqWlkkJfuoUgyh_k=.81b99909-9dfd-4e83-ab8b-f7cf9b563fcf@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove mandated flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/06aa43ec..a8b31010

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21-22

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

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

From jlaskey at openjdk.org  Wed May 31 13:01:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 31 May 2023 13:01:47 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v24]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <G4eGE92rD9LTA6mHjokrlQZ5pYmk6w2lurJGZ8B0jDU=.49579b4c-41ad-467b-b164-40b8838923c6@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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 branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - Add main  tests for inferface/enum/record
 - Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
   
   Author: Jan Lahoda <jlahoda at openjdk.org>
 - Ignore SKIPs (semicolon class declarations)
 - Allow unqualified access to unnamed class (internally visible)
 - Fix missing constructor error messages and handle inner class launching
 - Merge branch 'master' into 8306112
 - Issue warning if traditional main not used.
 - ... and 30 more: https://git.openjdk.org/jdk/compare/4aea7dab...d0189fc2

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=23
  Stats: 1299 lines in 31 files changed: 1134 ins; 32 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlahoda at openjdk.org  Wed May 31 18:16:00 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 May 2023 18:16:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
Message-ID: <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>

On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

javac and symbol related changes seem reasonable to me. Two minor comments added for consideration.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127:

> 125:         V64(64, 0),   // JDK 20
> 126:         V65(65, 0),   // JDK 21
> 127:         V66(66, 0);   // JDK 22

A very small nit/suggestion - it should be possible to do:

V66(66, 0),   //JDK 22
;


(i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.)

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

> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc21),
> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc21);

Should there be `checksrc22` instead of `checksrc21`? Or is that done later?

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1453854784
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212101629
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212114188

From darcy at openjdk.org  Wed May 31 20:39:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 May 2023 20:39:44 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v4]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <2vhEXa4W2A-VkPRaEyqaidm2tKuWdhqvJOA2mgvvC4g=.0a0a7ffa-1e26-45b0-838c-865bb02a2b82@github.com>

> Time to get JDK 22 underway...

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

 - Respond to review comments.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/12649025...7b446793

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=03
  Stats: 5843 lines in 69 files changed: 5789 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From darcy at openjdk.org  Wed May 31 20:41:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 May 2023 20:41:13 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
 <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>
Message-ID: <QovVhDh1rbYLfithuvHa_eoAFD3_fhGYJU1xZq2p3yk=.f6cc23f5-cc8e-4633-b276-fcb9e4f00f4f@github.com>

On Wed, 31 May 2023 18:02:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Sync in symbol changes for JDK 21 build 24.
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Minor test fixes.
>>  - Merge branch 'master' into JDK-8306584
>>  - Update symbol files to JDK 21 b23.
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127:
> 
>> 125:         V64(64, 0),   // JDK 20
>> 126:         V65(65, 0),   // JDK 21
>> 127:         V66(66, 0);   // JDK 22
> 
> A very small nit/suggestion - it should be possible to do:
> 
> V66(66, 0),   //JDK 22
> ;
> 
> 
> (i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.)

Updated.

> test/langtools/tools/javac/versions/Versions.java line 93:
> 
>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc21),
>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc21);
> 
> Should there be `checksrc22` instead of `checksrc21`? Or is that done later?

Good catch. I have a refactoring of the test planned which will eliminate the explicit "checksrc$N" methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212284124
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212283880