From stephan.herrmann at berlin.de  Sun Sep  1 08:44:46 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Sun, 1 Sep 2024 10:44:46 +0200
Subject: widen-unbox-widen vs JEP 455
Message-ID: <d2423b79-5269-425c-b199-95c554534548@berlin.de>

I just learned that reference widening followed by unboxing (followed by 
primitive widening) is deemed a relevant conversion [1]. So I made sure that ecj 
can handle this in various situation, only to find out that this will make ecj 
produce code that is behaviorally different from what javac emits.

Here's my test code challenging this aspect of JEP 455:
//
<T extends Short> void typeVariableSingle(T single) {
     int i1 = single;
     System.out.print(i1);
     if (single instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (single) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
<T extends Short> void typeVariableList(List<T> list) {
     int i1 = list.get(0);
     System.out.print(i1);
     if (list.get(0) instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (list.get(0)) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
void wildcard(List<? extends Short> list) {
     int i1 = list.get(0);
     System.out.print(i1);
     if (list.get(0) instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (list.get(0)) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
void main() {
     Short s = 1;
     typeVariableSingle(s);
     typeVariableList(Collections.singletonList(s));
     wildcard(Collections.singletonList(s));
}
//

compiled with ecj this gives
111
111
111

compiled with javac the program prints
111
1-1
1-1

Is this a simple bug in javac, or is there more to it?
thanks
Stephan

[1] see answers to 
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-August/004204.html

From jlahoda at openjdk.org  Tue Sep  3 12:36:53 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Sep 2024 12:36:53 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java intermittently
 Timeout signalled after 480 seconds
Message-ID: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>

This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.

Consider this code:

    sealed interface B permits S1, S2 {}
    final class S1 implements B {}
    final class S2 implements B {}
    record R(B b, B s) {}
    private void test(R r) {
        switch (r) {
            case R(B _, S1 _) -> {}
            case R(S1 _, B _) -> {}
            case R(S2 _, S2 _) -> {}
        }
    }


The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.

This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.

But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).

The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.

The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.

The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more patterns can be merged.

I ran the `Exhaustiveness` test many times with this change, without a timeout so far.

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

Commit messages:
 - Cleanup.
 - Cleanup.
 - 8326616: tools/javac/patterns/Exhaustiveness.java intermittently Timeout signalled after 480 seconds

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

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

From abimpoudis at openjdk.org  Tue Sep  3 14:46:20 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Sep 2024 14:46:20 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds
In-Reply-To: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
Message-ID: <_-BB5r4-1U83vjbam4-tj8y44EKfa5Kpa8xr_TR3cRQ=.5a436d15-b36b-4ac0-a8f3-2115ad4eca36@github.com>

On Tue, 3 Sep 2024 12:31:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
> 
> Consider this code:
> 
>     sealed interface B permits S1, S2 {}
>     final class S1 implements B {}
>     final class S2 implements B {}
>     record R(B b, B s) {}
>     private void test(R r) {
>         switch (r) {
>             case R(B _, S1 _) -> {}
>             case R(S1 _, B _) -> {}
>             case R(S2 _, S2 _) -> {}
>         }
>     }
> 
> 
> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
> 
> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
> 
> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
> 
> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
> 
> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
> 
> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more ...

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1030:

> 1028:          * $record($prefix$, $resultOfReduction, $suffix$)
> 1029:          *
> 1030:          * useHashes: when true, patterns will be a subject to exact equivalence;

- will be ~a~ subject
- two binding~s~ patterns

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1742201117

From abimpoudis at openjdk.org  Tue Sep  3 15:29:19 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Sep 2024 15:29:19 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds
In-Reply-To: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
Message-ID: <z31pYKGWYJ3X4YaMdC20VwWrQZFzqL8pRkbMC3GqcQk=.994c313b-990a-46d6-8193-4e31860e7ca6@github.com>

On Tue, 3 Sep 2024 12:31:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
> 
> Consider this code:
> 
>     sealed interface B permits S1, S2 {}
>     final class S1 implements B {}
>     final class S2 implements B {}
>     record R(B b, B s) {}
>     private void test(R r) {
>         switch (r) {
>             case R(B _, S1 _) -> {}
>             case R(S1 _, B _) -> {}
>             case R(S2 _, S2 _) -> {}
>         }
>     }
> 
> 
> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
> 
> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
> 
> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
> 
> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
> 
> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
> 
> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more ...

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1098:

> 1096:                                                     !(rpOther.nested[i] instanceof BindingPattern bpOther) ||
> 1097:                                                     !types.isSubtype(types.erasure(bpOne.type), types.erasure(bpOther.type))) {
> 1098:                                                     continue NEXT_PATTERN;

No tests in the `patterns` folder executes this block (`continue NEXT_PATTERN;`). I am sure it works, can you include a small test that leads to this line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1742266518

From nbenalla at openjdk.org  Wed Sep  4 10:36:51 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:51 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
Message-ID: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>

The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.

The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.

This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.


`[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
`[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
`[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
`[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)



`test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.

Tests broken by these methods are :


jdk/classfile/VerifierSelfTest.java
jdk/classfile/TestRecordComponent.java
jdk/classfile/TestNullHostile.java	
jdk/classfile/OpcodesValidationTest.java
jdk/classfile/ClassPrinterTest.java
java/lang/invoke/MethodHandlesGeneralTest.java	
java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
java/lang/invoke/MethodHandleProxies/BasicTest.java


Full list of methods


//the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
"java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",

// making this method null-hostile causes a BootstapMethodError during the the build
//        java.lang.BootstrapMethodError: bootstrap method initialization exception
//        Caused by: java.lang.invoke.LambdaConversionException: Exception instantiating lambda object
"java.lang.classfile.CodeBuilder/loadConstant(java.lang.constant.ConstantDesc)/0/0",
"java.lang.classfile.CodeBuilder$BlockCodeBuilder/loadConstant(java.lang.constant.ConstantDesc)/0/0",



//removing these from exclude list breaks CorpusTest and AdvancedTransformationsTest
"java.lang.classfile.ClassHierarchyResolver$ClassHierarchyInfo/ofClass(java.lang.constant.ClassDesc)/0/0",
"java.lang.classfile.attribute.ModuleAttribute$ModuleAttributeBuilder/requires(java.lang.constant.ModuleDesc,int,java.lang.String)/2/0",
"java.lang.classfile.attribute.ModuleAttribute/of(java.lang.classfile.constantpool.ModuleEntry,int,java.lang.classfile.constantpool.Utf8Entry,java.util.Collection,java.util.Collection,java.util.Collection,java.util.Collection,java.util.Collection)/2/0",
"java.lang.classfile.attribute.ModuleRequireInfo/of(java.lang.classfile.constantpool.ModuleEntry,int,java.lang.classfile.constantpool.Utf8Entry)/2/0",
"java.lang.classfile.AttributeMapper/readAttribute(java.lang.classfile.AttributedElement,java.lang.classfile.ClassReader,int)/0/0",

// this one from exclude list breaksa few more tests
"java.lang.classfile.AttributeMapper/readAttribute(java.lang.classfile.AttributedElement,java.lang.classfile.ClassReader,int)/1/0",

// this one breaks jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java
"java.lang.classfile.ClassHierarchyResolver/ofClassLoading(java.lang.ClassLoader)/0/0",

//I need to revisit these
"java.lang.classfile.ClassFileTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.ClassFileTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.ClassTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",

//can we add stronger checks here?
"java.lang.classfile.components.CodeStackTracker/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.components.CodeStackTracker/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.CodeTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.CodeTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.FieldTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.FieldTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeLocalsShifter/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.components.CodeLocalsShifter/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeRelabeler/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeRelabeler/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.MethodTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.MethodTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",

// implementation calls these method with null
"java.lang.classfile.Signature$ClassTypeSig/of(java.lang.classfile.Signature$ClassTypeSig,java.lang.constant.ClassDesc,java.lang.classfile.Signature$TypeArg[])/0/0",
"java.lang.classfile.Signature$ClassTypeSig/of(java.lang.classfile.Signature$ClassTypeSig,java.lang.String,java.lang.classfile.Signature$TypeArg[])/0/0",
"java.lang.classfile.Signature$TypeParam/of(java.lang.String,java.lang.classfile.Signature$RefTypeSig,java.lang.classfile.Signature$RefTypeSig[])/1/0",
"java.lang.classfile.BufWriter/writeIndexOrZero(java.lang.classfile.constantpool.PoolEntry)/0/0"

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

Commit messages:
 - Tiny changes, some variable renames
 - Changes after JDK-8339214
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - - Passes all tests, a lot of comments for future work and questions
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - drop unused test file
 - Add more null checks, added some todos for methods that need to be revisited.
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - add requiresnonnull where necessary
 - Merge remote-tracking branch 'origin/master' into classfile-nulls
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ad40a122...2902e21d

Changes: https://git.openjdk.org/jdk/pull/20556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317356
  Stats: 1458 lines in 85 files changed: 1388 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/20556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20556/head:pull/20556

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

From liach at openjdk.org  Wed Sep  4 10:36:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 10:36:51 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

? Reveals a lot of inconsistencies in the API. Many are remarks for future RFEs.

I doubt this is more of a conformance instead of a functional test - and this test cannot effectively test the cases where some object states will have code paths that do not throw NPE.

Indeed, `ConstantInstruction.ofArgument` needs a null check now. The other APIs should be fine as-is.

src/java.base/share/classes/java/lang/classfile/Annotation.java line 100:

> 98:                          List<AnnotationElement> elements) {
> 99:         requireNonNull(annotationClass);
> 100:         requireNonNull(elements);

How did you test these? Shouldn't null elements result in an NPE in `List.copyOf`?

src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java line 1:

> 1: /*

Methods here technically shouldn't be called by users; they only exist for the API to call, and for chained transforms, API don't call these and they throw UOE. We should look for another way to handle this.

src/java.base/share/classes/java/lang/classfile/Signature.java line 162:

> 160:          * @param typeArgs signatures of the type arguments
> 161:          */
> 162:         public static ClassTypeSig of(ClassTypeSig outerType, ClassDesc className, TypeArg... typeArgs) {

Another instance of nullable argument... I thought @asotona expressed that we wish to convert nullable args to `Optional`. Need to make such parameters consistent across the ClassFile API.

test/jdk/jdk/classfile/testdata/TestClass.java line 1:

> 1: package testdata;

File seems redundant? Or did you forget to upload the test driver?

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

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2276280243
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2288755193
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326604717
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741341522
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741340877
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741342557
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741343202

From duke at openjdk.org  Wed Sep  4 10:36:53 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

> And this test cannot effectively test the cases where some object states will have code paths that do not throw NPE.

**Ref:** [JDK?8336430](https://bugs.openjdk.org/browse/JDK-8336430)

Since?this now?makes the?NPE?behaviour of?[`Utf8Entry?::equalsString?(String)`]?consistent, this?PR can?be?marked as?fixing [JDK?8336430].

[`Utf8Entry?::equalsString?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/Utf8Entry.html#equalsString(java.lang.String)
[JDK?8336430]: https://bugs.openjdk.org/browse/JDK-8336430

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 88:

> 86:             //todo: uncomment later
> 87:             // this causes CorpusTest to fail
> 88:             // requireNonNull(superClass);

This?is?valid, as?the?super class?descriptor of?`java.lang.Object` is?`null` (it?s?the?only one?allowed and?required to?extend?`null`).
Suggestion:

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 226:

> 224:     static ClassHierarchyResolver ofClassLoading(ClassLoader loader) {
> 225:         //null check here breaks WithSecurityManagerTest
> 226: //        requireNonNull(loader);

The `null` `ClassLoader` is?valid and?refers to?either the?system or?bootstrap class?loader (depending on the API).

In?the?case of?[`Class?::forName(?)`], it?s?the?bootstrap class?loader (which?is?represented by?`null` (`Object.class.getClassLoader()` returns?`null`!))
Suggestion:



[`Class?::forName(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 622:

> 620:     default CodeBuilder loadConstant(ConstantDesc value) {
> 621: //        adding null check here causes error
> 622: //        requireNonNull(value);

This?method is?specified as?allowing?`null`?below.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 144:

> 142:         requireNonNull(moduleName);
> 143:         //todo should moduleVersion be Nullable?
> 144: //        requireNonNull(moduleVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 240:

> 238:             requireNonNull(module);
> 239:             requireNonNull(requiresFlags);
> 240:             requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 93:

> 91:         requireNonNull(requires);
> 92:         //todo: uncomment later after CorpusTest is fixed
> 93: //        requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 104:

> 102:      */
> 103:     static ModuleRequireInfo of(ModuleEntry requires, Collection<AccessFlag> requiresFlags, Utf8Entry requiresVersion) {
> 104:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 106:

> 104:         requireNonNull(requiresVersion);
> 105:         requireNonNull(requiresFlags);
> 106:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 118:

> 116:     static ModuleRequireInfo of(ModuleDesc requires, int requiresFlags, String requiresVersion) {
> 117:         requireNonNull(requires);
> 118:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 385:

> 383:         @Override
> 384:         public boolean equalsString(String s) {
> 385:             Objects.requireNonNull(s);

I?d?prefer if?this?method returned?`false` on?`null`, just?like how?[`Object?::equals?(Object)`] and?[`String?::equalsIgnoreCase?(String)`] return?`false` on?`null`.

[`Object?::equals?(Object)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)
[`String?::equalsIgnoreCase?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#equalsIgnoreCase(java.lang.String)

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 78:

> 76:     public ClassFileImpl withOptions(Option... options) {
> 77:         requireNonNull(options);
> 78:         for (var o : options){

Suggestion:

        for (var o : options) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 101:

> 99:         requireNonNull(clb);
> 100:         requireNonNull(cle);
> 101:         switch (cle) {

Suggestion:

        switch (cle) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 280:

> 278:     @Override
> 279:     public ClassDesc map(ClassDesc desc) {
> 280:         requireNonNull(desc);

Allowed?below:
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/CodeLocalsShifterImpl.java line 54:

> 52:         Objects.requireNonNull(cob);
> 53:         Objects.requireNonNull(coe);
> 54:         switch (coe) {

Suggestion:

        switch (coe) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java line 55:

> 53:         requireNonNull(cob);
> 54:         requireNonNull(coe);
> 55:         switch (coe) {

Suggestion:

        switch (coe) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java line 83:

> 81:     @Override
> 82:     public ModuleAttributeBuilder moduleVersion(String version) {
> 83:         requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java line 92:

> 90:         requireNonNull(module);
> 91:         // todo this crashes corpus test??
> 92: //        requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

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

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2278167656
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2288819265
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2325306146
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742497978
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742496132
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742500730
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742505667
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742512822
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742505172
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523836
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523525
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523581
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1739220025
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742526544
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742527119
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742528052
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742528767
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742529154
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742510632
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742510377

From nbenalla at openjdk.org  Wed Sep  4 10:36:53 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <h4Ime_qdU_ug4Zqc9y2RgFxhJHtkXbIIcHIfPC10xdo=.eeb07b4c-7072-48e0-a823-5b3eacae6c3a@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

**Edit: the entire list has now been checked**

I now have some tests that pick up on the bug in `Utf8Entry::equalsString`.
I have added `Objects::requireNonNull` in a few places, will do an other scan when I'm done to remove a few that may be redundant, as the null check is sometimes implicit.
Classes/Interfaces that I haven't tested yet are the following 

AttributeMapper
AttributeMapper.AttributeStability
BufWriter
ClassBuilder
ClassFileElement
ClassFileTransform
ClassHierarchyResolver.ClassHierarchyInfo
ClassModel
ClassReader
ClassSignature
ClassTransform
CodeBuilder
CodeBuilder.CatchBuilder
CodeBuilder.BlockCodeBuilder
CodeElement
CodeTransform
CompoundElement
FieldBuilder
FieldTransform
MethodBuilder
MethodElement
MethodSignature
MethodTransform
Opcode
Opcode.Kind
Signature.ArrayTypeSig
Signature.BaseTypeSig
Signature.TypeArg
Signature.TypeArg.Bounded
Signature.TypeArg.Bounded.WildcardIndicator
Signature.TypeArg.Unbounded
Signature.ClassTypeSig
Signature.ThrowableSig
Signature.TypeParam
Signature.TypeVarSig
Signature.RefTypeSig
TypeAnnotation.TargetInfo
TypeAnnotation.TypePathComponent
TypeAnnotation.TypePathComponent.Kind
TypeAnnotation.TypeArgumentTarget
TypeAnnotation.OffsetTarget
TypeAnnotation.CatchTarget
TypeAnnotation.LocalVarTargetInfo
TypeAnnotation.LocalVarTarget
TypeAnnotation.ThrowsTarget
TypeAnnotation.FormalParameterTarget
TypeAnnotation.EmptyTarget
TypeAnnotation.TypeParameterBoundTarget
TypeAnnotation.SupertypeTarget
TypeAnnotation.TypeParameterTarget
TypeAnnotation.TargetType
AnnotationDefaultAttribute
BootstrapMethodsAttribute
ModuleAttribute.ModuleAttributeBuilder
ModuleExportInfo
ModuleHashInfo
ModuleHashesAttribute
ModuleMainClassAttribute
ModuleOpenInfo
ModulePackagesAttribute
ModuleProvideInfo
ModuleRequireInfo
ModuleResolutionAttribute
ModuleTargetAttribute
ClassPrinter.MapNode
ClassPrinter.ListNode
ClassPrinter.LeafNode
ClassPrinter.Node
ClassRemapper
CodeLocalsShifter
CodeRelabeler

Thanks for keeping track of this PR, I will do one more push tomorrow and open it.

I shaved 500 lines from the test I was using, I can probably make it more concise with more time.

Adding null checks breaks some tests (sometimes even the build), some are method handles related but the rest are limited to CF. 

I have filed [JDK-8339344](https://bugs.openjdk.org/browse/JDK-8339344) but more Bugs/RFEs will need to be filed.

I will modify the PR's body with some questions on which methods can be added to `TestNullHostile##EXCLUDE_LIST` and which need to be updated.

Also, I noticed a recent push (#20779) removing `CodeBuilder.loadConstant(Opcode, ConstantDesc)` which had been a major source of pain today. Will merge in a bit.

An other want I want to discuss is CodeBuilder.loadConstant(ConstantDesc value).

It [handles nulls ](https://github.com/openjdk/jdk/blob/ad40a122d632d65052b71125c0dfd58c54e3a521/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L614), and adding a null check causes a `BootstrapMethodError` during the build

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

PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2321858976
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2325417395
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326579191
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326627971

From liach at openjdk.org  Wed Sep  4 10:36:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>
Message-ID: <gWN6eFDdHqCKZ9kh66EkSVPMJMxNluIcYWpoFZgP6E0=.64408161-1be7-4e76-aacd-790180ab1ea0@github.com>

On Tue, 3 Sep 2024 18:27:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 226:
> 
>> 224:     static ClassHierarchyResolver ofClassLoading(ClassLoader loader) {
>> 225:         //null check here breaks WithSecurityManagerTest
>> 226: //        requireNonNull(loader);
> 
> The `null` `ClassLoader` is?valid and?refers to?either the?system or?bootstrap class?loader (depending on the API).
> 
> In?the?case of?[`Class?::forName(?)`], it?s?the?bootstrap class?loader (which?is?represented by?`null` (`Object.class.getClassLoader()` returns?`null`!))
> Suggestion:
> 
> 
> 
> [`Class?::forName(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

We intend to avoid using `null` to represent bootstrap class loader here, like in `MethodType`: https://github.com/openjdk/jdk/blob/bbb516163d400a9c7e923e423fe2a60091b59322/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1197

> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 622:
> 
>> 620:     default CodeBuilder loadConstant(ConstantDesc value) {
>> 621: //        adding null check here causes error
>> 622: //        requireNonNull(value);
> 
> This?method is?specified as?allowing?`null`?below.
> Suggestion:

We are thinking about whether to allow nullable or enforce `Optional` across the ClassFile API. So this may be changed to accept an `Optional` in the future.

> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 385:
> 
>> 383:         @Override
>> 384:         public boolean equalsString(String s) {
>> 385:             Objects.requireNonNull(s);
> 
> I?d?prefer if?this?method returned?`false` on?`null`, just?like how?[`Object?::equals?(Object)`] and?[`String?::equalsIgnoreCase?(String)`] return?`false` on?`null`.
> 
> [`Object?::equals?(Object)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)
> [`String?::equalsIgnoreCase?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#equalsIgnoreCase(java.lang.String)

We should have noted clearly that the intended use case is for a read utf8 to compare to an existing string, like a method name, so we can minimally inflate a utf8 to perform a comparison. This means that there is little purpose of using `null` here, just like for any other Class-File API endpoints.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742619721
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742622251
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1739266003

From nbenalla at openjdk.org  Wed Sep  4 10:36:54 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:54 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>
Message-ID: <GFVLh9Yx29xWv_6mq7I3cJjScuok6LPK8gSuQBmu70Y=.1f211f27-51b5-4594-ac1d-1fb43c350365@github.com>

On Tue, 3 Sep 2024 01:58:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> test/jdk/jdk/classfile/testdata/TestClass.java line 1:
> 
>> 1: package testdata;
> 
> File seems redundant? Or did you forget to upload the test driver?

I thought I removed `testClass.java` as I no longer use it.

I will include a regression test tomorrow with the next patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741345363

From abimpoudis at openjdk.org  Wed Sep  4 13:10:24 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Sep 2024 13:10:24 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds
In-Reply-To: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
Message-ID: <WdUxYhC3CxSrwOLLGXiZU4mKTa3Qyp4Kk6BXAFJEgQY=.4c470d47-aae6-4967-ac7c-68f704734e60@github.com>

On Tue, 3 Sep 2024 12:31:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
> 
> Consider this code:
> 
>     sealed interface B permits S1, S2 {}
>     final class S1 implements B {}
>     final class S2 implements B {}
>     record R(B b, B s) {}
>     private void test(R r) {
>         switch (r) {
>             case R(B _, S1 _) -> {}
>             case R(S1 _, B _) -> {}
>             case R(S2 _, S2 _) -> {}
>         }
>     }
> 
> 
> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
> 
> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
> 
> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
> 
> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
> 
> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
> 
> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more ...

LGTM

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1067:

> 1065:                              //error recovery, ignore patterns with incorrect number of nested patterns:
> 1066:                              .filter(pd -> pd.nested.length == nestedPatternsCount)
> 1067:                              .collect(groupingBy(pd -> useHashes ? pd.hashCode(mismatchingCandidateFin) : 0));

`groupByHashes` can be renamed into `groupByOnlyMismatchingCandidateDifference` or something else. The `ByHashes` is not applicable any more in the general case.

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20836#pullrequestreview-2280080396
PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1743725949

From nbenalla at openjdk.org  Wed Sep  4 15:32:41 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 15:32:41 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v2]
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <5OcOD6zYMPs6902_xjt3j6gvafZO-JGAS-4yCkk472c=.ae91898c-b3c0-4f85-9230-289983b83e88@github.com>

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
 - Tiny changes, some variable renames
 - Changes after JDK-8339214
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
 - - Passes all tests, a lot of comments for future work and questions
   
   - Added (C)
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - drop unused test file
 - Add more null checks, added some todos for methods that need to be revisited.
   
   Some tests need to be updated if we want to integrate this change
   
   use regex to switch Object.require non null with the static import.
   Just for nicer syntax
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
 - add requiresnonnull where necessary
 - ... and 2 more: https://git.openjdk.org/jdk/compare/6f8714ee...cf75c679

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

Changes: https://git.openjdk.org/jdk/pull/20556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=01
  Stats: 1458 lines in 85 files changed: 1388 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/20556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20556/head:pull/20556

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

From nbenalla at openjdk.org  Wed Sep  4 18:35:57 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 18:35:57 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v3]
In-Reply-To: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
Message-ID: <HYUYi3VNQMrnr41IwiaW-r_LWfBsmG7xzGBwLwufNys=.b1e1f624-9f04-4668-bc72-bb752208a968@github.com>

> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
> More details are in the JBS issues
> 
> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - Add two different modes of running the checkers
 - - Update PR to use TestRunner
   - Renamed tools directory to doccheckutils due to naming conflict
   - Some fixes based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20711/files
  - new: https://git.openjdk.org/jdk/pull/20711/files/031c49bd..c6d60f95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20711&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20711&range=01-02

  Stats: 154 lines in 12 files changed: 66 ins; 52 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/20711.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20711/head:pull/20711

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

From nbenalla at openjdk.org  Wed Sep  4 18:39:15 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 18:39:15 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v4]
In-Reply-To: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
Message-ID: <1ZqEH21Ms05SQx4dFO0QuChlG8LlsHQGezFU_nBmyGQ=.cac34912-12be-4c16-8c53-917dbe2c37e2@github.com>

> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
> More details are in the JBS issues
> 
> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  make test run with executors by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20711/files
  - new: https://git.openjdk.org/jdk/pull/20711/files/c6d60f95..19d07811

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20711&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20711&range=02-03

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

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

From nbenalla at openjdk.org  Wed Sep  4 18:48:20 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 18:48:20 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v4]
In-Reply-To: <1ZqEH21Ms05SQx4dFO0QuChlG8LlsHQGezFU_nBmyGQ=.cac34912-12be-4c16-8c53-917dbe2c37e2@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
 <1ZqEH21Ms05SQx4dFO0QuChlG8LlsHQGezFU_nBmyGQ=.cac34912-12be-4c16-8c53-917dbe2c37e2@github.com>
Message-ID: <3bwgl-NyAPb4ciEgkO91Ow2izwFE_hWBgLCYEk1HVBY=.d2d17fa3-ebac-41e0-8582-24296cdb57f8@github.com>

On Wed, 4 Sep 2024 18:39:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
>> More details are in the JBS issues
>> 
>> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test run with executors by default

I tried to address some of the review comments, I now use `TestRunner`.
I've renamed the `tools` directory to `doccheckutils` to avoid any naming conflicts.
There are now two modes of running the test, one with executors and one sequentially, you can pass a `doccheck.runParallel` command line option to test and the default value is true.

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

PR Comment: https://git.openjdk.org/jdk/pull/20711#issuecomment-2329748255

From jonathan.gibbons at oracle.com  Thu Sep  5 00:22:04 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 4 Sep 2024 17:22:04 -0700
Subject: Result: Withdraw sponsorship of Closures and Detroit Projects
In-Reply-To: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
References: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
Message-ID: <1c55f69d-6002-41fb-88ac-b61ab329ab40@oracle.com>

Voting for this [*] has now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [b], this is 
sufficient
to approve the motion, and so the Compiler Group withdraws sponsorship
of?aforementioned Projects.

-- Jon

[*]: https://mail.openjdk.org/pipermail/compiler-dev/2024-August/027546.html

On 8/15/24 2:38 PM, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the long 
> inactive
> Closures [1] and Detroit [2] Projects
>
> Closures was one of the Innovators' Challenge Projects.? It's been 
> inactive for years.
>
> Detroit never got off the ground.
>
> A consequence of withdrawing sponsorship? is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 29 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#closures
> [2]: https://openjdk.org/census#detroit
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>
>
>
>

From jonathan.gibbons at oracle.com  Thu Sep  5 00:22:10 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 4 Sep 2024 17:22:10 -0700
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
Message-ID: <ab86cd60-a35e-4403-8332-a1340500c12e@oracle.com>

Voting for this [*] has now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [b], this is 
sufficient
to approve the motion, and so the Compiler Group withdraws sponsorship
of the aforementioned Projects.

-- Jon

[*]: https://mail.openjdk.org/pipermail/compiler-dev/2024-August/027557.html

On 8/16/24 1:39 PM, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the
> Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.
>
> All three projects have been completed successfully and the results
> integrated into the mainline JDK repositories.
>
> A consequence of withdrawing sponsorship is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 30 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#lambda
> [2]: https://openjdk.org/census#tiered-attrib
> [3]: https://openjdk.org/census#type-annotations
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>

From jonathan.gibbons at oracle.com  Thu Sep  5 00:52:14 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 4 Sep 2024 17:52:14 -0700
Subject: Result: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <ab86cd60-a35e-4403-8332-a1340500c12e@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
 <ab86cd60-a35e-4403-8332-a1340500c12e@oracle.com>
Message-ID: <b446287e-f9cb-41ed-a585-281083005a5e@oracle.com>

Resending with corrected Subject line

-- Jon

On 9/4/24 5:22 PM, Jonathan Gibbons wrote:
> Voting for this [*] has now closed.
>
> Yes: 4
> Veto: 0
> Abstain: 0
>
> According to the Bylaws definition of Lazy Consensus [b], this is 
> sufficient
> to approve the motion, and so the Compiler Group withdraws sponsorship
> of the aforementioned Projects.
>
> -- Jon
>
> [*]: 
> https://mail.openjdk.org/pipermail/compiler-dev/2024-August/027557.html
>
> On 8/16/24 1:39 PM, Jonathan Gibbons wrote:
>> I propose that the Compiler Group withdraw Sponsorship of the
>> Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.
>>
>> All three projects have been completed successfully and the results
>> integrated into the mainline JDK repositories.
>>
>> A consequence of withdrawing sponsorship is that the Project may be
>> dissolved. [c]
>>
>> Votes are due by COB 30 Aug 2024.
>>
>> Only current Compiler Group Members [a] are eligible to vote on this
>> motion.? Votes must be cast in the open by replying to this mailing
>> list.
>>
>> For Lazy Consensus voting instructions, see [b].
>>
>> -- Jon
>>
>> [1]: https://openjdk.org/census#lambda
>> [2]: https://openjdk.org/census#tiered-attrib
>> [3]: https://openjdk.org/census#type-annotations
>> [a]: https://openjdk.org/census#compiler
>> [b]: https://openjdk.org/bylaws#lazy-consensus
>> [c]: https://openjdk.org/bylaws#sponsor
>>
>>

From nbenalla at openjdk.org  Thu Sep  5 08:49:14 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Sep 2024 08:49:14 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  convert TestNullHostile to use JUnit Jupiter API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20556/files
  - new: https://git.openjdk.org/jdk/pull/20556/files/cf75c679..2e72dee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=01-02

  Stats: 21 lines in 1 file changed: 7 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20556/head:pull/20556

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

From jpai at openjdk.org  Thu Sep  5 16:50:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Sep 2024 16:50:57 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3572beb3-06f9-4236-b976-1a7c9039c03a@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.df639556-1e88-41f4-9f87-12ca432f6617@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.a3eb0b03-e287-4434-bc61-f2f7c06bc99c@github.com>
 <ThW0-XhNZcWXBxBeaTUu_zonbyNvLG8JkByOVVZsxbA=.d6d5a990-73a2-4ab6-9299-1457bd90551e@github.com>
 <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.c2063e9a-1648-4763-8a5f-f3e145b88672@github.com>
 <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3572beb3-06f9-4236-b976-1a7c9039c03a@github.com>
Message-ID: <NfqlTzz0YsNAPYixinx3gdtq6ScTEEHmDZ4AXqtFSGw=.5f587d8e-8ab1-4ad1-8f90-3bf3a77beda0@github.com>

On Mon, 26 Aug 2024 01:08:38 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.
>
> Hello @jaikiran,
> This is just a friendly reminder. How is the task going?

> I verified that this test code passed. If the test using only UTF-8 is sufficient, this seems to be the best fix.
> ...
> Should I ignore this concern and specify UTF-8 for the test?

Hello @tkiriyama, sorry it took me long to get back to this. I had forgotten what this PR was about. Having reviewed it again and going through the comments, it's good that the test now passes if you use UTF-8. As for whether or not that's OK to do in this specific test, I'm unsure. We will need someone from the compiler team who know more about this test to provide that input.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1745872643

From darcy at openjdk.org  Thu Sep  5 21:53:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Sep 2024 21:53:59 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <5ZAsYJjpuLQrxcpRMOY3h8H_IpO7tgAmczbmoIVkYts=.089531e7-6b14-4dd4-9395-ae7afc1cafbb@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Looks fine; thanks.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284138298

From prappo at openjdk.org  Thu Sep  5 21:53:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 21:53:58 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
Message-ID: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>

This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:

  - [JLS]
  - [JVMS]

Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.

[issues]: https://bugs.openjdk.org/browse/JDK-8339558
[JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
[JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

Commit messages:
 - Initial commit

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

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

From jjg at openjdk.org  Thu Sep  5 22:04:49 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 5 Sep 2024 22:04:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284150971

From liach at openjdk.org  Thu Sep  5 22:10:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 22:10:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
Message-ID: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>

On Thu, 5 Sep 2024 22:01:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332713929

From prappo at openjdk.org  Thu Sep  5 22:17:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 22:17:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
 <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
Message-ID: <-j2KsqOYz6TMGTQ1j6CS3fp7azbiNXcXIaFrvnwX32c=.5cd321a0-d4f0-4187-b635-ab10be5782e0@github.com>

On Thu, 5 Sep 2024 22:08:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> > possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`
> 
> 
> 
> For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

Typography issues are less severe than those fixed in this PR, but I can fix them too.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332721312

From duke at openjdk.org  Fri Sep  6 05:47:19 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 6 Sep 2024 05:47:19 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
Message-ID: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>

I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
The modified code is based on the alternatives given in JEP400.
I verified that the test passed on Windows in both Japanese and English locales with this fix.

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

Commit messages:
 - 8333427: langtools/tools/javac/newlines/NewLineTest.java is failing on Japanese Windows

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

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

From duke at openjdk.org  Fri Sep  6 05:47:19 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 6 Sep 2024 05:47:19 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
Message-ID: <hi2E9XikabnfYAooZC4PZ_SMnKIwyBFDdDbgwSZopf8=.5dffd1d9-137e-4862-b5ac-739c39e083d8@github.com>

On Mon, 3 Jun 2024 11:42:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
> The modified code is based on the alternatives given in JEP400.
> I verified that the test passed on Windows in both Japanese and English locales with this fix.

Could someone from the compiler team please review this PR? It fixes the test regression in certain environments.

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

PR Comment: https://git.openjdk.org/jdk/pull/19519#issuecomment-2333275227

From jpai at openjdk.org  Fri Sep  6 05:47:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Sep 2024 05:47:19 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
Message-ID: <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>

On Mon, 3 Jun 2024 11:42:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
> The modified code is based on the alternatives given in JEP400.
> I verified that the test passed on Windows in both Japanese and English locales with this fix.

test/langtools/tools/javac/newlines/NewLineTest.java line 61:

> 59:                 .run(Task.Expect.FAIL);
> 60: 
> 61:         String encoding = System.getProperty("native.encoding");

Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work.

I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`.
Can you give that change a try on your setup and see if it solves the issue for you?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1639370650

From duke at openjdk.org  Fri Sep  6 05:47:19 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 6 Sep 2024 05:47:19 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>
Message-ID: <C_qPrfceDhDUlKt1uS2IPdK1rZKHT6vbAK5srK3-yuk=.6c742db0-6726-4be7-b00f-139d09876a1f@github.com>

On Fri, 14 Jun 2024 07:08:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
>> The modified code is based on the alternatives given in JEP400.
>> I verified that the test passed on Windows in both Japanese and English locales with this fix.
>
> test/langtools/tools/javac/newlines/NewLineTest.java line 61:
> 
>> 59:                 .run(Task.Expect.FAIL);
>> 60: 
>> 61:         String encoding = System.getProperty("native.encoding");
> 
> Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work.
> 
> I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`.
> Can you give that change a try on your setup and see if it solves the issue for you?

Hello @jaikiran, thank you for your advice.

> What I understand is that javac will print to STDOUT using a PrinterWriter for System.out, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use stdout.encoding value for the character encoding. 

I completely agree with you.

> The default value of stdout.encoding standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that stdout.encoding will be the same value as native.encoding.

I think that in the current implementation,System.out use native.encoding for the character encoding  if stdout.encoding is not specified. The value of native.encoding is derived from the host environment and user settings. It cannot be changed.

> I think to make this deterministic, you might have to update the javac launch command (a few lines above) to pass -J-Dstdout.encoding=UTF-8 and then when reading from the file to which the content was redirected, use StandardCharsets.UTF_8.
> Can you give that change a try on your setup and see if it solves the issue for you?


        new JavacTask(tb, Task.Mode.EXEC)
                .redirect(Task.OutputKind.STDOUT, javacOutput.getPath())
                .options("-J-Dline.separator='@'", "-J-Dstdout.encoding=UTF-8")
                .run(Task.Expect.FAIL);

        List<String> lines = Files.readAllLines(javacOutput.toPath(), StandardCharsets.UTF_8);
        if (lines.size() != 1) {
            throw new AssertionError("The compiler output should have one line only");
        }

I verified that this test code passed. If the test using only UTF-8 is sufficient, this seems to be  the best fix. 
I am concerned that it would be better to test with the default encoding in a test runnning environment if possible. Therefore, I use the generic alternatives exposed in [JEP 400](https://openjdk.org/jeps/400).
Should I ignore this concern and specify UTF-8 for the test?

@jaikiran 
Just a friendly reminder that I need your view.

@jaikiran 
I'm looking forward to your comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1642230032
PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1671923721
PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1705192781

From jpai at openjdk.org  Fri Sep  6 05:47:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Sep 2024 05:47:19 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <C_qPrfceDhDUlKt1uS2IPdK1rZKHT6vbAK5srK3-yuk=.6c742db0-6726-4be7-b00f-139d09876a1f@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>
 <C_qPrfceDhDUlKt1uS2IPdK1rZKHT6vbAK5srK3-yuk=.6c742db0-6726-4be7-b00f-139d09876a1f@github.com>
Message-ID: <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.9e8e1ad4-a837-4a4e-b1b7-cdac83716f2a@github.com>

On Tue, 6 Aug 2024 09:11:31 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/newlines/NewLineTest.java line 61:
>> 
>>> 59:                 .run(Task.Expect.FAIL);
>>> 60: 
>>> 61:         String encoding = System.getProperty("native.encoding");
>> 
>> Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work.
>> 
>> I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`.
>> Can you give that change a try on your setup and see if it solves the issue for you?
>
> @jaikiran 
> I'm looking forward to your comments.

Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1705196105

From duke at openjdk.org  Fri Sep  6 05:47:20 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 6 Sep 2024 05:47:20 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.9e8e1ad4-a837-4a4e-b1b7-cdac83716f2a@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>
 <C_qPrfceDhDUlKt1uS2IPdK1rZKHT6vbAK5srK3-yuk=.6c742db0-6726-4be7-b00f-139d09876a1f@github.com>
 <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.9e8e1ad4-a837-4a4e-b1b7-cdac83716f2a@github.com>
Message-ID: <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3c6ffcf2-f368-47da-bfc4-295e46755995@github.com>

On Tue, 6 Aug 2024 09:12:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @jaikiran 
>> I'm looking forward to your comments.
>
> Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.

Hello @jaikiran,
This is just a friendly reminder. How is the task going?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1730493382

From jpai at openjdk.org  Fri Sep  6 05:47:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Sep 2024 05:47:20 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3c6ffcf2-f368-47da-bfc4-295e46755995@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.c277685d-2311-46e2-b8b9-86f4c2acac1a@github.com>
 <C_qPrfceDhDUlKt1uS2IPdK1rZKHT6vbAK5srK3-yuk=.6c742db0-6726-4be7-b00f-139d09876a1f@github.com>
 <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.9e8e1ad4-a837-4a4e-b1b7-cdac83716f2a@github.com>
 <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3c6ffcf2-f368-47da-bfc4-295e46755995@github.com>
Message-ID: <NfqlTzz0YsNAPYixinx3gdtq6ScTEEHmDZ4AXqtFSGw=.a3c2a864-5072-4c5b-bdbf-f87a79a8ba3f@github.com>

On Mon, 26 Aug 2024 01:08:38 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.
>
> Hello @jaikiran,
> This is just a friendly reminder. How is the task going?

> I verified that this test code passed. If the test using only UTF-8 is sufficient, this seems to be the best fix.
> ...
> Should I ignore this concern and specify UTF-8 for the test?

Hello @tkiriyama, sorry it took me long to get back to this. I had forgotten what this PR was about. Having reviewed it again and going through the comments, it's good that the test now passes if you use UTF-8. As for whether or not that's OK to do in this specific test, I'm unsure. We will need someone from the compiler team who know more about this test to provide that input.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1745872643

From jlahoda at openjdk.org  Fri Sep  6 07:23:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 6 Sep 2024 07:23:02 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds [v2]
In-Reply-To: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
Message-ID: <oQ6AA0xLmHv4W4TqlY6YelQfyix9FiL2Ma2fEG0bx14=.cafafa71-13d0-45fe-aa72-5c5d45fed0f8@github.com>

> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
> 
> Consider this code:
> 
>     sealed interface B permits S1, S2 {}
>     final class S1 implements B {}
>     final class S2 implements B {}
>     record R(B b, B s) {}
>     private void test(R r) {
>         switch (r) {
>             case R(B _, S1 _) -> {}
>             case R(S1 _, B _) -> {}
>             case R(S2 _, S2 _) -> {}
>         }
>     }
> 
> 
> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
> 
> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
> 
> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
> 
> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
> 
> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
> 
> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more ...

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - adjusting javadoc and name.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20836/files
  - new: https://git.openjdk.org/jdk/pull/20836/files/acab89a4..78497255

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20836&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20836&range=00-01

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

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

From jlahoda at openjdk.org  Fri Sep  6 07:25:52 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 6 Sep 2024 07:25:52 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds [v2]
In-Reply-To: <_-BB5r4-1U83vjbam4-tj8y44EKfa5Kpa8xr_TR3cRQ=.5a436d15-b36b-4ac0-a8f3-2115ad4eca36@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
 <_-BB5r4-1U83vjbam4-tj8y44EKfa5Kpa8xr_TR3cRQ=.5a436d15-b36b-4ac0-a8f3-2115ad4eca36@github.com>
Message-ID: <cK6D-foIN8-wHMMK6ju_xsq6zYjelnCq31nf_-MbnKw=.67c872a4-38e9-4362-8f3c-1f0561b70bc1@github.com>

On Tue, 3 Sep 2024 14:43:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - adjusting javadoc and name.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1030:
> 
>> 1028:          * $record($prefix$, $resultOfReduction, $suffix$)
>> 1029:          *
>> 1030:          * useHashes: when true, patterns will be a subject to exact equivalence;
> 
> - will be ~a~ subject
> - two binding~s~ patterns

Done, thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1067:
> 
>> 1065:                              //error recovery, ignore patterns with incorrect number of nested patterns:
>> 1066:                              .filter(pd -> pd.nested.length == nestedPatternsCount)
>> 1067:                              .collect(groupingBy(pd -> useHashes ? pd.hashCode(mismatchingCandidateFin) : 0));
> 
> `groupByHashes` can be renamed into `groupByOnlyMismatchingCandidateDifference` or something else. The `ByHashes` is not applicable any more in the general case.

I've used `groupEquivalenceCandidates` - please let me know if that makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1746629314
PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1746628898

From abimpoudis at openjdk.org  Fri Sep  6 08:09:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Sep 2024 08:09:51 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds [v2]
In-Reply-To: <cK6D-foIN8-wHMMK6ju_xsq6zYjelnCq31nf_-MbnKw=.67c872a4-38e9-4362-8f3c-1f0561b70bc1@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
 <_-BB5r4-1U83vjbam4-tj8y44EKfa5Kpa8xr_TR3cRQ=.5a436d15-b36b-4ac0-a8f3-2115ad4eca36@github.com>
 <cK6D-foIN8-wHMMK6ju_xsq6zYjelnCq31nf_-MbnKw=.67c872a4-38e9-4362-8f3c-1f0561b70bc1@github.com>
Message-ID: <etPKa1AYAm2YWriFmmmH9CeF_k4w-Bf4iC53Grc8C2A=.f2486e37-1125-46c7-9988-82063c0d6f77@github.com>

On Fri, 6 Sep 2024 07:23:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1067:
>> 
>>> 1065:                              //error recovery, ignore patterns with incorrect number of nested patterns:
>>> 1066:                              .filter(pd -> pd.nested.length == nestedPatternsCount)
>>> 1067:                              .collect(groupingBy(pd -> useHashes ? pd.hashCode(mismatchingCandidateFin) : 0));
>> 
>> `groupByHashes` can be renamed into `groupByOnlyMismatchingCandidateDifference` or something else. The `ByHashes` is not applicable any more in the general case.
>
> I've used `groupEquivalenceCandidates` - please let me know if that makes sense.

Perfect!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20836#discussion_r1746682939

From prappo at openjdk.org  Fri Sep  6 09:16:28 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 09:16:28 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Link to 8.1.3 instead of 8.5.1
  
  8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
  Alternatively, the link can be deleted altogether.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/51ffa5ee..2c3d47aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=00-01

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

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

From asotona at openjdk.org  Fri Sep  6 09:27:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 09:27:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
Message-ID: <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>

On Thu, 5 Sep 2024 08:49:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert TestNullHostile to use JUnit Jupiter API

JDK-8317356 subject is "Test ClassFile API if it deals with nulls correctly across the whole API". 

Unfortunately this pull request blindly covers the whole API with a layer of null check, which are redundant in many cases or can be placed better to avoid double-checks, save the bytecode footprint and performance.

With such massive code addition I would also expect performance impact evaluation. 

Below are just few examples of redundant checks, I did not went through the whole code.

src/java.base/share/classes/java/lang/classfile/Annotation.java line 122:

> 120:     static Annotation of(ClassDesc annotationClass,
> 121:                          List<AnnotationElement> elements) {
> 122:         requireNonNull(elements);

Isn't this covered by the method above, where the null check is also redundant?

src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:

> 679:      */
> 680:     static AnnotationValue of(Object value) {
> 681:         requireNonNull(value);

Below is a null test throwing IAE.

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 76:

> 74:         for (var o : options){
> 75:             requireNonNull(o);
> 76:         }

Is this really necessary? I would expect NPE from ClassFile::withOptions .

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 213:

> 211:             requireNonNull(i);
> 212:         }
> 213:         requireNonNull(classToSuperClass);

Obsolete checks.

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

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2285569207
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746787611
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746791566
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746784544
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746796891

From abimpoudis at openjdk.org  Fri Sep  6 10:57:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Sep 2024 10:57:52 GMT
Subject: RFR: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds [v2]
In-Reply-To: <oQ6AA0xLmHv4W4TqlY6YelQfyix9FiL2Ma2fEG0bx14=.cafafa71-13d0-45fe-aa72-5c5d45fed0f8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
 <oQ6AA0xLmHv4W4TqlY6YelQfyix9FiL2Ma2fEG0bx14=.cafafa71-13d0-45fe-aa72-5c5d45fed0f8@github.com>
Message-ID: <rohUrJkJDvFUkHUMR4pEuvgTtSB98geo64F0Vk9iQyk=.921a2cea-83ae-4fab-9740-d7d997573684@github.com>

On Fri, 6 Sep 2024 07:23:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
>> 
>> Consider this code:
>> 
>>     sealed interface B permits S1, S2 {}
>>     final class S1 implements B {}
>>     final class S2 implements B {}
>>     record R(B b, B s) {}
>>     private void test(R r) {
>>         switch (r) {
>>             case R(B _, S1 _) -> {}
>>             case R(S1 _, B _) -> {}
>>             case R(S2 _, S2 _) -> {}
>>         }
>>     }
>> 
>> 
>> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
>> 
>> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
>> 
>> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
>> 
>> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
>> 
>> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
>> 
>> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing whe...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - adjusting javadoc and name.

Thanks Jan. Nice work!

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20836#pullrequestreview-2285945802

From prappo at openjdk.org  Fri Sep  6 12:11:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 12:11:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I understand that a PR might not be the best place for a comment like this. Still, it's highly relevant to the review feedback I've got so far. Also, a PR comment will be seen by more people sooner than a JBS comment. This is by the virtue of being fanned out by the mailing lists.

Some reviewers suggested fixing the typography. I could do it, but I think it will pay us more if we pause and think what the broken typography tells us, which I think is that the design of these tags is not entirely what it should be. 

Currently, these tags are really a specialised form of `@see` and `@linkplain`. The block variant corresponds to `@see` and the inline variant corresponds to `@linkplain`.

Since the tag links to a specific resource, it saves the documentation author keystrokes on typing the link to that resource. Along with the visual consistency of the generated documentation, the author also gets some integrity: the tag links to the same version of the specification as that of the documentation.

Unfortunately, mismatching versions is not the only source of broken integrity. Even if initially the tag is accurate, it may degrade over time by various means. This PR is a good evidence that specification sections can be reordered and that their text can be changed. The problem is not the degradation per se, but that it stays unnoticed indefinitely.

In similar situations, we use external checkers as a post-build documentation test. While it's much better than nothing and is more flexible than changing the tags, failing tests are prone to stay problem-listed indefinitely. Which gets us back to square one.

If like me you think that a broken or irrelevant link is bad, we could make these tags provide more integrity. The tags could check their contents against the actual specification and report an error if the contents are not the same (subject to some typographic and formatting leeway). As for the visual consistency, the tags could also make sure the text they generate is of a particular form by automatically carrying over (some) typography from the specification to the generated documentation.

In my mind, this will require having (an extract from) the specification accessible to the tag. Because build system don't typically have access to the Internet, the specification could be stored in the repo and updated every release, which happens every 6 months.

One problem though is what to do when (not if) a spec is not up-to-date. For example, consider these `@jls` tags in JDK 23:

    package java.lang.runtime;
       ...
     * @jls 5.7.1 Exact Testing Conversions
     * @jls 5.7.2 Unconditionally Exact Testing Conversions
       ...
     * @since 23
     */
    public final class ExactConversionsSupport {

These tags relate to a preview feature, which is documented not in JLS but in an annex to it, which is currently missing due to a build error. If the tags are to strictly check their integrity, a problem like this would prevent a documentation build.

Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2333914768

From nbenalla at openjdk.org  Fri Sep  6 12:42:52 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 6 Sep 2024 12:42:52 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
Message-ID: <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>

On Fri, 6 Sep 2024 09:14:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert TestNullHostile to use JUnit Jupiter API
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:
> 
>> 679:      */
>> 680:     static AnnotationValue of(Object value) {
>> 681:         requireNonNull(value);
> 
> Below is a null test throwing IAE.

The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.

What exceptions would be considered ok when nulls are provided?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747059399

From liach at openjdk.org  Fri Sep  6 13:42:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 13:42:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
 <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
Message-ID: <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>

On Fri, 6 Sep 2024 12:40:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:
>> 
>>> 679:      */
>>> 680:     static AnnotationValue of(Object value) {
>>> 681:         requireNonNull(value);
>> 
>> Below is a null test throwing IAE.
>
> The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.
> 
> What exceptions would be considered ok when nulls are provided?

I think we should prefer NPE instead of IAE for null inputs.

I think we should just remove this method - the format for composite list/array or annotation is not well-defined. We might replace this with a `ofResolvedConstant` to accept primitives and String.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747146758

From asotona at openjdk.org  Fri Sep  6 13:49:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 13:49:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
 <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
 <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>
Message-ID: <-oHMdlEykt9iuwWT6eLH5UjHFxvxrchVv4KahXOxsEo=.78ef2f8e-faf4-4f76-8835-c80f6d4458ce@github.com>

On Fri, 6 Sep 2024 13:39:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.
>> 
>> What exceptions would be considered ok when nulls are provided?
>
> I think we should prefer NPE instead of IAE for null inputs.
> 
> I think we should just remove this method - the format for composite list/array or annotation is not well-defined. We might replace this with a `ofResolvedConstant` to accept primitives and String.

API method removal is not subject of this bug/PR, please discuss it on the mailing list.
Also throwing NPE instead of IAE is a subject for consideration, as it is a factory of AnnotationValue from an Object, where null might be considered as IAE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747156753

From jjg at openjdk.org  Fri Sep  6 15:13:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 6 Sep 2024 15:13:04 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
 <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
Message-ID: <0eesrQjIjIPQpmWyNkorSyQAWTCwWduwpfFHAnFdXTA=.ce7dcc1d-cbdc-4dcf-ac8f-85984a9713ab@github.com>

On Fri, 6 Sep 2024 12:09:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thoughts?

My initial thought is, at least we're working with specific tags (`@jls` and `@jvms`) rather than generic HTML links (`<a href=...>...</a>`), since that permits the kind of detailed analysis and checking you are doing.

Preview-ness is a pervasive feature of JDK these days, on the command-line and in APIs. Perhaps the tags here can be augmented to indicate that a feature is a preview feature, for example, `@jls preview 5.7.2 Unconditionally Exact Testing Conversions`. This could be used not only to affect the generated output, perhaps with <sup>PREVIEW</sup>, but could be used to help both determine the target for such links, and to review such links in subsequent releases. Such management should be part of the responsibilities of the preview-feature owner.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2334271942

From liach at openjdk.org  Fri Sep  6 16:04:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:04:11 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <04Yd7RQbg2OlP3ITFXQoioYo1SfsP8HwUTRejGUJKWM=.6ce414d0-b567-4a24-a066-bb4f5481c7b0@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I think we can ignore the title style aspect for now; the key of these tags has always been to provide a correct link to the specs, so fixing trailing period or section number is more important.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2286639738

From acobbs at openjdk.org  Fri Sep  6 16:34:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 6 Sep 2024 16:34:36 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
Message-ID: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>

> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
> 
> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
> 
> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
> 
> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
> 
> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
> 
> public class Bug {
> 
>     public interface A {
>         int op();
>     }
> 
>     public abstract static class B {
>         public abstract int op();
>     }
> 
>     public abstract static class C extends B implements A {
> 
>         public int test() {
>             return op();   // findMethod("op") returns both A.op() and B.op() here
>         }
>     }
> }
> 
> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.

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

 - Merge branch 'master' into JDK-8337980
 - Avoid crash caused by failure to resolve a valid AmbiguityError.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20533/files
  - new: https://git.openjdk.org/jdk/pull/20533/files/90ae27dc..e0470d52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20533&range=00-01

  Stats: 66011 lines in 1846 files changed: 38131 ins; 18136 del; 9744 mod
  Patch: https://git.openjdk.org/jdk/pull/20533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20533/head:pull/20533

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

From darcy at openjdk.org  Fri Sep  6 22:37:48 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Sep 2024 22:37:48 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
Message-ID: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>

Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

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

Commit messages:
 - Appease jcheck.
 - JDK-8339696: Clarify modeling scope of javax.lang.model.element

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

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

From jlahoda at openjdk.org  Mon Sep  9 05:37:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 9 Sep 2024 05:37:24 GMT
Subject: Integrated: 8326616: tools/javac/patterns/Exhaustiveness.java
 intermittently Timeout signalled after 480 seconds
In-Reply-To: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
References: <RgNwTKnGvOodTRhQ71qyOcGMvCN-y5ebjreaelUiD_4=.0131bbc2-97bd-4430-b0f3-d5a72f1bcce8@github.com>
Message-ID: <qOWnTswf3ouEVpC3ApgvNBMip9DkdFAV3Wppw0vR0bM=.1f75d07e-e830-4f46-9bf2-7cfaf778aada@github.com>

On Tue, 3 Sep 2024 12:31:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch revisits the fix for JDK-8325215 (PR: https://github.com/openjdk/jdk/pull/17949). The problem in that bug was along the following lines.
> 
> Consider this code:
> 
>     sealed interface B permits S1, S2 {}
>     final class S1 implements B {}
>     final class S2 implements B {}
>     record R(B b, B s) {}
>     private void test(R r) {
>         switch (r) {
>             case R(B _, S1 _) -> {}
>             case R(S1 _, B _) -> {}
>             case R(S2 _, S2 _) -> {}
>         }
>     }
> 
> 
> The `switch` is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. If ` case R(S1 _, B _)` is preplaced with ` case R(S1 _, S2 _)`, javac will consider the `switch` to be exhaustive.
> 
> This problem is because to prove that the `switch` is exhaustive, it is necessary to merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, which then can be merged with `R(B _, S1 _)` to form `R(B _, B_)`, and then just `R _`, which means the `switch` is exhaustive.
> 
> But, before JDK-8325215, javac could merge `R(S1 _, B _)` and `R(S2 _, S2 _)` into `R(B _, S2 _)`, because it was looking at the two patterns, set the mismatching component to `0`, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replace `B _` with `S2 _`).
> 
> The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case `R(S1 _, B _)` was expanded to `R(S1 _, B _)`, `R(S1 _, S1 _)` and `R(S1 _, S2 _)`. As a consequence, the merging could proceed, and javac would consider the `switch` to be exhaustive.
> 
> The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
> 
> The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge `R(S1 _, B _)` and `R(S2 _, S2 _)`, because `B` is a supertype of (more general pattern than) `S2`. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the  use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more ...

This pull request has now been integrated.

Changeset: a18d9d84
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a18d9d84cd92b0b7e7c3c83efab1d81773e3a87c
Stats:     75 lines in 2 files changed: 21 ins; 35 del; 19 mod

8326616: tools/javac/patterns/Exhaustiveness.java intermittently Timeout signalled after 480 seconds

Reviewed-by: abimpoudis

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

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

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years
  
  Note: any commit hashes below might be outdated due to subsequent
  history rewriting (e.g. git rebase).
  
   + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
   + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/2c3d47aa..c9518c85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=01-02

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

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

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <w1Tp8gpthta4aiyckqPCgYBYT-d48cE7zYiIhtf6M38=.80190c3b-e495-4eef-a313-58da5ac99fe8@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

Ugh... The most recent change to copyright years caused the bot to remove the "ready" label. Please re-review; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2337578863

From jlahoda at openjdk.org  Mon Sep  9 09:34:04 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 9 Sep 2024 09:34:04 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <B4AVTsnq28NrhOlFmZCrifCnn2LN14RfjIF8FMBIcjM=.95eb6cf7-a020-47ca-b020-a823284c9c44@github.com>

On Fri, 6 Sep 2024 21:49:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20900#pullrequestreview-2289385030

From duke at openjdk.org  Mon Sep  9 10:15:05 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Mon, 9 Sep 2024 10:15:05 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <qICI3aSiL72hbS7lW54uzw8LKP3G9MYL6wVA8DAsO2w=.5685813e-f0f5-4f64-a444-3b603ef8940a@github.com>

On Fri, 6 Sep 2024 21:49:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/20900#pullrequestreview-2289473598

From prappo at openjdk.org  Mon Sep  9 11:49:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 11:49:05 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <IdqTOjb-B7fVCnXRo-jeBnLmvDYTFJ2HtGOXqKuK4Sw=.34be0c68-482e-46ac-9dc5-7fe189f267e3@github.com>

On Fri, 6 Sep 2024 21:49:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

Looks good.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20900#pullrequestreview-2289667289

From liach at openjdk.org  Mon Sep  9 12:09:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 12:09:06 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
Message-ID: <19ozWfaawKNwfzfhGYjnNfSB-S9SYGmPSvFYT5CRob0=.07c930ac-f9e7-4d38-81d3-3528608c5eb0@github.com>

On Mon, 9 Sep 2024 09:19:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years
>   
>   Note: any commit hashes below might be outdated due to subsequent
>   history rewriting (e.g. git rebase).
>   
>    + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2289709280

From prappo at openjdk.org  Mon Sep  9 12:09:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 12:09:07 GMT
Subject: Integrated: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <562NEVvPnRZm-wYVGCbsiMk1JR0xzN1BUOSQ1tlv2YU=.0c338c07-d988-4f94-b1d1-fcfd0736d13e@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

This pull request has now been integrated.

Changeset: 88cccc14
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88cccc14db168876a60b5ea2ae9d0fda7969af9a
Stats:     54 lines in 22 files changed: 1 ins; 1 del; 52 mod

8339631: Fix block @jls and @jvms tags

Reviewed-by: liach, darcy, jjg

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

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

From jlahoda at openjdk.org  Mon Sep  9 13:31:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 9 Sep 2024 13:31:06 GMT
Subject: RFR: 8334870: javac does not accept classfiles with certain
 permitted RuntimeVisibleParameterAnnotations and
 RuntimeInvisibleParameterAnnotations attributes [v3]
In-Reply-To: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
References: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
Message-ID: <kKnCf2WmzaoILDxCoZyDcveO8jw77ucv2hE-YW-HIGU=.e34ecd69-14c4-493f-980f-e12220f329fc@github.com>

> JVMS 4.7.18 and 4.7.19 say this about the entries in the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes:
> 
>> The i'th entry in the parameter_annotations table may, but is not required to, correspond to the i'th parameter descriptor in the method descriptor (?4.3.3).
> 
> When reading classfiles, javac does not follow this specification (which puts no requirements on the number of entries in the attributes), but rather expects as many entries as the `MethodSymbol.type` has (which is either based in the `Signature` attribute, if present, or the method descritor, if `Signature` is not present).
> 
> This patch proposes to adjust javac to accept the attributes with any number of entries, implementing a number of heuristics to map the content of the entries in the attributes to the parameters. There are comments in the code explaining the heuristics.
> 
> javac will ignore the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes it cannot handle with a warning.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Adjusting test to an updated ClassFile API.
 - Merge branch 'master' into JDK-8024694
 - Merge branch 'master' into JDK-8024694
 - Reflecting review feedback.
 - Adding a new bug number.
 - Adjusting heuristics.
 - Fixing tests.
 - Fixing tests.
 - 8024694: javac always expects signature attribute for enum constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19860/files
  - new: https://git.openjdk.org/jdk/pull/19860/files/3404a1f0..5d8cafbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19860&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19860&range=01-02

  Stats: 118935 lines in 2906 files changed: 73366 ins; 29285 del; 16284 mod
  Patch: https://git.openjdk.org/jdk/pull/19860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19860/head:pull/19860

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

From darcy at openjdk.org  Mon Sep  9 15:09:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Sep 2024 15:09:40 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
 [v2]
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <TFaeejBO-TuMFJCglFCxDMH1QNs6iONS_opxs-tuaYQ=.1fd700d1-818a-4a47-a1b7-23f0d5eac95c@github.com>

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

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

  Reflow paragraph.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20900/files
  - new: https://git.openjdk.org/jdk/pull/20900/files/2c213737..ac8ac995

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20900&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20900&range=00-01

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

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

From jjg at openjdk.org  Mon Sep  9 19:13:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 9 Sep 2024 19:13:05 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
 [v2]
In-Reply-To: <TFaeejBO-TuMFJCglFCxDMH1QNs6iONS_opxs-tuaYQ=.1fd700d1-818a-4a47-a1b7-23f0d5eac95c@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
 <TFaeejBO-TuMFJCglFCxDMH1QNs6iONS_opxs-tuaYQ=.1fd700d1-818a-4a47-a1b7-23f0d5eac95c@github.com>
Message-ID: <BwNOQ3F6Cuju60_peZ9ezDndO8DjlwBrvFqsgbH6W6k=.dde58ffb-5748-4530-90c4-62060f98a252@github.com>

On Mon, 9 Sep 2024 15:09:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflow paragraph.

src/java.compiler/share/classes/javax/lang/model/element/package-info.java line 35:

> 33:  * program inside a method body; for example there is no
> 34:  * representation of a {@code for} loop or {@code try}-{@code finally}
> 35:  * block. Concretely, there is no model of the abstract syntax tree

I suggest changing `the` (definite article) to something less definite, like `any`.
This would then correspond to the grammar on line 41 "an AST API"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20900#discussion_r1750793727

From darcy at openjdk.org  Mon Sep  9 19:22:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Sep 2024 19:22:37 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
 [v3]
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <PXdv8X9kS0X-vRcSO7W_57Vg7HUXahY5_UmQBxJE2aE=.23b87973-1b6c-4340-819f-40ad6eebb4d4@github.com>

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

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

  Implement review feedbacck.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20900/files
  - new: https://git.openjdk.org/jdk/pull/20900/files/ac8ac995..53c187db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20900&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20900&range=01-02

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

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

From jjg at openjdk.org  Mon Sep  9 19:22:37 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 9 Sep 2024 19:22:37 GMT
Subject: RFR: 8339696: Clarify modeling scope of javax.lang.model.element
 [v3]
In-Reply-To: <PXdv8X9kS0X-vRcSO7W_57Vg7HUXahY5_UmQBxJE2aE=.23b87973-1b6c-4340-819f-40ad6eebb4d4@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
 <PXdv8X9kS0X-vRcSO7W_57Vg7HUXahY5_UmQBxJE2aE=.23b87973-1b6c-4340-819f-40ad6eebb4d4@github.com>
Message-ID: <m6UxlfQxOw6Xuav4solFmfJfysRIHPU2Q6DaGwdImII=.914df8c4-8c82-4714-a184-e8a2cce53d83@github.com>

On Mon, 9 Sep 2024 19:19:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedbacck.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20900#pullrequestreview-2290760669

From darcy at openjdk.org  Mon Sep  9 19:27:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Sep 2024 19:27:08 GMT
Subject: Integrated: 8339696: Clarify modeling scope of
 javax.lang.model.element
In-Reply-To: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
References: <-dP00kRBNz9fPNfhNJFkWN9PJVAlnZEVi6ADAETG9aE=.3200cd29-55d7-4bdf-ac20-90144cc89f46@github.com>
Message-ID: <tqiVE3TTehsgwvM-W1ndFYJbUo4QXG8BQ4Cf8EtMmTo=.090ef79f-393b-478b-bbde-345e5d91139a@github.com>

On Fri, 6 Sep 2024 21:49:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Clarify that while javax.lang.model does not include an AST API, it is intended to be usable by an AST API.

This pull request has now been integrated.

Changeset: 6b5958d6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b5958d6612a57c48320438981b2eae030927065
Stats:     10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8339696: Clarify modeling scope of javax.lang.model.element

Reviewed-by: jjg, jlahoda, prappo

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

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

From vromero at openjdk.org  Mon Sep  9 19:57:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 9 Sep 2024 19:57:09 GMT
Subject: RFR: 8334870: javac does not accept classfiles with certain
 permitted RuntimeVisibleParameterAnnotations and
 RuntimeInvisibleParameterAnnotations attributes [v3]
In-Reply-To: <kKnCf2WmzaoILDxCoZyDcveO8jw77ucv2hE-YW-HIGU=.e34ecd69-14c4-493f-980f-e12220f329fc@github.com>
References: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
 <kKnCf2WmzaoILDxCoZyDcveO8jw77ucv2hE-YW-HIGU=.e34ecd69-14c4-493f-980f-e12220f329fc@github.com>
Message-ID: <hGBpOY03y1_m1qzhL49XVi0Lw9nCz6uax_cp-H-IuI8=.14a5b184-02e1-49ac-bb9e-89b6ea92f2d1@github.com>

On Mon, 9 Sep 2024 13:31:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JVMS 4.7.18 and 4.7.19 say this about the entries in the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes:
>> 
>>> The i'th entry in the parameter_annotations table may, but is not required to, correspond to the i'th parameter descriptor in the method descriptor (?4.3.3).
>> 
>> When reading classfiles, javac does not follow this specification (which puts no requirements on the number of entries in the attributes), but rather expects as many entries as the `MethodSymbol.type` has (which is either based in the `Signature` attribute, if present, or the method descritor, if `Signature` is not present).
>> 
>> This patch proposes to adjust javac to accept the attributes with any number of entries, implementing a number of heuristics to map the content of the entries in the attributes to the parameters. There are comments in the code explaining the heuristics.
>> 
>> javac will ignore the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes it cannot handle with a warning.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Adjusting test to an updated ClassFile API.
>  - Merge branch 'master' into JDK-8024694
>  - Merge branch 'master' into JDK-8024694
>  - Reflecting review feedback.
>  - Adding a new bug number.
>  - Adjusting heuristics.
>  - Fixing tests.
>  - Fixing tests.
>  - 8024694: javac always expects signature attribute for enum constructors

last changes looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19860#pullrequestreview-2290823684

From jpai at openjdk.org  Tue Sep 10 04:36:42 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 04:36:42 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=09
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From jpai at openjdk.org  Tue Sep 10 05:36:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 05:36:36 GMT
Subject: RFR: 8339810: Cleanup the code in sun.tools.jar.Main to properly close
 resources and use ZipFile during extract
Message-ID: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>

Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?

As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.

No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.

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

Commit messages:
 - 8339810: Cleanup the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

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

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

From cstein at openjdk.org  Tue Sep 10 05:39:17 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Sep 2024 05:39:17 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
Message-ID: <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>

On Tue, 10 Sep 2024 04:36:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - cleanup testExtractNoDestDirWithPFlag() test
>  - merge latest from master branch
>  - merge latest from master branch
>  - convert the new test to junit
>  - merge latest from master branch
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 268:

> 266:         CREATE_UPDATE_INDEX("create.update.index"),
> 267:         OTHER("other"),
> 268:         EXTRACT("extract");

Is the order number important in this non-public `enum`? If not, I would expect `OTHER` to remain the last/highest entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r1751283531

From jlahoda at openjdk.org  Tue Sep 10 06:16:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 10 Sep 2024 06:16:16 GMT
Subject: Integrated: 8334870: javac does not accept classfiles with certain
 permitted RuntimeVisibleParameterAnnotations and
 RuntimeInvisibleParameterAnnotations attributes
In-Reply-To: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
References: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
Message-ID: <b5gSnYppg42PywpZ69d0ZyIIu_ZaiU02BFrLuOzDDUQ=.2286ec68-523b-4ddb-8ae0-5cde0a69d7a7@github.com>

On Mon, 24 Jun 2024 15:06:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JVMS 4.7.18 and 4.7.19 say this about the entries in the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes:
> 
>> The i'th entry in the parameter_annotations table may, but is not required to, correspond to the i'th parameter descriptor in the method descriptor (?4.3.3).
> 
> When reading classfiles, javac does not follow this specification (which puts no requirements on the number of entries in the attributes), but rather expects as many entries as the `MethodSymbol.type` has (which is either based in the `Signature` attribute, if present, or the method descritor, if `Signature` is not present).
> 
> This patch proposes to adjust javac to accept the attributes with any number of entries, implementing a number of heuristics to map the content of the entries in the attributes to the parameters. There are comments in the code explaining the heuristics.
> 
> javac will ignore the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes it cannot handle with a warning.

This pull request has now been integrated.

Changeset: 5e822c24
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e822c24bb42e9027c8d9090d498bca7125d1963
Stats:     1246 lines in 6 files changed: 856 ins; 382 del; 8 mod

8334870: javac does not accept classfiles with certain permitted RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes

Reviewed-by: vromero

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

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

From stephan.herrmann at berlin.de  Tue Sep 10 12:40:30 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 10 Sep 2024 14:40:30 +0200
Subject: widen-unbox-widen vs JEP 455
In-Reply-To: <d2423b79-5269-425c-b199-95c554534548@berlin.de>
References: <d2423b79-5269-425c-b199-95c554534548@berlin.de>
Message-ID: <be6f2008-0ba1-4add-bdb8-700d4feb8e98@berlin.de>

Has anyone found the time to check which outcome is intended according to JEP 455?

Do I understand correctly, that the pattern 'int i' should always match at 
runtime in all cases of the below code?

Alternatively, should we propose to drop the rules for widen-then-unbox 
conversions, because any real benefit of such conversion would require that 
'final' is dropped from any of the boxing classes?

thanks,
Stephan

Am 01.09.24 um 10:44 schrieb Stephan Herrmann:
> I just learned that reference widening followed by unboxing (followed by 
> primitive widening) is deemed a relevant conversion [1]. So I made sure that ecj 
> can handle this in various situation, only to find out that this will make ecj 
> produce code that is behaviorally different from what javac emits.
> 
> Here's my test code challenging this aspect of JEP 455:
> //
> <T extends Short> void typeVariableSingle(T single) {
>  ??? int i1 = single;
>  ??? System.out.print(i1);
>  ??? if (single instanceof int i)
>  ??????? System.out.print(i);
>  ??? else
>  ??????? System.out.print('-');
>  ??? switch (single) {
>  ??????? case int i -> System.out.print(i);
>  ??????? default -> System.out.print('-');
>  ??? }
>  ??? System.out.println();
> }
> <T extends Short> void typeVariableList(List<T> list) {
>  ??? int i1 = list.get(0);
>  ??? System.out.print(i1);
>  ??? if (list.get(0) instanceof int i)
>  ??????? System.out.print(i);
>  ??? else
>  ??????? System.out.print('-');
>  ??? switch (list.get(0)) {
>  ??????? case int i -> System.out.print(i);
>  ??????? default -> System.out.print('-');
>  ??? }
>  ??? System.out.println();
> }
> void wildcard(List<? extends Short> list) {
>  ??? int i1 = list.get(0);
>  ??? System.out.print(i1);
>  ??? if (list.get(0) instanceof int i)
>  ??????? System.out.print(i);
>  ??? else
>  ??????? System.out.print('-');
>  ??? switch (list.get(0)) {
>  ??????? case int i -> System.out.print(i);
>  ??????? default -> System.out.print('-');
>  ??? }
>  ??? System.out.println();
> }
> void main() {
>  ??? Short s = 1;
>  ??? typeVariableSingle(s);
>  ??? typeVariableList(Collections.singletonList(s));
>  ??? wildcard(Collections.singletonList(s));
> }
> //
> 
> compiled with ecj this gives
> 111
> 111
> 111
> 
> compiled with javac the program prints
> 111
> 1-1
> 1-1
> 
> Is this a simple bug in javac, or is there more to it?
> thanks
> Stephan
> 
> [1] see answers to 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-August/004204.html


From prappo at openjdk.org  Tue Sep 10 16:35:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 16:35:14 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
Message-ID: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>

Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20937/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339852
  Stats: 61 lines in 17 files changed: 1 ins; 1 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/20937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20937/head:pull/20937

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

From liach at openjdk.org  Tue Sep 10 16:47:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 16:47:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>

On Tue, 10 Sep 2024 16:29:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 198:

> 196:  *
> 197:  * @apiNote Implementors of this interface may find it convenient
> 198:  * to extend {@link AbstractProcessor} rather than implement this

The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".

src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 55:

> 53:  * <p>In the definitions below, an annotation <i>A</i> has an
> 54:  * annotation interface <i>AI</i>. If <i>AI</i> is a repeatable annotation
> 55:  * interface, the type of the container annotation is <i>AIC</i>.

"the annotation interface of the container annotation is *AIC*"
or
"the containing annotation interface is *AIC*"

To align with the JLS.

src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 192:

> 190: 
> 191:     /**
> 192:      * Returns annotations of the specified type that are <em>associated</em>

Suggestion:

     * Returns annotations of the specified interface that are <em>associated</em>

src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 195:

> 193:      * with this construct.
> 194:      *
> 195:      * If there are no annotations of the specified type associated with this

Suggestion:

     * If there is no annotation of the specified interface associated with this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752303973
PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752305614
PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752306566
PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752306829

From darcy at openjdk.org  Tue Sep 10 16:58:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Sep 2024 16:58:04 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
Message-ID: <iyT_Z2Mp0y-jU4OIWybVUN5yaC1SErOsmSxdpQXmt-8=.99a00535-c0b8-47d2-8077-87cdf2d07753@github.com>

On Tue, 10 Sep 2024 16:40:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 198:
> 
>> 196:  *
>> 197:  * @apiNote Implementors of this interface may find it convenient
>> 198:  * to extend {@link AbstractProcessor} rather than implement this
> 
> The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".

I will admit a higher than average fondness for gerunds ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752323958

From prappo at openjdk.org  Tue Sep 10 17:52:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 17:52:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <iyT_Z2Mp0y-jU4OIWybVUN5yaC1SErOsmSxdpQXmt-8=.99a00535-c0b8-47d2-8077-87cdf2d07753@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <iyT_Z2Mp0y-jU4OIWybVUN5yaC1SErOsmSxdpQXmt-8=.99a00535-c0b8-47d2-8077-87cdf2d07753@github.com>
Message-ID: <htzdudDiOZIil9c1zn04KeVdVxPJgij6xCl5k4zBawI=.bd95f4f0-8b4c-4f88-b348-f096a9467bd7@github.com>

On Tue, 10 Sep 2024 16:54:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 198:
>> 
>>> 196:  *
>>> 197:  * @apiNote Implementors of this interface may find it convenient
>>> 198:  * to extend {@link AbstractProcessor} rather than implement this
>> 
>> The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".
>
> I will admit a higher than average fondness for gerunds ;-)

> The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".

To me, I read it like this: "to extend rather than implement". But if Joe thinks like you do, I will revert this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752419461

From prappo at openjdk.org  Tue Sep 10 18:01:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 18:01:04 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
Message-ID: <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>

On Tue, 10 Sep 2024 16:41:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 55:
> 
>> 53:  * <p>In the definitions below, an annotation <i>A</i> has an
>> 54:  * annotation interface <i>AI</i>. If <i>AI</i> is a repeatable annotation
>> 55:  * interface, the type of the container annotation is <i>AIC</i>.
> 
> "the annotation interface of the container annotation is *AIC*"
> or
> "the containing annotation interface is *AIC*"
> 
> To align with the JLS.

"Type" is appropriate here and in some other locations in the `AnnotatedConstruct` javadoc. I paid attention to the difference between "contain-ing annotation interface" and "contain-er annotation".

@dansmithcode, please correct me if I'm wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752433797

From prappo at openjdk.org  Tue Sep 10 18:06:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 18:06:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
Message-ID: <SX0wc2OEJSNR_esWCc485eKbHpD6Q7o9p_n5_gzxcs8=.eff2bad0-b8ee-4f9f-bfac-f459227842eb@github.com>

On Tue, 10 Sep 2024 16:42:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 192:
> 
>> 190: 
>> 191:     /**
>> 192:      * Returns annotations of the specified type that are <em>associated</em>
> 
> Suggestion:
> 
>      * Returns annotations of the specified interface that are <em>associated</em>

Please see the entire javadoc, not just the parts ended up in this diff. There's one more method that uses this term. In general, "type" should not always be changed to "interface" in the context of annotations.

> src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 195:
> 
>> 193:      * with this construct.
>> 194:      *
>> 195:      * If there are no annotations of the specified type associated with this
> 
> Suggestion:
> 
>      * If there is no annotation of the specified interface associated with this

See the above comment on "type".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752442669
PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752444337

From prappo at openjdk.org  Tue Sep 10 18:12:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 18:12:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
Message-ID: <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>

On Tue, 10 Sep 2024 17:58:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 55:
>> 
>>> 53:  * <p>In the definitions below, an annotation <i>A</i> has an
>>> 54:  * annotation interface <i>AI</i>. If <i>AI</i> is a repeatable annotation
>>> 55:  * interface, the type of the container annotation is <i>AIC</i>.
>> 
>> "the annotation interface of the container annotation is *AIC*"
>> or
>> "the containing annotation interface is *AIC*"
>> 
>> To align with the JLS.
>
> "Type" is appropriate here and in some other locations in the `AnnotatedConstruct` javadoc. I paid attention to the difference between "contain-ing annotation interface" and "contain-er annotation".
> 
> @dansmithcode, please correct me if I'm wrong.

For convenience, here's the rendered documentation in question for JDK 23: https://download.java.net/java/early_access/jdk23/docs/api/java.compiler/javax/lang/model/AnnotatedConstruct.html#:~:text=containing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752455117

From dlsmith at openjdk.org  Tue Sep 10 18:48:04 2024
From: dlsmith at openjdk.org (Dan Smith)
Date: Tue, 10 Sep 2024 18:48:04 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <PcCYvISxVmtxkuXRUwMgt-Gn9aIkYEUwYh3Y0mOZ7Yc=.d6b2fe73-c5b5-42c3-9fbb-f1273037f193@github.com>

On Tue, 10 Sep 2024 16:29:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 592:

> 590: 
> 591:     /**
> 592:      * Returns whether or not {@code s} is a keyword, boolean literal,

"a boolean literal" (since structure was changed from _a_ [A, B, or C] to [an A, a B, or the C]). (same below)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752532635

From liach at openjdk.org  Tue Sep 10 20:24:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 20:24:04 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
Message-ID: <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>

On Tue, 10 Sep 2024 18:09:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> "Type" is appropriate here and in some other locations in the `AnnotatedConstruct` javadoc. I paid attention to the difference between "contain-ing annotation interface" and "contain-er annotation".
>> 
>> @dansmithcode, please correct me if I'm wrong.
>
> For convenience, here's the rendered documentation in question for JDK 23: https://download.java.net/java/early_access/jdk23/docs/api/java.compiler/javax/lang/model/AnnotatedConstruct.html#:~:text=containing

The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit 952dc704

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752674984

From cushon at openjdk.org  Tue Sep 10 20:42:09 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 10 Sep 2024 20:42:09 GMT
Subject: RFR: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions [v2]
In-Reply-To: <Ggm8_uuAUv8gNof1ZqdemcYVksg8hFxjkVGIeAtSRwQ=.4c0e74de-b369-40d9-b9bc-e24c5df85937@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
 <Ggm8_uuAUv8gNof1ZqdemcYVksg8hFxjkVGIeAtSRwQ=.4c0e74de-b369-40d9-b9bc-e24c5df85937@github.com>
Message-ID: <N9HDyXciMgWSdmq_HJKxBkvdNkITK-Dy_m9GtS-b5YQ=.7fa4526e-b9e7-4622-9a13-7270956528a6@github.com>

On Tue, 13 Aug 2024 15:12:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
>> 
>> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
>> 
>> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8336942
>  - Sort entries in nameToAnnotation
>  - 8336942: Improve test coverage for class loading elements with annotations of different retentions

> Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Assistance progressing this pull request towards integration is welcome

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

PR Comment: https://git.openjdk.org/jdk/pull/20287#issuecomment-2341970207

From prappo at openjdk.org  Tue Sep 10 21:42:03 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 21:42:03 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
 <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
Message-ID: <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>

On Tue, 10 Sep 2024 20:21:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For convenience, here's the rendered documentation in question for JDK 23: https://download.java.net/java/early_access/jdk23/docs/api/java.compiler/javax/lang/model/AnnotatedConstruct.html#:~:text=containing
>
> The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit 952dc704

> The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit [952dc70](https://github.com/openjdk/jdk/commit/952dc704024d44c8f37449382fe769320f9dad1c)

@liach, I respect you as a fellow JLS reader. Not only am I aware of that JBS issue, but I also remember the respective PR being reviewed.

Unsurprisingly, I had a similar knee-jerk reaction to the word "type". So, before publishing this PR, I asked a JLS expert on its use in this context. He replied that although in general "type" should not to be conflated with "interface"/"class", in this context it is reasonable to use "type".

However, if we do decide to abandon "type", we need to inspect every use of it in this class very carefully. The closest terminology that I could find is JLS 9.7.1

> The `TypeName` specifies the annotation interface corresponding to the annotation. The annotation is said to be "of" that interface.

and JLS 9.6.3

> An annotation interface `A` is repeatable if its declaration is (meta-)annotated with an `@Repeatable` annotation ([?9.6.4.8](https://docs.oracle.com/javase/specs/jls/se22/html/jls-9.html#jls-9.6.4.8)) whose value element indicates a containing annotation interface of `A`.

Note how slightly dizzying the terminology is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752760437

From prappo at openjdk.org  Tue Sep 10 21:48:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 21:48:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
 <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
 <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>
Message-ID: <Yj_NjzIWdeKNzomXd2tXpZz3bBS41teI7In54RQKuDY=.6b2a3b42-1a5d-4369-b51d-bb5b23d6692e@github.com>

On Tue, 10 Sep 2024 21:39:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit 952dc704
>
>> The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit [952dc70](https://github.com/openjdk/jdk/commit/952dc704024d44c8f37449382fe769320f9dad1c)
> 
> @liach, I respect you as a fellow JLS reader. Not only am I aware of that JBS issue, but I also remember the respective PR being reviewed.
> 
> Unsurprisingly, I had a similar knee-jerk reaction to the word "type". So, before publishing this PR, I asked a JLS expert on its use in this context. He replied that although in general "type" should not to be conflated with "interface"/"class", in this context it is reasonable to use "type".
> 
> However, if we do decide to abandon "type", we need to inspect every use of it in this class very carefully. The closest terminology that I could find is JLS 9.7.1
> 
>> The `TypeName` specifies the annotation interface corresponding to the annotation. The annotation is said to be "of" that interface.
> 
> and JLS 9.6.3
> 
>> An annotation interface `A` is repeatable if its declaration is (meta-)annotated with an `@Repeatable` annotation ([?9.6.4.8](https://docs.oracle.com/javase/specs/jls/se22/html/jls-9.html#jls-9.6.4.8)) whose value element indicates a containing annotation interface of `A`.
> 
> Note how slightly dizzying the terminology is.

Separately, maybe JLS hasn't done its homework in full? See 9.6.4.1. `@Target`:
> It is a compile-time error if the same enum constant appears more than once in the value element of an annotation of type `java.lang.annotation.Target`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752764682

From prappo at openjdk.org  Tue Sep 10 21:54:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 21:54:35 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Dan's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20937/files
  - new: https://git.openjdk.org/jdk/pull/20937/files/ab574c56..76588ba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=00-01

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

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

From prappo at openjdk.org  Tue Sep 10 21:59:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 21:59:08 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <Yj_NjzIWdeKNzomXd2tXpZz3bBS41teI7In54RQKuDY=.6b2a3b42-1a5d-4369-b51d-bb5b23d6692e@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
 <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
 <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>
 <Yj_NjzIWdeKNzomXd2tXpZz3bBS41teI7In54RQKuDY=.6b2a3b42-1a5d-4369-b51d-bb5b23d6692e@github.com>
Message-ID: <OSAiBqUVfyKT04TRb6Zdoy8yeV_Nt33HvzZasRweceA=.58febd24-b0df-4249-bc58-79fb341abc89@github.com>

On Tue, 10 Sep 2024 21:45:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> The "type" terminology is outdated and is already migrated to "class or interface" or the applicable subtype elsewhere: https://bugs.openjdk.org/browse/JDK-8257636 and commit [952dc70](https://github.com/openjdk/jdk/commit/952dc704024d44c8f37449382fe769320f9dad1c)
>> 
>> @liach, I respect you as a fellow JLS reader. Not only am I aware of that JBS issue, but I also remember the respective PR being reviewed.
>> 
>> Unsurprisingly, I had a similar knee-jerk reaction to the word "type". So, before publishing this PR, I asked a JLS expert on its use in this context. He replied that although in general "type" should not to be conflated with "interface"/"class", in this context it is reasonable to use "type".
>> 
>> However, if we do decide to abandon "type", we need to inspect every use of it in this class very carefully. The closest terminology that I could find is JLS 9.7.1
>> 
>>> The `TypeName` specifies the annotation interface corresponding to the annotation. The annotation is said to be "of" that interface.
>> 
>> and JLS 9.6.3
>> 
>>> An annotation interface `A` is repeatable if its declaration is (meta-)annotated with an `@Repeatable` annotation ([?9.6.4.8](https://docs.oracle.com/javase/specs/jls/se22/html/jls-9.html#jls-9.6.4.8)) whose value element indicates a containing annotation interface of `A`.
>> 
>> Note how slightly dizzying the terminology is.
>
> Separately, maybe JLS hasn't done its homework in full? See 9.6.4.1. `@Target`:
>> It is a compile-time error if the same enum constant appears more than once in the value element of an annotation of type `java.lang.annotation.Target`.

Yes, that use of "type" in 9.6.4.1. feels like an overlook.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1752776740

From darcy at openjdk.org  Wed Sep 11 04:03:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Sep 2024 04:03:08 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
Message-ID: <eAl-VokR0w6v1FcG-sC2xsp6r5QHZ4Jhkx2jRHFg7N8=.459d1017-aea8-427a-ad55-5d12004ff7bb@github.com>

On Tue, 10 Sep 2024 21:54:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dan's feedback

Note there were a few prior updates of `javax.lang.model` to accommodate terminology changes made in JLS:

JDK-8257638: Update usage of "type" terminology in javax.lang.model
JDK-8287886: Further terminology updates to match JLS

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

PR Comment: https://git.openjdk.org/jdk/pull/20937#issuecomment-2342571691

From jjg at openjdk.org  Wed Sep 11 22:40:22 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 11 Sep 2024 22:40:22 GMT
Subject: RFR: 8338525: leading and trailing code blocks by indentation
Message-ID: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>

Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.

There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.

1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.

For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

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

Commit messages:
 - JDK-8338525: leading and trailing code blocks by indentation

Changes: https://git.openjdk.org/jdk/pull/20956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338525
  Stats: 128 lines in 4 files changed: 109 ins; 14 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20956/head:pull/20956

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

From prappo at openjdk.org  Thu Sep 12 12:03:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 12 Sep 2024 12:03:08 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <zsfmVvN9yt2rBYmoW8uRAuFEjlJiZJ8jwg2CY4pZrAk=.4ce5a980-be33-4f6f-b0f5-b829fda81b26@github.com>

On Wed, 11 Sep 2024 22:36:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

Looks good.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 596:

> 594:                             var content = getContent(dt);
> 595:                             if (isFirst && dt.getKind() == Kind.MARKDOWN && isIndented(content)) {
> 596:                                 // begins with an indented code block (unusual), so no first sentence

This reminded me of the `snippet` tag, which, in similar circumstances, will be included in the first sentence.

test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownCodeBlocks.java line 497:

> 495:                     package p;
> 496:                     ///     Leading code block
> 497:                     /// Lorum ipsum.

My immediate reaction was to think that it is not a code block because there's no blank line between those two lines; but it is: https://spec.commonmark.org/0.31.2/#example-114

So, all is well here.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20956#pullrequestreview-2299962785
PR Review Comment: https://git.openjdk.org/jdk/pull/20956#discussion_r1756688209
PR Review Comment: https://git.openjdk.org/jdk/pull/20956#discussion_r1756634553

From vromero at openjdk.org  Thu Sep 12 14:59:08 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Sep 2024 14:59:08 GMT
Subject: RFR: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions [v2]
In-Reply-To: <Ggm8_uuAUv8gNof1ZqdemcYVksg8hFxjkVGIeAtSRwQ=.4c0e74de-b369-40d9-b9bc-e24c5df85937@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
 <Ggm8_uuAUv8gNof1ZqdemcYVksg8hFxjkVGIeAtSRwQ=.4c0e74de-b369-40d9-b9bc-e24c5df85937@github.com>
Message-ID: <MaK_LkKYMMzEzCyUPl72aMeJFejgyKBG1DK80R0yNlc=.c5cbd71e-e0fa-465f-a2d2-ceb45c33b548@github.com>

On Tue, 13 Aug 2024 15:12:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
>> 
>> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
>> 
>> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8336942
>  - Sort entries in nameToAnnotation
>  - 8336942: Improve test coverage for class loading elements with annotations of different retentions

Marked as reviewed by vromero (Reviewer).

looks good

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

PR Review: https://git.openjdk.org/jdk/pull/20287#pullrequestreview-2300596217
PR Comment: https://git.openjdk.org/jdk/pull/20287#issuecomment-2346535434

From vromero at openjdk.org  Thu Sep 12 16:21:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Sep 2024 16:21:09 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <3p-GZ30CERYgO0m0s2CxbQ67xbnspSybNpPSUdpcGmM=.fbbc3ddd-7f4a-4acf-9811-2455719f5369@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
 <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
 <Af_eeV6_0vXR5CBcbW_1R3bcncJFPvbenxFxjW_YcTE=.dae8c224-b78b-4b8b-aba1-7643fa93e235@github.com>
 <3p-GZ30CERYgO0m0s2CxbQ67xbnspSybNpPSUdpcGmM=.fbbc3ddd-7f4a-4acf-9811-2455719f5369@github.com>
Message-ID: <H_ZdRDGvSRlYW09e4kaXlk872Nw4JxLCAB70utIJPw0=.368f2e5c-ad96-4bb9-ae98-65cc3819faee@github.com>

On Wed, 28 Aug 2024 09:33:18 GMT, Evemose <duke at openjdk.org> wrote:

> > Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).
> > I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.
> 
> I have decided to write tests before reworking fix. Could you please suggest where could i put it? I have found tools/javac/diags/examples folder, but it seems to only contain negative tests, while I need positive ones. Is there any suitable place for this kind of thing?

most tests for sealed classes are under:
`test/langtools/tools/javac/sealed/`

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2346727332

From cushon at openjdk.org  Thu Sep 12 16:23:29 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 12 Sep 2024 16:23:29 GMT
Subject: RFR: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions [v3]
In-Reply-To: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
Message-ID: <-xrqHySdfFtRKS0rnOZ6N1NK4j9gg5n-j3mian0Mr8Y=.b671acaa-4e4a-4a63-9e48-4362171a5316@github.com>

> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
> 
> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.

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

 - Merge branch 'master' into JDK-8336942
 - Merge branch 'master' into JDK-8336942
 - Sort entries in nameToAnnotation
 - 8336942: Improve test coverage for class loading elements with annotations of different retentions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20287/files
  - new: https://git.openjdk.org/jdk/pull/20287/files/7e5bbd58..d44ee835

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20287&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20287&range=01-02

  Stats: 48462 lines in 1406 files changed: 30418 ins; 10621 del; 7423 mod
  Patch: https://git.openjdk.org/jdk/pull/20287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20287/head:pull/20287

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

From cushon at openjdk.org  Thu Sep 12 16:38:14 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 12 Sep 2024 16:38:14 GMT
Subject: RFR: 8340024: In ClassReader,
 extract a constant for the superclass supertype_index
Message-ID: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>

Hi, please consider this cleanup to extract a literal to a documented constant in `ClassReader`, see [JDK-8340024](https://bugs.openjdk.org/browse/JDK-8340024).

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

Commit messages:
 - 8340024: In ClassReader, extract a constant for the superclass supertype_index

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

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

From cushon at openjdk.org  Thu Sep 12 16:44:03 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 12 Sep 2024 16:44:03 GMT
Subject: RFR: 8340024: In ClassReader,
 extract a constant for the superclass supertype_index
In-Reply-To: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
References: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
Message-ID: <8Qn5kKEmKTd169jwwX8FqsyLCuhet_IkMzAcSm0JTH4=.de01b1bd-d549-43c5-9552-41d151cd399c@github.com>

On Thu, 12 Sep 2024 16:33:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi, please consider this cleanup to extract a literal to a documented constant in `ClassReader`, see [JDK-8340024](https://bugs.openjdk.org/browse/JDK-8340024).

I also noticed this constant shows up a couple times in `TypeAnnotationPosition`, I could also define a shared constant there and reference it in `ClassReader`:

https://github.com/openjdk/jdk/blob/ab9b72c50a5f324e53b8c6535f401cc185b98c75/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java#L828

https://github.com/openjdk/jdk/blob/ab9b72c50a5f324e53b8c6535f401cc185b98c75/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java#L796

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

PR Comment: https://git.openjdk.org/jdk/pull/20970#issuecomment-2346773897

From jjg at openjdk.org  Thu Sep 12 20:00:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 20:00:05 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <zsfmVvN9yt2rBYmoW8uRAuFEjlJiZJ8jwg2CY4pZrAk=.4ce5a980-be33-4f6f-b0f5-b829fda81b26@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
 <zsfmVvN9yt2rBYmoW8uRAuFEjlJiZJ8jwg2CY4pZrAk=.4ce5a980-be33-4f6f-b0f5-b829fda81b26@github.com>
Message-ID: <Ap9bH9dAqf_x0_8qdPEPJ_t_SfzjOkhw5viEjt0QZ88=.da8b7650-2b00-46d6-8696-9965d7ff20e4@github.com>

On Thu, 12 Sep 2024 11:00:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
>> 
>> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
>> 
>> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
>> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
>> 
>> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.
>
> test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownCodeBlocks.java line 497:
> 
>> 495:                     package p;
>> 496:                     ///     Leading code block
>> 497:                     /// Lorum ipsum.
> 
> My immediate reaction was to think that it is not a code block because there's no blank line between those two lines; but it is: https://spec.commonmark.org/0.31.2/#example-114
> 
> So, all is well here.

Yes, you typically need a blank line _before_ an indented code block, to avoid being treated as a continuation of a preceding paragraph, but "unindenting" is enough to end an indented code block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20956#discussion_r1757500658

From jjg at openjdk.org  Thu Sep 12 20:32:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 20:32:06 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <yqRB8KbRXVoOIHmCsrcFIYLwScEyvTNcoftQ66P87vk=.b9a0f56a-b8b4-4971-9dcc-126d8203cc81@github.com>

On Wed, 11 Sep 2024 22:36:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

Grrr, the fix is incomplete.  I went back and tried the example from the JBS issue, and the part related to the annotation in a leading indented code block is still there.


Generating play/test/api/Test.html...
play/test/src/Test.java:2: warning: unknown tag. Unregistered custom tag?
    ///     @Override
            ^

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

PR Comment: https://git.openjdk.org/jdk/pull/20956#issuecomment-2347182668

From duke at openjdk.org  Thu Sep 12 21:55:59 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 12 Sep 2024 21:55:59 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v3]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <6o1L5F2FmyK2DGp6nkZVdLCk8ceZlQDMv8A_HCIbj2g=.065f08f3-2b8e-401d-867f-0dac7230e4e8@github.com>

> Fix is quite hacky, but this is best solution that i came up with without making invasive changes in other parts of jdk. Basically, I check if current symbol is symbol for tree inside of permits clause i na following way:
> 
> 1. env.tree is JCTree.JCClassDecl;
> 2. Tree symbols in extends and implements clauses are already not null
> 3. There is at least one tree with null sym in permits clause (main indicator that permits clause resolution is in process)
> 
> If all three of above are true, the requirment for symbol to be visible is to have sym.owner.outermostClass() == env.tree.sym.outermostClass()
> 
> Not sure if this is a correct way to do it, hope more expirienced people out here could look into it more carefully.
> 
> DEV NOTE: Will add test a bit later
> 
> DEV NOTE 2: I`m not sure if non immidiate private memebrs should also be available in permit clause (like private static class A in private static class B that is in sealed class C should be available in permits clause of C as well). If not, condition on owner of symbol should be tightened a bit

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

 - add attr context flag
 - test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/fd6e673d..7d05c664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=01-02

  Stats: 69 lines in 4 files changed: 53 ins; 15 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From jjg at openjdk.org  Thu Sep 12 22:46:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 22:46:18 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation [v2]
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <yooIylunzspG_tE3wX9Q4HWWI_CoMVVBggVRHqmOISE=.2eb475a9-bb1b-48f4-8393-745374378426@github.com>

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  check Markdown line kind for first line, as well as after newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20956/files
  - new: https://git.openjdk.org/jdk/pull/20956/files/02f10326..9942aa01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20956&range=00-01

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

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

From prappo at openjdk.org  Thu Sep 12 22:46:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 12 Sep 2024 22:46:19 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <yqRB8KbRXVoOIHmCsrcFIYLwScEyvTNcoftQ66P87vk=.b9a0f56a-b8b4-4971-9dcc-126d8203cc81@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
 <yqRB8KbRXVoOIHmCsrcFIYLwScEyvTNcoftQ66P87vk=.b9a0f56a-b8b4-4971-9dcc-126d8203cc81@github.com>
Message-ID: <71V0Rh_HD84O9lgdnPWy68CL-nPhGvY245W6uFR266M=.7616a81b-94ff-4c17-a398-a259fe44a3e9@github.com>

On Thu, 12 Sep 2024 20:29:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Grrr, the fix is incomplete. I went back and tried the example from the JBS issue, and the part related to the annotation in a leading indented code block is still there.
> 
> ```
> Generating play/test/api/Test.html...
> play/test/src/Test.java:2: warning: unknown tag. Unregistered custom tag?
>     ///     @Override
>             ^
> ```

One point for you, minus one point for me. I should've been more careful reviewing the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20956#issuecomment-2347341767

From jjg at openjdk.org  Thu Sep 12 22:46:19 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 22:46:19 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <k0R9WkS6X8hDKi2I5yIGzyEJ5UZz1zDDXW9qLF3i4Zw=.ec30741e-e96e-4d92-9adf-0099da84ad91@github.com>

On Wed, 11 Sep 2024 22:36:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

Updated: in Markdown mode, `DocCommentParser` needs to determine and handle the "kind" of line for the first line as well as after newlines.

The tests are extended to include the specific test case given in the JBS entry.

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

PR Comment: https://git.openjdk.org/jdk/pull/20956#issuecomment-2347364871

From duke at openjdk.org  Thu Sep 12 22:59:08 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 12 Sep 2024 22:59:08 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
 <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
Message-ID: <L_vzBIje9DxfJT5XiTWZ2kNE9NuAA59kPufT26mUjpo=.5b6453c5-63ee-4565-b9b8-343e2522fb4e@github.com>

On Tue, 27 Aug 2024 09:16:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   allowed non-direct members to be permitted
>
> Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).
> 
> I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.

@lahodaj could you review please?

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2347379043

From jonathan.gibbons at oracle.com  Thu Sep 12 23:15:41 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 16:15:41 -0700
Subject: Resigning as Compiler Group Lead
Message-ID: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>

The time has come for me to resign as Lead for the Compiler Group.

It has been my privilege and pleasure to have supported this Group since
the beginning of OpenJDK, and the work to open source `javac` ahead
of the rest of JDK, in the early days of JDK 7.

-- Jon


From jonathan.gibbons at oracle.com  Thu Sep 12 23:16:43 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 12 Sep 2024 16:16:43 -0700
Subject: CFV: New Compiler Group Lead: Maurizio Cimadamore
Message-ID: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>


I hereby nominate Maurizio Cimadamore to Compiler Group Lead [1].

Maurizio is a member of long standing in the OpenJDK Members Group,
and this, the Compiler Group. He is well known as a leading authority
on the Java compiler, javac, and is active in many advanced OpenJDK
Projects, such as Amber, Valhalla, Panama, to name but a few. [4]

Votes are due by COB September 26, 2004.

Only current Members of the Compiler Group [2] are eligible to
vote on this nomination.? Votes must be cast in the open by
replying to this mailing list.

For Simple Majority voting instructions, see [3].

-- Jon

[1]: https://openjdk.org/bylaws#group-lead
[2]: https://openjdk.org/census
[3]: https://openjdk.org/groups#lead-vote
[4]: https://openjdk.org/census#mcimadamore


From alex.buckley at oracle.com  Fri Sep 13 00:04:15 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 12 Sep 2024 17:04:15 -0700
Subject: CFV: New Compiler Group Lead: Maurizio Cimadamore
In-Reply-To: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
References: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
Message-ID: <20b2a71f-c12b-4e9b-b215-90ec95f7909e@oracle.com>

Vote: yes

Alex

From alex.buckley at oracle.com  Fri Sep 13 00:07:59 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 12 Sep 2024 17:07:59 -0700
Subject: Resigning as Compiler Group Lead
In-Reply-To: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
References: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
Message-ID: <f9e5696f-8482-4ac8-a73b-ae659a789965@oracle.com>

On 9/12/2024 4:15 PM, Jonathan Gibbons wrote:
> The time has come for me to resign as Lead for the Compiler Group.
> 
> It has been my privilege and pleasure to have supported this Group since
> the beginning of OpenJDK, and the work to open source `javac` ahead
> of the rest of JDK, in the early days of JDK 7.

Thank you for the time and the care and the leadership you have given to 
this group, which I would sum up in two words: absolutely peerless.

Alex

From angelos.bimpoudis at oracle.com  Fri Sep 13 08:50:57 2024
From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis)
Date: Fri, 13 Sep 2024 08:50:57 +0000
Subject: widen-unbox-widen vs JEP 455
In-Reply-To: <be6f2008-0ba1-4add-bdb8-700d4feb8e98@berlin.de>
References: <d2423b79-5269-425c-b199-95c554534548@berlin.de>
 <be6f2008-0ba1-4add-bdb8-700d4feb8e98@berlin.de>
Message-ID: <IA1PR10MB7515022C2EAFEFFB73316BEC82652@IA1PR10MB7515.namprd10.prod.outlook.com>

Hello Stephan,

Thank you for your feedback and investigation!

Let me recap.

Currently (and correctly) the following two examples work as expected.

```java
Short s = 42;
s instanceof int
// true, because s has static type Short followed by unboxing followed by w.p.c.

Object o = s;
o instanceof int
// false, because o has static type Object followed by narrowing r.c.
// (to Integer, thus false) followed by unboxing
```

However, we realized that javac accepts the following two with
different runtime behavior. In the first case javac loses the static type of
`ls.get(0)`. This has the effect to "guide" the conversion checking not from
`Short` to `int` as expected, but from `Object` to `int`. In the second case
javac inserts a sharp cast in the selector type `(Short) ls.get(0)`.

```java
List<Short> ls = List.of((short) 42);
ls.get(0) instanceof int
// false, since what is executed is ((Object) ls.get(0)) instanceof int

switch(ls.get(0)) {
  case int _ -> true;
  default -> false;
}
// true, since what is executed is ((Short) ls.get(0))
```

(of course, if we would have `List<?>` both return `false`, as expected)

There are two requirements here. `instanceof` is the precondition of safe
casting and safe casting is described in Section 5.5. The second is that
`switch` and `instanceof` should expose the same behaviour.

As your example clearly demonstrates, javac fails to respect this second
requirement. We will address that in javac and add any required JLS
clarification as part of JEP 455 (Preview 2).

Many many thanks!

________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Stephan Herrmann <stephan.herrmann at berlin.de>
Sent: 10 September 2024 14:40
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: widen-unbox-widen vs JEP 455

Has anyone found the time to check which outcome is intended according to JEP 455?

Do I understand correctly, that the pattern 'int i' should always match at
runtime in all cases of the below code?

Alternatively, should we propose to drop the rules for widen-then-unbox
conversions, because any real benefit of such conversion would require that
'final' is dropped from any of the boxing classes?

thanks,
Stephan

Am 01.09.24 um 10:44 schrieb Stephan Herrmann:
> I just learned that reference widening followed by unboxing (followed by
> primitive widening) is deemed a relevant conversion [1]. So I made sure that ecj
> can handle this in various situation, only to find out that this will make ecj
> produce code that is behaviorally different from what javac emits.
>
> Here's my test code challenging this aspect of JEP 455:
> //
> <T extends Short> void typeVariableSingle(T single) {
>      int i1 = single;
>      System.out.print(i1);
>      if (single instanceof int i)
>          System.out.print(i);
>      else
>          System.out.print('-');
>      switch (single) {
>          case int i -> System.out.print(i);
>          default -> System.out.print('-');
>      }
>      System.out.println();
> }
> <T extends Short> void typeVariableList(List<T> list) {
>      int i1 = list.get(0);
>      System.out.print(i1);
>      if (list.get(0) instanceof int i)
>          System.out.print(i);
>      else
>          System.out.print('-');
>      switch (list.get(0)) {
>          case int i -> System.out.print(i);
>          default -> System.out.print('-');
>      }
>      System.out.println();
> }
> void wildcard(List<? extends Short> list) {
>      int i1 = list.get(0);
>      System.out.print(i1);
>      if (list.get(0) instanceof int i)
>          System.out.print(i);
>      else
>          System.out.print('-');
>      switch (list.get(0)) {
>          case int i -> System.out.print(i);
>          default -> System.out.print('-');
>      }
>      System.out.println();
> }
> void main() {
>      Short s = 1;
>      typeVariableSingle(s);
>      typeVariableList(Collections.singletonList(s));
>      wildcard(Collections.singletonList(s));
> }
> //
>
> compiled with ecj this gives
> 111
> 111
> 111
>
> compiled with javac the program prints
> 111
> 1-1
> 1-1
>
> Is this a simple bug in javac, or is there more to it?
> thanks
> Stephan
>
> [1] see answers to
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-August/004204.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240913/05d792d5/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Fri Sep 13 09:12:31 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 10:12:31 +0100
Subject: Resigning as Compiler Group Lead
In-Reply-To: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
References: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
Message-ID: <2ea8449b-e79f-4e18-a89e-88146c3bf299@oracle.com>

Thanks Jon for your great work on javac, javadoc, javap (and several 
other important tools that I'm probably forgetting about right now).

Your mentorship and leadership has been of invaluable help to this group 
(and to this engineer in particular :-)).

Cheers
Maurizio

On 13/09/2024 00:15, Jonathan Gibbons wrote:
> The time has come for me to resign as Lead for the Compiler Group.
>
> It has been my privilege and pleasure to have supported this Group since
> the beginning of OpenJDK, and the work to open source `javac` ahead
> of the rest of JDK, in the early days of JDK 7.
>
> -- Jon
>

From jlahoda at openjdk.org  Fri Sep 13 09:28:41 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 13 Sep 2024 09:28:41 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to compile
Message-ID: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>

Consider code like this:

    int nestedSwitchesInArgumentPosition(Object o1) {
        return id(switch (o1) {
            case R(var o2) -> switch (o2) {
                case R(String s) -> s;
                default -> "n";
            };
            default -> "";
        });
    }

    int id(String s) {
        return s.length();
    }

    int id(int i) {
        return i;
    }


Compiling this fails with a `StackOverflowError`, because:
 - there are speculative attribution happening for the switch expressions,
 - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
 - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
 - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
 - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.

It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.

But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.

The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904

After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.

The intent is that the public API behavior for the `unknownType` should remain the same.

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

Commit messages:
 - 8339296: Record deconstruction pattern in switch fails to compile

Changes: https://git.openjdk.org/jdk/pull/20990/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20990&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339296
  Stats: 174 lines in 6 files changed: 150 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20990/head:pull/20990

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

From duke at openjdk.org  Fri Sep 13 10:25:31 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 13 Sep 2024 10:25:31 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v4]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <cTmCyLgDWCYD2qLh8WRVCTgOJrh_outWBI2oyeD6vrk=.f3f19aca-baee-4d68-bd74-33fdb6f5a2c8@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/7d05c664..b7a5c47e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=02-03

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

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

From prappo at openjdk.org  Fri Sep 13 10:36:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 10:36:04 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <OSAiBqUVfyKT04TRb6Zdoy8yeV_Nt33HvzZasRweceA=.58febd24-b0df-4249-bc58-79fb341abc89@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
 <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
 <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>
 <Yj_NjzIWdeKNzomXd2tXpZz3bBS41teI7In54RQKuDY=.6b2a3b42-1a5d-4369-b51d-bb5b23d6692e@github.com>
 <OSAiBqUVfyKT04TRb6Zdoy8yeV_Nt33HvzZasRweceA=.58febd24-b0df-4249-bc58-79fb341abc89@github.com>
Message-ID: <HSG3n7hFv-so-12-YG0VaW2j5YfjWx6hZIF8we06ZX0=.9ba67d7c-2469-4278-8003-49434c3c3b23@github.com>

On Tue, 10 Sep 2024 21:56:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Separately, maybe JLS hasn't done its homework in full? See 9.6.4.1. `@Target`:
>>> It is a compile-time error if the same enum constant appears more than once in the value element of an annotation of type `java.lang.annotation.Target`.
>
> Yes, that use of "type" in 9.6.4.1. feels like an overlook.

Chen, I suggest we integrate this PR as is but ask JLS experts/authors on the issue. In fact, I've already asked. I suspect that JLS 9.6.4.1 is germane to this discussion. If JLS changes "type" to "interface" in JLS 9.6.4.1, we could change these occurrences of "type" to "interface" in `AnnotatedConstruct` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1758625326

From vromero at openjdk.org  Fri Sep 13 11:53:15 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Sep 2024 11:53:15 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v18]
In-Reply-To: <cuidcUbVnyQuABMA_M8fj4_09RH9UUwEe9dg1k7vAok=.d96cb328-111c-4089-9dd2-12138d741bf8@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <cuidcUbVnyQuABMA_M8fj4_09RH9UUwEe9dg1k7vAok=.d96cb328-111c-4089-9dd2-12138d741bf8@github.com>
Message-ID: <1PVzZ7nofjKL6SFQqI4LSXR63mshgVVOXNV_FxksBdA=.528369bd-641a-4922-a268-4cedded0b252@github.com>

On Wed, 14 Aug 2024 11:16:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
>> 
>> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
>> 
>> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
>> 
>> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
>> 
>> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
>> 
>> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
>> 
>> #### C...
>
> Maurizio Cimadamore 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into lambda_capture
>  - Address review comment
>  - Fix comment
>  - Beef up serializable lambda test
>  - Remove whitespaces
>  - Make sure order of captured vars is the same as before.
>    Do not remove `this$0` from serializable local classes.
>  - Minory style cleanup to get rid of IDE warnings
>  - Drop TranslationContext
>  - Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits
>  - Drop caching of clinit fake symbols in Attr
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/676237cd...6a730ed0

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2302908797

From mcimadamore at openjdk.org  Fri Sep 13 12:07:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 12:07:14 GMT
Subject: Integrated: 8336492: Regression in lambda serialization
In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
Message-ID: <VY58gYa_jahsAGhTXUOInvPpDVqKNfltEGpaT5lg_vA=.2f01cce8-7ba4-4692-811f-0c19ac8d8e6b@github.com>

On Fri, 26 Jul 2024 10:31:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
> 
> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
> 
> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
> 
> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
> 
> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
> 
> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
> 
> #### Compatibility
> 
> This PR chan...

This pull request has now been integrated.

Changeset: 8a4ea09f
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a4ea09fa220f74f2236fc85e197eadf83b65875
Stats:     1652 lines in 16 files changed: 450 ins; 815 del; 387 mod

8336492: Regression in lambda serialization

Reviewed-by: vromero

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

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

From nbenalla at openjdk.org  Fri Sep 13 14:09:11 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 14:09:11 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v4]
In-Reply-To: <1ZqEH21Ms05SQx4dFO0QuChlG8LlsHQGezFU_nBmyGQ=.cac34912-12be-4c16-8c53-917dbe2c37e2@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
 <1ZqEH21Ms05SQx4dFO0QuChlG8LlsHQGezFU_nBmyGQ=.cac34912-12be-4c16-8c53-917dbe2c37e2@github.com>
Message-ID: <3mmcOoYF2Xjp7h7dMyoBhwXvNjZsqE0qaZc7cnAwLiY=.e0d5ace2-121d-4328-a906-18e09755612a@github.com>

On Wed, 4 Sep 2024 18:39:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
>> More details are in the JBS issues
>> 
>> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test run with executors by default

Closing this for now, I need time to adapt parts of this

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

PR Comment: https://git.openjdk.org/jdk/pull/20711#issuecomment-2349049489

From nbenalla at openjdk.org  Fri Sep 13 14:09:12 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 14:09:12 GMT
Subject: Withdrawn: 8337111: Bad HTML checker for generated documentation
In-Reply-To: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
Message-ID: <C0DaKRH9u_9Sr3K-Hbhh3NLrRhtA26MZ7Q9COwQuXOs=.fe0f3ac8-d7f2-4200-896e-54e6a2030e4b@github.com>

On Mon, 26 Aug 2024 09:00:28 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
> More details are in the JBS issues
> 
> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).

This pull request has been closed without being integrated.

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

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

From nbenalla at openjdk.org  Fri Sep 13 14:34:15 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 14:34:15 GMT
Subject: Withdrawn: 8317356: Test ClassFile API if it deals with nulls
 correctly across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <JVvUnbArgv5rFQmn0B0UtuJV9DwKk3hQU5y5QWiKUUo=.8537dde7-c997-4530-b4f6-d6f76ed64754@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

This pull request has been closed without being integrated.

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

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

From vicente.romero at oracle.com  Fri Sep 13 14:37:11 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 13 Sep 2024 10:37:11 -0400
Subject: Resigning as Compiler Group Lead
In-Reply-To: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
References: <c1eb94ed-abb7-44cd-8070-cab75aa7d8a0@oracle.com>
Message-ID: <694911bd-c0e4-4e28-a1c8-3ddc7ae07040@oracle.com>

Thanks you very much for all the time you have put into Java, the 
compiler group and everybody around you. Thanks for all the time you 
have dedicated to mentor me and for always being accessible for a good 
discussion about a myriad of topics. You helped me with my first patch, 
my first patent and many other things, always grateful,

All the best,
Vicente

On 9/12/24 19:15, Jonathan Gibbons wrote:
> The time has come for me to resign as Lead for the Compiler Group.
>
> It has been my privilege and pleasure to have supported this Group since
> the beginning of OpenJDK, and the work to open source `javac` ahead
> of the rest of JDK, in the early days of JDK 7.
>
> -- Jon
>


From vicente.romero at oracle.com  Fri Sep 13 14:40:24 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 13 Sep 2024 10:40:24 -0400
Subject: CFV: New Compiler Group Lead: Maurizio Cimadamore
In-Reply-To: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
References: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
Message-ID: <0245f92e-d4ca-477e-af66-25b28b2ed089@oracle.com>

vote: yes!

Vicente

On 9/12/24 19:16, Jonathan Gibbons wrote:
>
> I hereby nominate Maurizio Cimadamore to Compiler Group Lead [1].
>
> Maurizio is a member of long standing in the OpenJDK Members Group,
> and this, the Compiler Group. He is well known as a leading authority
> on the Java compiler, javac, and is active in many advanced OpenJDK
> Projects, such as Amber, Valhalla, Panama, to name but a few. [4]
>
> Votes are due by COB September 26, 2004.
>
> Only current Members of the Compiler Group [2] are eligible to
> vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list.
>
> For Simple Majority voting instructions, see [3].
>
> -- Jon
>
> [1]: https://openjdk.org/bylaws#group-lead
> [2]: https://openjdk.org/census
> [3]: https://openjdk.org/groups#lead-vote
> [4]: https://openjdk.org/census#mcimadamore
>


From dlsmith at openjdk.org  Fri Sep 13 14:49:05 2024
From: dlsmith at openjdk.org (Dan Smith)
Date: Fri, 13 Sep 2024 14:49:05 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <HSG3n7hFv-so-12-YG0VaW2j5YfjWx6hZIF8we06ZX0=.9ba67d7c-2469-4278-8003-49434c3c3b23@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <Ow_jMFecwwqyQGPzvEciGjqFd7B7n4fh3KS5OXThTNs=.22c683d4-af41-46bd-a29b-48bf1334d2ab@github.com>
 <ZVAvuhRzf897Jj_FYzuUQSt5UO792ZHwWfFhbdCZQGs=.91328d39-5608-41c1-9f77-00308b0fd2e0@github.com>
 <1_sBf0GDmeM7yIYNuyDRxcwo_8f-N2e_pEe3jJpHT4U=.fcbbbe61-9f82-4268-88cb-d54b70fa8061@github.com>
 <M0rCqKptVaLlUxmB1oxuoKFONb8-7qi6eptejoJSY8I=.c0530b87-0fe6-404a-811f-e3cde6fe63b5@github.com>
 <Yj_NjzIWdeKNzomXd2tXpZz3bBS41teI7In54RQKuDY=.6b2a3b42-1a5d-4369-b51d-bb5b23d6692e@github.com>
 <OSAiBqUVfyKT04TRb6Zdoy8yeV_Nt33HvzZasRweceA=.58febd24-b0df-4249-bc58-79fb341abc89@github.com>
 <HSG3n7hFv-so-12-YG0VaW2j5YfjWx6hZIF8we06ZX0=.9ba67d7c-2469-4278-8003-49434c3c3b23@github.com>
Message-ID: <frCE395XzKLuoC7Q7F1cZhDtKbaUGNt0iTAGe6SqI5g=.1bb56f9b-3d3c-427d-8e9c-2a9befe9df21@github.com>

On Fri, 13 Sep 2024 10:33:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes, that use of "type" in 9.6.4.1. feels like an overlook.
>
> Chen, I suggest we integrate this PR as is but ask JLS experts/authors on the issue. In fact, I've already asked. I suspect that JLS 9.6.4.1 is germane to this discussion. If JLS changes "type" to "interface" in JLS 9.6.4.1, we could change these occurrences of "type" to "interface" in `AnnotatedConstruct` too.

There's really nothing wrong with talking about the type of an annotation, just like you can talk about the type of a variable. If it's the most intuitive way to express what you're trying to say, go for it!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1759003606

From prappo at openjdk.org  Fri Sep 13 16:35:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 16:35:07 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <htzdudDiOZIil9c1zn04KeVdVxPJgij6xCl5k4zBawI=.bd95f4f0-8b4c-4f88-b348-f096a9467bd7@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <iyT_Z2Mp0y-jU4OIWybVUN5yaC1SErOsmSxdpQXmt-8=.99a00535-c0b8-47d2-8077-87cdf2d07753@github.com>
 <htzdudDiOZIil9c1zn04KeVdVxPJgij6xCl5k4zBawI=.bd95f4f0-8b4c-4f88-b348-f096a9467bd7@github.com>
Message-ID: <POPw7kkGsCNLDi4Xsy8tZfRmn8WfUCwyw1lheYVCc6M=.9046389a-f2a9-4aa6-a895-9b94bc1970d3@github.com>

On Tue, 10 Sep 2024 17:49:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I will admit a higher than average fondness for gerunds ;-)
>
>> The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".
> 
> To me, I read it like this: "to extend rather than implement". But if Joe thinks like you do, I will revert this.

Since Dan has [replied] on "type" vs "interface", is "implement" vs "implementing" the only place where we disagree? Joe, do you want me to revert it to "implementing"?

[replied]: https://github.com/openjdk/jdk/pull/20937/files/ab574c569166f3200782f4c5e02ae69afddfada4#r1759003606

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1759159470

From joe.darcy at oracle.com  Fri Sep 13 16:49:51 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 13 Sep 2024 09:49:51 -0700
Subject: CFV: New Compiler Group Lead: Maurizio Cimadamore
In-Reply-To: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
References: <d99beb3a-c4a2-480f-8385-87394367a699@oracle.com>
Message-ID: <d3ab3e1b-d4cf-44b5-911b-fe9114609274@oracle.com>

Vote: yes

-Joe

On 9/12/2024 4:16 PM, Jonathan Gibbons wrote:
>
> I hereby nominate Maurizio Cimadamore to Compiler Group Lead [1].
>
> Maurizio is a member of long standing in the OpenJDK Members Group,
> and this, the Compiler Group. He is well known as a leading authority
> on the Java compiler, javac, and is active in many advanced OpenJDK
> Projects, such as Amber, Valhalla, Panama, to name but a few. [4]
>
> Votes are due by COB September 26, 2004.
>
> Only current Members of the Compiler Group [2] are eligible to
> vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list.
>
> For Simple Majority voting instructions, see [3].
>
> -- Jon
>
> [1]: https://openjdk.org/bylaws#group-lead
> [2]: https://openjdk.org/census
> [3]: https://openjdk.org/groups#lead-vote
> [4]: https://openjdk.org/census#mcimadamore
>

From liach at openjdk.org  Fri Sep 13 17:01:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 17:01:05 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
Message-ID: <3hs95r5UNkoXr3cztJmWO0vZactCJ0Ul0EVQnChu5W0=.d88e7d51-94e5-464b-b911-e3b07cfe369d@github.com>

On Tue, 10 Sep 2024 21:54:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dan's feedback

Looks good besides that "implement" verb after "rather than" grammatical debate.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20937#pullrequestreview-2303627614

From darcy at openjdk.org  Fri Sep 13 21:13:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 21:13:07 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <POPw7kkGsCNLDi4Xsy8tZfRmn8WfUCwyw1lheYVCc6M=.9046389a-f2a9-4aa6-a895-9b94bc1970d3@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <tJxMyQbuAo8b_VU9kXD9csjVAq_ztAShEHrOKz4QN_Y=.740c5e4a-5662-4349-986a-4fd81475a3e5@github.com>
 <iyT_Z2Mp0y-jU4OIWybVUN5yaC1SErOsmSxdpQXmt-8=.99a00535-c0b8-47d2-8077-87cdf2d07753@github.com>
 <htzdudDiOZIil9c1zn04KeVdVxPJgij6xCl5k4zBawI=.bd95f4f0-8b4c-4f88-b348-f096a9467bd7@github.com>
 <POPw7kkGsCNLDi4Xsy8tZfRmn8WfUCwyw1lheYVCc6M=.9046389a-f2a9-4aa6-a895-9b94bc1970d3@github.com>
Message-ID: <xMwyhpx8NUO19JipGMlTCPWX8dbLaIxVog3SdUz95c0=.53766e80-04e9-4315-9e29-59e8cd88313c@github.com>

On Fri, 13 Sep 2024 16:32:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> The original grammar was correct: "rather than something" so "implementing" is correct as a noun. Or you can say "to implement".
>> 
>> To me, I read it like this: "to extend rather than implement". But if Joe thinks like you do, I will revert this.
>
> Since Dan has [replied] on "type" vs "interface", is "implement" vs "implementing" the only place where we disagree? Joe, do you want me to revert it to "implementing"?
> 
> [replied]: https://github.com/openjdk/jdk/pull/20937/files/ab574c569166f3200782f4c5e02ae69afddfada4#r1759003606

I'd prefer "implementing" was kept.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1759526009

From darcy at openjdk.org  Fri Sep 13 21:17:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 21:17:05 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
Message-ID: <XtRPGFq_unrvfJcyQ6RbMetuPrUtAoXMXQ5JcKjRWyQ=.3fbc8fac-749c-4645-b30a-6df7bb5c73a9@github.com>

On Tue, 10 Sep 2024 21:54:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dan's feedback

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 499:

> 497:      * Character#isJavaIdentifierPart(int)} returns {@code true}.
> 498:      * This pattern matches regular identifiers, keywords, contextual
> 499:      * keywords, boolean literals, and the null literal.

I don't think it is necessarily more clear remove the explicit listing of the strings in question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1759529077

From prappo at openjdk.org  Fri Sep 13 21:31:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 21:31:09 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v2]
In-Reply-To: <XtRPGFq_unrvfJcyQ6RbMetuPrUtAoXMXQ5JcKjRWyQ=.3fbc8fac-749c-4645-b30a-6df7bb5c73a9@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <SKypItdoCWENW7rb7RVocyU8mVwt3fEbZljtjmN93RY=.1c46b6c5-7212-4a0b-b972-9a9948ab0827@github.com>
 <XtRPGFq_unrvfJcyQ6RbMetuPrUtAoXMXQ5JcKjRWyQ=.3fbc8fac-749c-4645-b30a-6df7bb5c73a9@github.com>
Message-ID: <aKkSRRFlVlBuBXjaxvAHF3eBgRgBgSO52RPy0HXmaQI=.f65a8834-a192-4094-857a-1525cf339f49@github.com>

On Fri, 13 Sep 2024 21:14:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dan's feedback
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 499:
> 
>> 497:      * Character#isJavaIdentifierPart(int)} returns {@code true}.
>> 498:      * This pattern matches regular identifiers, keywords, contextual
>> 499:      * keywords, boolean literals, and the null literal.
> 
> I don't think it is necessarily more clear remove the explicit listing of the strings in question.

Perhaps. I just thought that it's strange to spell them out only here, but refer to them through "x literal(s)" everywhere else in that file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20937#discussion_r1759538760

From ethan at mccue.dev  Sat Sep 14 17:12:01 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 14 Sep 2024 13:12:01 -0400
Subject: Code generating annotation processors break eachother
Message-ID: <CA+NR86iCB5LLJJ4vfvnCw==5rs5F2OpP86=zu7ZsDmDAjWTw=w@mail.gmail.com>

I was investigating why my annotation processing library (
https://github.com/bowbahdoe/magic-bean) was failing to integrate with
mapstruct (https://github.com/mapstruct/mapstruct).

After talking to one of the maintainers of that library (
https://github.com/mapstruct/mapstruct/issues/3710) and making a reproducer
(https://github.com/bowbahdoe/mapstruct-magicbean-repro) we've come to the
conclusion that I have no clue what is going on.

For whatever reason, adding an extra annotation processing round breaks
exhaustiveness checks in pattern matching. Will try to make a more concise
reproducer soon, but sharing here in case anyone happens to have a guess as
to whether its a bug in one of the libraries or javac itself
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240914/67b72c65/attachment.htm>

From duke at openjdk.org  Sat Sep 14 23:34:09 2024
From: duke at openjdk.org (duke)
Date: Sat, 14 Sep 2024 23:34:09 GMT
Subject: Withdrawn: 8336470: Source launcher should work with service loader
 SPI in unnamed module
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <BNl6GiAjaWL8R0TfQjV5X_OdQfz4rf6CsPTg1cfxjWs=.14a22c02-d098-401d-8f3b-99680427f38e@github.com>

On Tue, 16 Jul 2024 11:45:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

This pull request has been closed without being integrated.

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

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

From asotona at openjdk.org  Mon Sep 16 09:41:46 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 09:41:46 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v4]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <kAaIGpyJT28MdMcL9seX5mzfKJjOtnUYPdLqjoGtEe8=.2b70faac-2a32-460e-a7f1-286e43d461ef@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 five commits:

 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=03
  Stats: 718 lines in 165 files changed: 0 ins; 480 del; 238 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

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

From asotona at openjdk.org  Mon Sep 16 09:59:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 09:59:40 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v5]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <SMCHT3gn--56kq0MrvB5sSbiVfUx73vzcRlxm68EcFw=.59bc3b5a-795c-407a-b714-e00f76bc077e@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 six commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=04
  Stats: 718 lines in 165 files changed: 0 ins; 480 del; 238 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

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

From prappo at openjdk.org  Mon Sep 16 13:50:50 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 16 Sep 2024 13:50:50 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v3]
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <nHAr9HaVQ47jcpUQGZCEaySjXqL3TJB2j5iz99CImqA=.c69988a9-b0f3-46e6-b9db-4976251c900a@github.com>

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Revert to "implementing"
 - Merge branch 'master' into 8339852
 - Dan's feedback
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20937/files
  - new: https://git.openjdk.org/jdk/pull/20937/files/76588ba0..9e2c153c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=01-02

  Stats: 14423 lines in 311 files changed: 8735 ins; 3715 del; 1973 mod
  Patch: https://git.openjdk.org/jdk/pull/20937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20937/head:pull/20937

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

From prappo at openjdk.org  Mon Sep 16 14:02:39 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 16 Sep 2024 14:02:39 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v4]
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <7PZcNiRpI0Phut2wFMWpHIJcXzsXFAboWEWLN3SUB2s=.562e80ba-8cb2-4dd0-a085-017d6004db18@github.com>

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years
  
  Note: any commit hashes below might be outdated due to subsequent
  history rewriting (e.g. git rebase).
  
   - revert src/java.compiler/share/classes/javax/annotation/processing/Processor.java as spurious

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20937/files
  - new: https://git.openjdk.org/jdk/pull/20937/files/9e2c153c..8335b7d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20937&range=02-03

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

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

From prappo at openjdk.org  Mon Sep 16 14:02:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 16 Sep 2024 14:02:41 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v3]
In-Reply-To: <nHAr9HaVQ47jcpUQGZCEaySjXqL3TJB2j5iz99CImqA=.c69988a9-b0f3-46e6-b9db-4976251c900a@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <nHAr9HaVQ47jcpUQGZCEaySjXqL3TJB2j5iz99CImqA=.c69988a9-b0f3-46e6-b9db-4976251c900a@github.com>
Message-ID: <JC9WQBBfHUouS51DLXpx-UvnNttRDcp0oJTx4t424GQ=.ead83ad9-6dfc-48cc-a351-50e910e64a34@github.com>

On Mon, 16 Sep 2024 13:50:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Revert to "implementing"
>  - Merge branch 'master' into 8339852
>  - Dan's feedback
>  - Initial commit

Please re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20937#issuecomment-2353008987

From darcy at openjdk.org  Mon Sep 16 16:56:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Sep 2024 16:56:06 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v4]
In-Reply-To: <7PZcNiRpI0Phut2wFMWpHIJcXzsXFAboWEWLN3SUB2s=.562e80ba-8cb2-4dd0-a085-017d6004db18@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <7PZcNiRpI0Phut2wFMWpHIJcXzsXFAboWEWLN3SUB2s=.562e80ba-8cb2-4dd0-a085-017d6004db18@github.com>
Message-ID: <u-SelAhOjC_rwxCjQclQNKNy2lmVBJGiIgoU5wSw1mg=.745bec21-299c-4882-948f-8cc6e74ce533@github.com>

On Mon, 16 Sep 2024 14:02:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years
>   
>   Note: any commit hashes below might be outdated due to subsequent
>   history rewriting (e.g. git rebase).
>   
>    - revert src/java.compiler/share/classes/javax/annotation/processing/Processor.java as spurious

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20937#pullrequestreview-2307202515

From liach at openjdk.org  Mon Sep 16 17:32:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 17:32:05 GMT
Subject: RFR: 8339852: Fix typos in java.compiler documentation [v4]
In-Reply-To: <7PZcNiRpI0Phut2wFMWpHIJcXzsXFAboWEWLN3SUB2s=.562e80ba-8cb2-4dd0-a085-017d6004db18@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
 <7PZcNiRpI0Phut2wFMWpHIJcXzsXFAboWEWLN3SUB2s=.562e80ba-8cb2-4dd0-a085-017d6004db18@github.com>
Message-ID: <t2H1UJMpVCcrNgVKHEqgJ5mwvEoGA_TPik_0Gd8xD8g=.735465e0-dd5e-402f-9f1f-0626da34b772@github.com>

On Mon, 16 Sep 2024 14:02:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years
>   
>   Note: any commit hashes below might be outdated due to subsequent
>   history rewriting (e.g. git rebase).
>   
>    - revert src/java.compiler/share/classes/javax/annotation/processing/Processor.java as spurious

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20937#pullrequestreview-2307293336

From hannesw at openjdk.org  Wed Sep 18 12:57:11 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 18 Sep 2024 12:57:11 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation [v2]
In-Reply-To: <yooIylunzspG_tE3wX9Q4HWWI_CoMVVBggVRHqmOISE=.2eb475a9-bb1b-48f4-8393-745374378426@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
 <yooIylunzspG_tE3wX9Q4HWWI_CoMVVBggVRHqmOISE=.2eb475a9-bb1b-48f4-8393-745374378426@github.com>
Message-ID: <90vdszuyosHF5B-cVIT9kXBcekiBgGc6AHQTZ4xRJ8I=.9c12c4e3-502c-46b1-a965-023cb23e3339@github.com>

On Thu, 12 Sep 2024 22:46:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
>> 
>> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
>> 
>> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
>> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
>> 
>> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check Markdown line kind for first line, as well as after newline

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 499:

> 497:         if (markdown.isIndentedCodeBlock()) {
> 498:             markdown.skipLine();
> 499:             lastNonWhite = bp - 1; // no not include newline or EOF

Typo in comment? Should probably read "do not include ...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20956#discussion_r1765003315

From hannesw at openjdk.org  Wed Sep 18 14:20:10 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 18 Sep 2024 14:20:10 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation [v2]
In-Reply-To: <yooIylunzspG_tE3wX9Q4HWWI_CoMVVBggVRHqmOISE=.2eb475a9-bb1b-48f4-8393-745374378426@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
 <yooIylunzspG_tE3wX9Q4HWWI_CoMVVBggVRHqmOISE=.2eb475a9-bb1b-48f4-8393-745374378426@github.com>
Message-ID: <qJOpZecA3Su3KIcIOvGNHeAM5cx69UzXThMxSVsQLWE=.0682e851-09a4-481f-8fbc-a06102eaf870@github.com>

On Thu, 12 Sep 2024 22:46:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
>> 
>> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
>> 
>> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
>> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
>> 
>> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check Markdown line kind for first line, as well as after newline

Looks good except for typo in comment.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20956#pullrequestreview-2312849809

From darcy at openjdk.org  Wed Sep 18 16:55:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Sep 2024 16:55:32 GMT
Subject: RFR: 8340399: Update comment in SourceVersion for language evolution
 history
Message-ID: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>

Update comment in include recent language evolution.

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

Commit messages:
 - JDK-8340399: Update comment in SourceVersion for language evolution history

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

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

From iris at openjdk.org  Wed Sep 18 17:19:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Sep 2024 17:19:08 GMT
Subject: RFR: 8340399: Update comment in SourceVersion for language
 evolution history
In-Reply-To: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
References: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
Message-ID: <oYdVzJG8pmBU4eQ1iwSTG5OSW0boHb5tHRAwfWPUPRg=.cb325c7e-7aee-458a-8c7b-4d84d64a6ebe@github.com>

On Wed, 18 Sep 2024 16:49:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update comment in include recent language evolution.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21068#pullrequestreview-2313313924

From liach at openjdk.org  Thu Sep 19 17:14:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 17:14:42 GMT
Subject: RFR: 8340399: Update comment in SourceVersion for language
 evolution history
In-Reply-To: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
References: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
Message-ID: <uXdFJrPhzgypnDzr6QkR-UqZhFKj9-84GcsATZ0C2X4=.db70627a-9122-460e-894f-2114b8ca2a9d@github.com>

On Wed, 18 Sep 2024 16:49:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update comment in include recent language evolution.

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 77:

> 75:      *      declared classes and instance main methods in second preview)
> 76:      *  23: no changes (primitive Types in Patterns, instanceof, and
> 77:      *      switch in preview, module Import Declarations in preview,

Suggestion:

     *  23: no changes (primitive types in patterns, instanceof, and
     *      switch in preview, module import declarations in preview,

We want all lowercase like for 21, don't we?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21068#discussion_r1767276191

From darcy at openjdk.org  Thu Sep 19 17:14:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Sep 2024 17:14:43 GMT
Subject: Integrated: 8340399: Update comment in SourceVersion for language
 evolution history
In-Reply-To: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
References: <q_PLF4MNzpeLkbdon4Ow5pfOottkSG2N3Y2ins4EK8s=.35de4579-1896-4804-b776-77328474c08a@github.com>
Message-ID: <lrTYgMqpz917d-McSaBXwNQ18FqvU-dirDad4R0lv-c=.ed73ebe6-a929-49fd-9037-73fc6e364cc5@github.com>

On Wed, 18 Sep 2024 16:49:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update comment in include recent language evolution.

This pull request has now been integrated.

Changeset: ec3cba02
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec3cba02963b5128480bcf62431ab03ecdb26db6
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8340399: Update comment in SourceVersion for language evolution history

Reviewed-by: iris

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

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

From darcy at openjdk.org  Fri Sep 20 19:54:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 20 Sep 2024 19:54:06 GMT
Subject: RFR: 8339781: Better use of Javadoc tags in javax.lang.model
Message-ID: <xXxA3Y6n-RsGDz3JzYOwNwDtZV-gj1X7ybiJX7io4l0=.68bcf4af-6af4-464b-8332-1c7fa04c1abe@github.com>

More extensive use of definition HTML tag and index javadoc tag.

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

Commit messages:
 - Update copyright.
 - Fix typos and expand scope.
 - Merge branch 'master' into JDK-8339781
 - JDK-8339781: Better use of Javadoc tags in javax.lang.model

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

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

From jjg at openjdk.org  Fri Sep 20 21:01:35 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 20 Sep 2024 21:01:35 GMT
Subject: RFR: 8339781: Better use of Javadoc tags in javax.lang.model
In-Reply-To: <xXxA3Y6n-RsGDz3JzYOwNwDtZV-gj1X7ybiJX7io4l0=.68bcf4af-6af4-464b-8332-1c7fa04c1abe@github.com>
References: <xXxA3Y6n-RsGDz3JzYOwNwDtZV-gj1X7ybiJX7io4l0=.68bcf4af-6af4-464b-8332-1c7fa04c1abe@github.com>
Message-ID: <qglzBaBRmLmzlKc3mc8Br31kAGRGVfPEt7lMOZPp2Ik=.c4788272-14c0-4c4a-8cf5-452a505ccb58@github.com>

On Mon, 9 Sep 2024 15:50:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> More extensive use of definition HTML tag and index javadoc tag.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20917#pullrequestreview-2319343264

From darcy at openjdk.org  Fri Sep 20 21:29:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 20 Sep 2024 21:29:37 GMT
Subject: Integrated: 8339781: Better use of Javadoc tags in javax.lang.model
In-Reply-To: <xXxA3Y6n-RsGDz3JzYOwNwDtZV-gj1X7ybiJX7io4l0=.68bcf4af-6af4-464b-8332-1c7fa04c1abe@github.com>
References: <xXxA3Y6n-RsGDz3JzYOwNwDtZV-gj1X7ybiJX7io4l0=.68bcf4af-6af4-464b-8332-1c7fa04c1abe@github.com>
Message-ID: <CvWKzmEnIcAwNb1fYF4uanjAWCaOUI51kh2BahC2VcY=.55d16227-b725-426e-95b1-40bd2a03080e@github.com>

On Mon, 9 Sep 2024 15:50:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> More extensive use of definition HTML tag and index javadoc tag.

This pull request has now been integrated.

Changeset: 08b25611
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08b25611f688ae85c05242afc4cee5b538db4f67
Stats:     20 lines in 4 files changed: 1 ins; 0 del; 19 mod

8339781: Better use of Javadoc tags in javax.lang.model

Reviewed-by: jjg

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

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

From cushon at openjdk.org  Sat Sep 21 07:33:11 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 21 Sep 2024 07:33:11 GMT
Subject: RFR: 8340568: Incorrect escaping of single quotes when pretty-printing
 character literals
Message-ID: <ieW6EuqG7TUPYn5UfFTviC-EtbbiLsa4X7pwYx2uxhM=.88aaddad-029b-4ac6-98a5-7be3140dac4b@github.com>

This change fixes a regression in pretty-printing of character literals after [JDK-8325078](https://bugs.openjdk.org/browse/JDK-8325078). The pretty-printed form of the character literal `'` should be `'''`, intead of `'''`.

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

Commit messages:
 - formatting
 - 8340568: Incorrect escaping of single quotes when pretty-printing character literals

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

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

From prappo at openjdk.org  Mon Sep 23 10:35:40 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 23 Sep 2024 10:35:40 GMT
Subject: Integrated: 8339852: Fix typos in java.compiler documentation
In-Reply-To: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
References: <2wiwvQNhnt46fbaOYOitf9HxFFfsxTzzD0HSzalEHZM=.608c2dfb-89d4-4cf5-8527-843eec3f78c2@github.com>
Message-ID: <U1ZPpfiC7brF67uFc4kRln-hTusuzFIgnooCRl37_0g=.77446952-65e9-4388-a0ba-77129922038c@github.com>

On Tue, 10 Sep 2024 16:29:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to fix typos and formatting issues. Some typos are trivial, others relate to domain vocabulary.

This pull request has now been integrated.

Changeset: 67448b0e
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67448b0eb2e83501b9c1dd0c79c7fe03aaef6b09
Stats:     60 lines in 16 files changed: 1 ins; 1 del; 58 mod

8339852: Fix typos in java.compiler documentation

Reviewed-by: liach, darcy

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

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

From prappo at openjdk.org  Mon Sep 23 16:38:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 23 Sep 2024 16:38:02 GMT
Subject: RFR: 8340680: Fix typos in javax.lang.model.SourceVersion
Message-ID: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>

This PR fixes a few overlooked typos in the recent PR #20937. In particular, it fixes grammar issues which @dansmithcode pointed to: https://github.com/openjdk/jdk/pull/20937#pullrequestreview-2293456337. (#20937 fixed only some of those.)

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

Commit messages:
 - Initial commit

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

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

From henryjen at openjdk.org  Mon Sep 23 17:37:50 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Sep 2024 17:37:50 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when extracting
 to not overwriting existing files
Message-ID: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>

This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

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

Commit messages:
 - Add simple test
 - Support legacy mode
 - 8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

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

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

From henryjen at openjdk.org  Mon Sep 23 18:25:59 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Sep 2024 18:25:59 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v2]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <jKeJSjGa6NgMAe1GsOCg_M5orSZGRckaOCKSGOz6qdQ=.6ffd5298-e851-4f19-b5a5-14d458ae0222@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Fix the long option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/ecef7aaf..f03956a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=00-01

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

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

From jjg at openjdk.org  Mon Sep 23 18:55:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 23 Sep 2024 18:55:11 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation [v3]
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <44xobr78AYPl_gutnLCe-t4IDvqH7esbmIIN4YmHVow=.d49f795e-395d-4cda-8e7f-c3b1e6e06a86@github.com>

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix typo, reported in review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20956/files
  - new: https://git.openjdk.org/jdk/pull/20956/files/9942aa01..363a4e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20956&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20956&range=01-02

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

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

From darcy at openjdk.org  Mon Sep 23 22:18:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Sep 2024 22:18:35 GMT
Subject: RFR: 8340680: Fix typos in javax.lang.model.SourceVersion
In-Reply-To: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
References: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
Message-ID: <Bj-WE7v5O0pkibdmDECar3rkrE4b1AG65cSzW-YrnXU=.5cb6c1d8-9adb-4056-8c51-23e5b895e3c7@github.com>

On Mon, 23 Sep 2024 16:31:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR fixes a few overlooked typos in the recent PR #20937. In particular, it fixes grammar issues which @dansmithcode pointed to: https://github.com/openjdk/jdk/pull/20937#pullrequestreview-2293456337. (#20937 fixed only some of those.)

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21140#pullrequestreview-2323617199

From iris at openjdk.org  Mon Sep 23 23:09:34 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 23 Sep 2024 23:09:34 GMT
Subject: RFR: 8340680: Fix typos in javax.lang.model.SourceVersion
In-Reply-To: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
References: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
Message-ID: <hQSquIhm6DCAn3sMtpm9M1GUzaz3hnFeGHRUF4NRGKQ=.8e2daa3b-1d8b-4db6-a395-b28127a91365@github.com>

On Mon, 23 Sep 2024 16:31:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR fixes a few overlooked typos in the recent PR #20937. In particular, it fixes grammar issues which @dansmithcode pointed to: https://github.com/openjdk/jdk/pull/20937#pullrequestreview-2293456337. (#20937 fixed only some of those.)

Changes match feedback from previous PR.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21140#pullrequestreview-2323670345

From duke at openjdk.org  Tue Sep 24 00:59:37 2024
From: duke at openjdk.org (toshiogata)
Date: Tue, 24 Sep 2024 00:59:37 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
 <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
Message-ID: <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>

On Fri, 23 Aug 2024 22:36:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package.
>> 
>> Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier.
>
>> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?
>> 
>> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.
>> 
>> In the meantime, renaming the files to avoid the problem is the recommended solution.
> 
> Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803

@jonathan-gibbons 
I was wondering if you have had a chance to see my response and aivanov-jdk's question. I would appreciate your reaction. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2369886576

From hannesw at openjdk.org  Tue Sep 24 07:48:38 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 24 Sep 2024 07:48:38 GMT
Subject: RFR: 8338525: Leading and trailing code blocks by indentation [v3]
In-Reply-To: <44xobr78AYPl_gutnLCe-t4IDvqH7esbmIIN4YmHVow=.d49f795e-395d-4cda-8e7f-c3b1e6e06a86@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
 <44xobr78AYPl_gutnLCe-t4IDvqH7esbmIIN4YmHVow=.d49f795e-395d-4cda-8e7f-c3b1e6e06a86@github.com>
Message-ID: <AW1dN1j55WqulqLZFIpbun7ALvm0Y6IyOtGTJIicL7s=.ffdea301-7627-497f-97c8-66cb3f30652b@github.com>

On Mon, 23 Sep 2024 18:55:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
>> 
>> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
>> 
>> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
>> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
>> 
>> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo, reported in review comment

Marked as reviewed by hannesw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20956#pullrequestreview-2324360600

From prappo at openjdk.org  Tue Sep 24 10:51:39 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 24 Sep 2024 10:51:39 GMT
Subject: Integrated: 8340680: Fix typos in javax.lang.model.SourceVersion
In-Reply-To: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
References: <GXJ-dgQSOTXeWWUPf6xN5HtN6SG3BCAHYleU-nqZmO0=.c2eb09ba-78d0-4752-89f4-f9066b546072@github.com>
Message-ID: <XlGFgQC6pMNQcKAG8HOJMsdVp2D8HBZtWDzuEiehs2A=.a4f277bd-9a1a-4927-99c1-f82835a4914d@github.com>

On Mon, 23 Sep 2024 16:31:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR fixes a few overlooked typos in the recent PR #20937. In particular, it fixes grammar issues which @dansmithcode pointed to: https://github.com/openjdk/jdk/pull/20937#pullrequestreview-2293456337. (#20937 fixed only some of those.)

This pull request has now been integrated.

Changeset: 3e673d9e
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e673d9e46ddb464263ff76f385ca5bf98a0b19d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8340680: Fix typos in javax.lang.model.SourceVersion

Reviewed-by: darcy, iris

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

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

From mistria at redhat.com  Tue Sep 24 12:54:37 2024
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 24 Sep 2024 14:54:37 +0200
Subject: Javac not trying to recover unresolved parameterized types
In-Reply-To: <CAFr6BZRBni2skeM0UcvvjYb6bAKQSqFSAEWT5cN4O_aSMNZc0g@mail.gmail.com>
References: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
 <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>
 <CAFr6BZShM39W0dfvORehoDPPcuWwww8dugddnB_qZx6+4cfCjA@mail.gmail.com>
 <e01c998c-86f6-41b5-b45d-aaae24e6b600@oracle.com>
 <CAFr6BZRBni2skeM0UcvvjYb6bAKQSqFSAEWT5cN4O_aSMNZc0g@mail.gmail.com>
Message-ID: <CAFr6BZSVqpR1YZ_D8QmOfyorkHuK0UifsQ-_1jJjeSdmi7L2xw@mail.gmail.com>

And thanks a lot for the fix as well!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240924/4cb56e89/attachment.htm>

From henryjen at openjdk.org  Tue Sep 24 17:01:54 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 24 Sep 2024 17:01:54 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

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

Changes: https://git.openjdk.org/jdk/pull/21141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=02
  Stats: 275 lines in 4 files changed: 274 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

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

From lancea at openjdk.org  Tue Sep 24 19:24:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Sep 2024 19:24:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
Message-ID: <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>

On Tue, 24 Sep 2024 17:01:54 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

Thank you for tackling Henry.

A few initial comments.  Also please make sure to update the copyright on the files being updated to 2024

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:

> 167:         extracted: {0}
> 168: out.kept=\
> 169:         \ \ skipped: {0}

We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:

> 314: main.help.opt.extract.keep-old-files=\
> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
> 316: \                             In particular, if a file appears more than once in an\n\

In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.

Here is the verbiage from tar to give you a start

` -x      Extract to disk from the archive.  If a file with the same name appears more than
             once in the archive, each copy will be extracted, with later copies overwriting
             (replacing) earlier copies.  The long option form is --extract.`

test/jdk/tools/jar/ExtractFilesTest.java line 32:

> 30:  * @build jdk.test.lib.Platform
> 31:  *        jdk.test.lib.util.FileUtils
> 32:  * @run testng ExtractFilesTest

Please convert the test to use junit as we are moving away from testng

test/jdk/tools/jar/ExtractFilesTest.java line 94:

> 92: 
> 93:     @Test
> 94:     public void testExtract() throws IOException {

Please consider adding comments introducing the methods used by the test

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

PR Review: https://git.openjdk.org/jdk/pull/21141#pullrequestreview-2326184792
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773915982
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773915040
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773928582
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773920945

From jjg at openjdk.org  Tue Sep 24 20:12:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 24 Sep 2024 20:12:42 GMT
Subject: Integrated: 8338525: Leading and trailing code blocks by indentation
In-Reply-To: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
References: <LrvAPmF4Mb0FWn5fSwU7ybCE9obE2-RBWriHAa7X4No=.1881c2a1-dfd3-485f-8d94-fef0caa694a5@github.com>
Message-ID: <F9Clh8tnm3jeyhAx762UQUsBgQEq_3iaVSiIPRPVTx4=.fbc230fb-ba53-4192-beae-9a2cfb85fd3e@github.com>

On Wed, 11 Sep 2024 22:36:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review these changes to correct the handling of leading and trailing indented code blocks in a doc comment.
> 
> There are two separate issues here: one for leading indented code blocks and one for trailing indented code blocks.
> 
> 1. Leading indented code blocks: the code to detect the first sentence of a doc comment is modified to detect whether the comment begins with an indented code block. If it does, the first sentence is deemed to be empty, and the body of the doc comment begins with the code block.
> 2. Trailing indented code blocks: the content of the indented code block is marked as significant by updating `lastNonWhite`, which will cause the content to be recorded (not dropped) if the code block is followed by EOF.
> 
> For both cases, simple `DocTree` AST-level tests are provided, as well as full `JavadocTester` tests, that test the end-user view of the generated docs.

This pull request has now been integrated.

Changeset: 0b8c9f6d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b8c9f6d2397dcb480dc5ae109607d86f2b15619
Stats:     214 lines in 5 files changed: 190 ins; 17 del; 7 mod

8338525: Leading and trailing code blocks by indentation

Reviewed-by: hannesw, prappo

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

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

From mcimadamore at openjdk.org  Wed Sep 25 10:08:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 10:08:38 GMT
Subject: RFR: 8340568: Incorrect escaping of single quotes when
 pretty-printing character literals
In-Reply-To: <ieW6EuqG7TUPYn5UfFTviC-EtbbiLsa4X7pwYx2uxhM=.88aaddad-029b-4ac6-98a5-7be3140dac4b@github.com>
References: <ieW6EuqG7TUPYn5UfFTviC-EtbbiLsa4X7pwYx2uxhM=.88aaddad-029b-4ac6-98a5-7be3140dac4b@github.com>
Message-ID: <M-iI1LZ1h8wAKIn3bJYQ6LgRrWsPr4NMAsbiYfvj09E=.4c8acade-9667-413d-9782-7353db7f8fe2@github.com>

On Sat, 21 Sep 2024 07:28:23 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a regression in pretty-printing of character literals after [JDK-8325078](https://bugs.openjdk.org/browse/JDK-8325078). The pretty-printed form of the character literal `'` should be `'''`, intead of `'''`.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21116#pullrequestreview-2327795773

From cushon at openjdk.org  Wed Sep 25 13:15:46 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 25 Sep 2024 13:15:46 GMT
Subject: Integrated: 8340568: Incorrect escaping of single quotes when
 pretty-printing character literals
In-Reply-To: <ieW6EuqG7TUPYn5UfFTviC-EtbbiLsa4X7pwYx2uxhM=.88aaddad-029b-4ac6-98a5-7be3140dac4b@github.com>
References: <ieW6EuqG7TUPYn5UfFTviC-EtbbiLsa4X7pwYx2uxhM=.88aaddad-029b-4ac6-98a5-7be3140dac4b@github.com>
Message-ID: <4nd3DEkK8XFT9GBy43G7SuLbSP-C6yc0PN7sy0Btrw4=.666b6401-f175-48b8-be47-34c39d55d11b@github.com>

On Sat, 21 Sep 2024 07:28:23 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a regression in pretty-printing of character literals after [JDK-8325078](https://bugs.openjdk.org/browse/JDK-8325078). The pretty-printed form of the character literal `'` should be `'''`, intead of `'''`.

This pull request has now been integrated.

Changeset: 083b9808
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/083b98083136933fc51499181f85ca30a77da9e1
Stats:     90 lines in 2 files changed: 89 ins; 0 del; 1 mod

8340568: Incorrect escaping of single quotes when pretty-printing character literals

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.org  Wed Sep 25 14:17:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 14:17:33 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v5]
In-Reply-To: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
Message-ID: <QqMxJwyUID7dSH6zaOXBCjCZdRwReyfz0uTTsc34rS4=.bfbb147a-968c-452f-9e13-07881fbaf603@github.com>

> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
> 
> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
> * `C` is a subclass of `M`?s enclosing class.
> 
> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
> 
> This check is defined in `Reslve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This check is defined in `Reslve::findLocalClassOwner`.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Avoid spurious errors in anon class constructor
 - Do not skip over classes in early construction context
 - Address review comment
 - Fix test summary
 - Initial push

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

Changes: https://git.openjdk.org/jdk/pull/19904/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19904&range=04
  Stats: 390 lines in 18 files changed: 225 ins; 140 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19904.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19904/head:pull/19904

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

From mcimadamore at openjdk.org  Wed Sep 25 14:19:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 14:19:41 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v4]
In-Reply-To: <YZZsjinBCf64QGTz4rkiQe69FrUeSUsAo9CnXGbAK98=.9d8cd8a3-3973-41ce-8478-69246948bf77@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <YZZsjinBCf64QGTz4rkiQe69FrUeSUsAo9CnXGbAK98=.9d8cd8a3-3973-41ce-8478-69246948bf77@github.com>
Message-ID: <fSqo7f8o7yaXRXVLCH7bNoSbDCwIUwTA1rul86p16bw=.cd0f2a63-f3a5-492e-b4b5-26eb703284b4@github.com>

On Fri, 28 Jun 2024 17:45:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
>> 
>> #### Member inner classes
>> 
>> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
>> 
>> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
>> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
>> * `C` is a subclass of `M`?s enclosing class.
>> 
>> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
>> 
>> This check is defined in `Reslve::findSelfContaining`.
>> 
>> #### Local and anonymous inner classes
>> 
>> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
>> 
>> This check is defined in `Reslve::findLocalClassOwner`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

I've updated the PR. After an offline discussion, we concluded that the behavior introduced by this PR is overly powerful. That is, the ability, when looking for a suitable `C.this`, to skip over enclosing classes that are in early-construction context, seems too subtle. In other cases e.g. when we resolve a method name, we pick the first enclosing class that has a method with that name, regardless of whether the signature of that method actually matches or not.

For that same reason, when an enclosing instance is missing, we should just try to see if `C.this` is valid. If not, instead of finding some other `X.Y.this` which might be suitable, it is better to just report an error. The user can manually disambiguate, if required.

For local classes, the considerations in this PR still apply.

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

PR Comment: https://git.openjdk.org/jdk/pull/19904#issuecomment-2374222613

From mcimadamore at openjdk.org  Wed Sep 25 14:25:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 14:25:24 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v6]
In-Reply-To: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
Message-ID: <Z4ycQuIi5_nua_-U5sjw6QHPtqjVXSuzEJxBi6j8ykI=.62559c58-77e5-4447-bffd-876896323d20@github.com>

> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
> 
> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
> * `C` is a subclass of `M`?s enclosing class.
> 
> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
> 
> This check is defined in `Reslve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This check is defined in `Reslve::findLocalClassOwner`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak test and add positive test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19904/files
  - new: https://git.openjdk.org/jdk/pull/19904/files/65c809ae..9dd03993

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

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

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

From acobbs at openjdk.org  Wed Sep 25 14:37:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 25 Sep 2024 14:37:40 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v6]
In-Reply-To: <Z4ycQuIi5_nua_-U5sjw6QHPtqjVXSuzEJxBi6j8ykI=.62559c58-77e5-4447-bffd-876896323d20@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <Z4ycQuIi5_nua_-U5sjw6QHPtqjVXSuzEJxBi6j8ykI=.62559c58-77e5-4447-bffd-876896323d20@github.com>
Message-ID: <jcmtbfpbzkn-Z3j0eBQ9pkpQ8wAiSGWDPDKUYDyPAwE=.dc868831-5d99-4f5a-bcc9-bfa8fbf01278@github.com>

On Wed, 25 Sep 2024 14:25:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
>> 
>> #### Member inner classes
>> 
>> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
>> 
>> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
>> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
>> * `C` is a subclass of `M`?s enclosing class.
>> 
>> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
>> 
>> This check is defined in `Reslve::findSelfContaining`.
>> 
>> #### Local and anonymous inner classes
>> 
>> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
>> 
>> This check is defined in `Reslve::findLocalClassOwner`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak test and add positive test case

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3785:

> 3783:      * Find a suitable reference to an enclosing 'A.this' such that A is a subclass of the provided class symbol.
> 3784:      * Note that this method can match multiple times during the traversal, as multiple enclosing classes can
> 3785:      * be a subclasses of the provided class. Therefore, if this method finds a matching 'A.this' that cannot be accessed

This comment needs updating to reflect the new logic (i.e., stopping now at the first class found).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1775356940

From darcy at openjdk.org  Wed Sep 25 22:39:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 25 Sep 2024 22:39:16 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType
Message-ID: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>

First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

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

Commit messages:
 - JDK-8340721: Clarify special case handling of unboxedType and getWildcardType

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

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

From darcy at openjdk.org  Wed Sep 25 22:39:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 25 Sep 2024 22:39:16 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType
In-Reply-To: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
Message-ID: <m1aKcg8Uh0fvIkgGt8m9-DptrZyTjFNW4So9sZaKOHQ=.07263dd0-c2d5-40c3-bff1-a88099ac57d3@github.com>

On Wed, 25 Sep 2024 22:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

Please also review the CSR [JDK-8340979](https://bugs.openjdk.org/browse/JDK-8340979).

I may augment the regression test to test unions types. Unions types come about from multi-catch statements so getting a hold of one involves a trip with the tree API and not just the standard annotation processing APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/21193#issuecomment-2375386709

From cushon at openjdk.org  Thu Sep 26 01:22:26 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 26 Sep 2024 01:22:26 GMT
Subject: RFR: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions [v4]
In-Reply-To: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
Message-ID: <zOVqraJQwU_ym8QZndFpO77bL9SsBLfEK7nXJxph0Mw=.e6e3a1a8-57d6-4b9a-a88f-2c3cd204ad62@github.com>

> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
> 
> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8336942
 - Merge branch 'master' into JDK-8336942
 - Merge branch 'master' into JDK-8336942
 - Sort entries in nameToAnnotation
 - 8336942: Improve test coverage for class loading elements with annotations of different retentions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20287/files
  - new: https://git.openjdk.org/jdk/pull/20287/files/d44ee835..25e4745f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20287&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20287&range=02-03

  Stats: 161519 lines in 897 files changed: 154024 ins; 3404 del; 4091 mod
  Patch: https://git.openjdk.org/jdk/pull/20287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20287/head:pull/20287

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

From jpai at openjdk.org  Thu Sep 26 06:42:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Sep 2024 06:42:11 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v11]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <fniWHpyWaqa113zVpezK96RX9738kgHwAepJA9Uw4Xo=.be5e5820-5f62-4003-9f73-a87a04cc78f0@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - ... and 11 more: https://git.openjdk.org/jdk/compare/66f16398...c21c8b32

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=10
  Stats: 568 lines in 4 files changed: 558 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From asotona at openjdk.org  Thu Sep 26 08:16:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Sep 2024 08:16:50 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 eight commits:

 - Updated copyright years
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=05
  Stats: 795 lines in 165 files changed: 0 ins; 479 del; 316 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

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

From mcimadamore at openjdk.org  Thu Sep 26 08:41:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Sep 2024 08:41:38 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v6]
In-Reply-To: <jcmtbfpbzkn-Z3j0eBQ9pkpQ8wAiSGWDPDKUYDyPAwE=.dc868831-5d99-4f5a-bcc9-bfa8fbf01278@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <Z4ycQuIi5_nua_-U5sjw6QHPtqjVXSuzEJxBi6j8ykI=.62559c58-77e5-4447-bffd-876896323d20@github.com>
 <jcmtbfpbzkn-Z3j0eBQ9pkpQ8wAiSGWDPDKUYDyPAwE=.dc868831-5d99-4f5a-bcc9-bfa8fbf01278@github.com>
Message-ID: <1yCBMuC7-mNOb48V1FhPOx1nmbj3nD2476h3b_CfNlc=.f6235cc2-5f09-47b4-8f87-a3d4b0939b8d@github.com>

On Wed, 25 Sep 2024 14:35:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak test and add positive test case
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3785:
> 
>> 3783:      * Find a suitable reference to an enclosing 'A.this' such that A is a subclass of the provided class symbol.
>> 3784:      * Note that this method can match multiple times during the traversal, as multiple enclosing classes can
>> 3785:      * be a subclasses of the provided class. Therefore, if this method finds a matching 'A.this' that cannot be accessed
> 
> This comment needs updating to reflect the new logic (i.e., stopping now at the first class found).

Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1776635186

From mcimadamore at openjdk.org  Thu Sep 26 08:48:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Sep 2024 08:48:20 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v7]
In-Reply-To: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
Message-ID: <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>

> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
> 
> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
> * `C` is a subclass of `M`?s enclosing class.
> 
> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
> 
> This check is defined in `Reslve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This check is defined in `Reslve::findLocalClassOwner`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19904/files
  - new: https://git.openjdk.org/jdk/pull/19904/files/9dd03993..4c271b7d

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

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

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

From prappo at openjdk.org  Thu Sep 26 11:37:43 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 26 Sep 2024 11:37:43 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType
In-Reply-To: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
Message-ID: <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>

On Wed, 25 Sep 2024 22:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 56:

> 54:  * In the reference implementation, handling {@linkplain ErrorType
> 55:  * error types} generally does not cause an {@code
> 56:  * UnsupportedOperationException} from the methods in this interface.

Did you really mean `UnsupportedOperationException` and not `IllegalArgumentException`?

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 50:

> 48:     private TypeMirror       stringType;
> 49:     private ArrayType        arrayType;
> 50:     private DeclaredType     declaredType;

`declaredType` is assigned but never used.

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 51:

> 49:     private ArrayType        arrayType;
> 50:     private DeclaredType     declaredType;
> 51:     // private ErrorType        errorType; // skip for now

Any plans on how to test `ErrorType` in the future?

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 137:

> 135:      */
> 136:     void testUnboxedType() {
> 137:         // Only DeclaredType's for wrapper classes should have unboxing converions defined.

converSions

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 149:

> 147:             try {
> 148:                 PrimitiveType pt = types.unboxedType(tm);
> 149:             } catch(IllegalArgumentException iae) {

Here and elsewhere in this file: if some of the calls didn't throw IAE, the test would still pass. Is this your goal?

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 171:

> 169:         for (TypeMirror tm : invalidInputs) {
> 170:             try {
> 171:                 WildcardType wc1 = types.getWildcardType(tm,   null);

Calling getWildcardType for an array type does not throw IAE; is this expected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776773575
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776806233
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776807030
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776811918
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776879313
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1776883671

From liach at openjdk.org  Thu Sep 26 14:06:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 14:06:41 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <v_TJ9AvGQXpaR3IgjRk_ePx_vx9gpEkD6E-Gjcma-1c=.16844e0e-5445-4ce9-87ba-0ebc0389ea26@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

All `@since` tags in the `java.lang.classfile` directory are `@since 24`.

@nizarbenalla Is it possible to enable the since checker in java.lang.classfile and its nested packages.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2331373411

From cushon at openjdk.org  Thu Sep 26 15:13:42 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 26 Sep 2024 15:13:42 GMT
Subject: Integrated: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions
In-Reply-To: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
Message-ID: <DNwjtmvcGm9a2DNfDi_yMVdZi0DPNB0o4-sJQyszpMk=.76ceecfc-59bc-4bcc-87b6-0301d483ee1a@github.com>

On Mon, 22 Jul 2024 23:05:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
> 
> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.

This pull request has now been integrated.

Changeset: e36ce5f0
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e36ce5f0341e8d0ec06cb12d0b2c0aa084401021
Stats:     15 lines in 1 file changed: 14 ins; 0 del; 1 mod

8336942: Improve test coverage for class loading elements with annotations of different retentions

Reviewed-by: vromero

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

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

From darcy at openjdk.org  Thu Sep 26 16:48:17 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 16:48:17 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
Message-ID: <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>

> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

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/21193/files
  - new: https://git.openjdk.org/jdk/pull/21193/files/ff630ef9..5d7309ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21193&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21193&range=00-01

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

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

From darcy at openjdk.org  Thu Sep 26 16:48:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 16:48:18 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
Message-ID: <8HVT_qrx325UCPgL0K0mYEe1nA9rHo6gHs8TLG0tr8E=.64355bf3-28a0-4313-8943-157d6e58fd83@github.com>

On Thu, 26 Sep 2024 10:10:11 GMT, Pavel Rappo <prappo 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/util/Types.java line 56:
> 
>> 54:  * In the reference implementation, handling {@linkplain ErrorType
>> 55:  * error types} generally does not cause an {@code
>> 56:  * UnsupportedOperationException} from the methods in this interface.
> 
> Did you really mean `UnsupportedOperationException` and not `IllegalArgumentException`?

Yes, meant IAE; will correct in the next push.

> test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 171:
> 
>> 169:         for (TypeMirror tm : invalidInputs) {
>> 170:             try {
>> 171:                 WildcardType wc1 = types.getWildcardType(tm,   null);
> 
> Calling getWildcardType for an array type does not throw IAE; is this expected?

Will correct in next push; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1777430381
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1777432454

From nbenalla at openjdk.org  Thu Sep 26 17:13:39 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Sep 2024 17:13:39 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I ran it and all the tags seem to be correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2377503375

From asotona at openjdk.org  Thu Sep 26 17:35:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Sep 2024 17:35:36 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
 <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>
Message-ID: <KvmN5DbwlGlNNAMMKfh3anymX7_J6-Q1R-TL53Riwok=.a0767f21-84fb-402e-b219-e455edee2cf1@github.com>

On Thu, 26 Sep 2024 17:11:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I ran it and all the tags seem to be correct.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2377551118

From darcy at openjdk.org  Fri Sep 27 00:42:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Sep 2024 00:42:40 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
Message-ID: <PH5k94dfIRdwdqQ7LdlkNDPZz3OxHImoXwImLkp5jzU=.19995e61-4fcf-475f-9fbc-6a1b0c69b807@github.com>

On Thu, 26 Sep 2024 11:32:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 149:
> 
>> 147:             try {
>> 148:                 PrimitiveType pt = types.unboxedType(tm);
>> 149:             } catch(IllegalArgumentException iae) {
> 
> Here and elsewhere in this file: if some of the calls didn't throw IAE, the test would still pass. Is this your goal?

Good catch; corrected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1777880972

From henryjen at openjdk.org  Fri Sep 27 01:41:33 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 01:41:33 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedbacks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/de53309d..6192de61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=02-03

  Stats: 284 lines in 4 files changed: 246 ins; 10 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

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

From henryjen at openjdk.org  Fri Sep 27 01:46:36 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 01:46:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
Message-ID: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>

On Tue, 24 Sep 2024 19:16:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:
> 
>> 167:         extracted: {0}
>> 168: out.kept=\
>> 169:         \ \ skipped: {0}
> 
> We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk

I follow existing pattern with short status update. Open to suggestions.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:
> 
>> 314: main.help.opt.extract.keep-old-files=\
>> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
>> 316: \                             In particular, if a file appears more than once in an\n\
> 
> In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.
> 
> Here is the verbiage from tar to give you a start
> 
> ` -x      Extract to disk from the archive.  If a file with the same name appears more than
>              once in the archive, each copy will be extracted, with later copies overwriting
>              (replacing) earlier copies.  The long option form is --extract.`

Updated.

> test/jdk/tools/jar/ExtractFilesTest.java line 32:
> 
>> 30:  * @build jdk.test.lib.Platform
>> 31:  *        jdk.test.lib.util.FileUtils
>> 32:  * @run testng ExtractFilesTest
> 
> Please convert the test to use junit as we are moving away from testng

Done. Also add a test case for multiple manifest files in the same archive as we mentioned such use case in the help text.

> test/jdk/tools/jar/ExtractFilesTest.java line 94:
> 
>> 92: 
>> 93:     @Test
>> 94:     public void testExtract() throws IOException {
> 
> Please consider adding comments introducing the methods used by the test

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777910329
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777909703
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777911075
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777910602

From prappo at openjdk.org  Fri Sep 27 09:01:44 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 27 Sep 2024 09:01:44 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
Message-ID: <ZqKvJBjOaHMNvwT3BV4rpu7XIjMbm_7d9DifEwWtTsM=.6854d2ac-d83c-43bd-9097-0b6d98f96723@github.com>

On Thu, 26 Sep 2024 16:48:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 147:

> 145:             try {
> 146:                 PrimitiveType pt = types.unboxedType(tm);
> 147:                 throw new RuntimeException("Should not reach" + tm);

Suggestion:

                throw new RuntimeException("Should not reach " + tm);

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 164:

> 162:         // Reference types are ArrayType, DeclaredType, ErrorType, NullType, TypeVariable
> 163:         // non-reference: ExecutableType, IntersectionType, NoType, PrimitiveType, UnionType, WildcardType
> 164:         var invalidInputs = List.of( arrayType,

Do we need to change `getWildcardType`'s behaviour for `ArrayType` or specification? `ArrayType` is a reference type, and `getWildcardType` is now specified to throw IAE for all reference types.

test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 177:

> 175:             try {
> 176:                 WildcardType wc2 = types.getWildcardType(null, tm);
> 177:                 throw new RuntimeException("Should not reach" + tm);

Suggestion:

                throw new RuntimeException("Should not reach " + tm);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1778262300
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1778281333
PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1778262044

From mcimadamore at openjdk.org  Fri Sep 27 12:04:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 12:04:36 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>

On Fri, 13 Sep 2024 09:23:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 2424:

> 2422:         }
> 2423: 
> 2424:         @Override @DefinedBy(Api.LANGUAGE_MODEL)

Modelling-wise, I'm not sure. It almost seems as if `UnknownType` should be subclassed by `ErrorType` and not the other way around. Is there a specific reason you went for this?

test/langtools/tools/javac/types/UnknownTypeTest.java line 46:

> 44: import java.util.Objects;
> 45: 
> 46: public class UnknownTypeTest extends TypeHarness {

Nice test!

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

PR Review: https://git.openjdk.org/jdk/pull/20990#pullrequestreview-2333548497
PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778507224
PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778505062

From mcimadamore at openjdk.org  Fri Sep 27 12:13:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 12:13:37 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
Message-ID: <TYta0JPCgO-etnMPEUCclfqqUeIVGgbmKArVcucp514=.5ceb79e0-a612-47cb-8cf9-d6865db9d0d8@github.com>

On Thu, 26 Sep 2024 16:48:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.
>
> 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/util/Types.java line 280:

> 278:      *
> 279:      * @throws IllegalArgumentException if bounds are not valid,
> 280:      * including for types that are <em>not</em> {@linkplain ReferenceType

I find "including for types" hard to parse and connect to the previous clause. Did you mean "e.g. if if the bounds are not reference types" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1778518313

From jlahoda at openjdk.org  Fri Sep 27 12:23:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 27 Sep 2024 12:23:35 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
Message-ID: <0W9RhqZXr2NXr3Gel2gyRqf9F59HL87SAQ6-x2_pmUA=.3d9668e7-07f6-4400-9bf8-b0d7090daf1a@github.com>

On Fri, 27 Sep 2024 12:00:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Consider code like this:
>> 
>>     int nestedSwitchesInArgumentPosition(Object o1) {
>>         return id(switch (o1) {
>>             case R(var o2) -> switch (o2) {
>>                 case R(String s) -> s;
>>                 default -> "n";
>>             };
>>             default -> "";
>>         });
>>     }
>> 
>>     int id(String s) {
>>         return s.length();
>>     }
>> 
>>     int id(int i) {
>>         return i;
>>     }
>> 
>> 
>> Compiling this fails with a `StackOverflowError`, because:
>>  - there are speculative attribution happening for the switch expressions,
>>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
>> 
>> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
>> 
>> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
>> 
>> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
>> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
>> 
>> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
>> 
>> The intent is that the public API behavior for the `unknownType` should remain the same.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 2424:
> 
>> 2422:         }
>> 2423: 
>> 2424:         @Override @DefinedBy(Api.LANGUAGE_MODEL)
> 
> Modelling-wise, I'm not sure. It almost seems as if `UnknownType` should be subclassed by `ErrorType` and not the other way around. Is there a specific reason you went for this?

I would see the `UnknownType` as a specific kind of an erroneous type (and hence `UnknownType` being a subtype or erroneous, as it is here).

But, even from a practical point of view - `ErrorType` basically must extend `ClassType`, I think, so implanting `UnknownType` in there seems difficult.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778530042

From jlahoda at openjdk.org  Fri Sep 27 12:30:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 27 Sep 2024 12:30:38 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
Message-ID: <5kW66NJeIr4Vd1Q6iAV0if5lXtZW9IaCrTOsPKkeQ8w=.75965288-6372-4799-8ec7-2314c3ebb85f@github.com>

On Fri, 27 Sep 2024 12:01:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.

I don't disagree. I think we need to see if we can move the completeness computation to a later point, and maybe even skip the exhaustiveness check during speculative attribution. But, having a type that crashes the compiler when sent to an innocuous method seemed relatively important to fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/20990#issuecomment-2379157880

From mcimadamore at openjdk.org  Fri Sep 27 13:38:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 13:38:37 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <0W9RhqZXr2NXr3Gel2gyRqf9F59HL87SAQ6-x2_pmUA=.3d9668e7-07f6-4400-9bf8-b0d7090daf1a@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
 <0W9RhqZXr2NXr3Gel2gyRqf9F59HL87SAQ6-x2_pmUA=.3d9668e7-07f6-4400-9bf8-b0d7090daf1a@github.com>
Message-ID: <xe-FZWB2eo9_zpa1a5ZmL-CFFbFBeS4A_Y6OCjLTb1s=.7694075b-5ff6-4795-bc9c-20060f8ad0ac@github.com>

On Fri, 27 Sep 2024 12:21:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 2424:
>> 
>>> 2422:         }
>>> 2423: 
>>> 2424:         @Override @DefinedBy(Api.LANGUAGE_MODEL)
>> 
>> Modelling-wise, I'm not sure. It almost seems as if `UnknownType` should be subclassed by `ErrorType` and not the other way around. Is there a specific reason you went for this?
>
> I would see the `UnknownType` as a specific kind of an erroneous type (and hence `UnknownType` being a subtype or erroneous, as it is here).
> 
> But, even from a practical point of view - `ErrorType` basically must extend `ClassType`, I think, so implanting `UnknownType` in there seems difficult.

I guess I'm a bit surprised by the typeKind - which is OTHER (you added the override to keep compatibility with what was there before). In that sense, it doesn't seem like `UnknownType` "is a" `ErrorType`, because its tag seems "less general" than the one in `ErrorType`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778644189

From mcimadamore at openjdk.org  Fri Sep 27 13:43:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 13:43:36 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <zCSI8kqxTXBv0rmr5qKVBxal-wf-bnq-6NCHUisxGr4=.11e40ff3-7d1e-4cd0-ba3e-a434a088e397@github.com>

On Fri, 13 Sep 2024 09:23:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 475:

> 473: 
> 474:         unknownSymbol = new ClassSymbol(PUBLIC|STATIC|ACYCLIC, names.fromString("<any?>"), null, rootPackage);
> 475:         // Create the unknown type

More general question: is the distinction between unknown and erroneous even relevant? It seems that an unknown type is just an erroneous type whose "class" happens to be the unknown symbol class. 

Can we just say:


        unknownSymbol = new ClassSymbol(PUBLIC|STATIC|ACYCLIC, names.fromString("<any?>"), null, rootPackage);
        unknownType = unknownSymbol.type = new ErrorType(unknownSymbol);


Is the only difference what the public `getTypeKind` will report? Do we care if there's a difference there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778652300

From jlahoda at openjdk.org  Fri Sep 27 13:56:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 27 Sep 2024 13:56:44 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <zCSI8kqxTXBv0rmr5qKVBxal-wf-bnq-6NCHUisxGr4=.11e40ff3-7d1e-4cd0-ba3e-a434a088e397@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <zCSI8kqxTXBv0rmr5qKVBxal-wf-bnq-6NCHUisxGr4=.11e40ff3-7d1e-4cd0-ba3e-a434a088e397@github.com>
Message-ID: <yRn7jH80bd6OC6Xp4MtAnccScqR1FbfdYfSMpdRWifs=.c2705fb1-158f-4ff6-b1c5-b50a4296134b@github.com>

On Fri, 27 Sep 2024 13:41:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Consider code like this:
>> 
>>     int nestedSwitchesInArgumentPosition(Object o1) {
>>         return id(switch (o1) {
>>             case R(var o2) -> switch (o2) {
>>                 case R(String s) -> s;
>>                 default -> "n";
>>             };
>>             default -> "";
>>         });
>>     }
>> 
>>     int id(String s) {
>>         return s.length();
>>     }
>> 
>>     int id(int i) {
>>         return i;
>>     }
>> 
>> 
>> Compiling this fails with a `StackOverflowError`, because:
>>  - there are speculative attribution happening for the switch expressions,
>>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
>> 
>> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
>> 
>> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
>> 
>> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
>> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
>> 
>> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
>> 
>> The intent is that the public API behavior for the `unknownType` should remain the same.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 475:
> 
>> 473: 
>> 474:         unknownSymbol = new ClassSymbol(PUBLIC|STATIC|ACYCLIC, names.fromString("<any?>"), null, rootPackage);
>> 475:         // Create the unknown type
> 
> More general question: is the distinction between unknown and erroneous even relevant? It seems that an unknown type is just an erroneous type whose "class" happens to be the unknown symbol class. 
> 
> Can we just say:
> 
> 
>         unknownSymbol = new ClassSymbol(PUBLIC|STATIC|ACYCLIC, names.fromString("<any?>"), null, rootPackage);
>         unknownType = unknownSymbol.type = new ErrorType(unknownSymbol);
> 
> 
> Is the only difference what the public `getTypeKind` will report? Do we care if there's a difference there?

Internally, after this patch, the distinction is minimal, and usually checked using `== unknownType`. Whether we can change the external behavior not sure. We can try.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20990#discussion_r1778669968

From mcimadamore at openjdk.org  Fri Sep 27 14:06:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 14:06:35 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <G9-u3-O4dlENjaKZQZocRiHPQYe0dCK7IRDvaJDOREA=.49b7a103-74a3-482b-8b64-4990a208c643@github.com>

On Fri, 13 Sep 2024 09:23:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20990#pullrequestreview-2333844506

From vromero at openjdk.org  Fri Sep 27 15:05:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 27 Sep 2024 15:05:42 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <5kW66NJeIr4Vd1Q6iAV0if5lXtZW9IaCrTOsPKkeQ8w=.75965288-6372-4799-8ec7-2314c3ebb85f@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
 <5kW66NJeIr4Vd1Q6iAV0if5lXtZW9IaCrTOsPKkeQ8w=.75965288-6372-4799-8ec7-2314c3ebb85f@github.com>
Message-ID: <c37XGcgu0CvT4-bHLudu8KkAgYkkrN1NVmy3BR3XSx8=.306d0f8b-e8c4-4afa-8cf8-df58f2a9eb63@github.com>

On Fri, 27 Sep 2024 12:27:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.

I agree with Maurizio that we are probably doing too much in speculative mode in the switch. I wonder if this patch should be part of the code that will refactor what we are doing there. I would expect any refactoring of what it is done in the switch code to affect this current PR

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

PR Comment: https://git.openjdk.org/jdk/pull/20990#issuecomment-2379484119

From vromero at openjdk.org  Fri Sep 27 16:07:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 27 Sep 2024 16:07:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v4]
In-Reply-To: <cTmCyLgDWCYD2qLh8WRVCTgOJrh_outWBI2oyeD6vrk=.f3f19aca-baee-4d68-bd74-33fdb6f5a2c8@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <cTmCyLgDWCYD2qLh8WRVCTgOJrh_outWBI2oyeD6vrk=.f3f19aca-baee-4d68-bd74-33fdb6f5a2c8@github.com>
Message-ID: <csiRIyv5-mn6jpVGaBJ1iqx4EZSL5C0LeI6ZXigmJ08=.06f181f9-ec20-46d8-9d38-dea9503d66e2@github.com>

On Fri, 13 Sep 2024 10:25:31 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

I think this change needs more test cases so that we can be sure that we are testing most of the possible combinations

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

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2334130381

From vromero at openjdk.org  Fri Sep 27 16:10:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 27 Sep 2024 16:10:36 GMT
Subject: RFR: 8340024: In ClassReader,
 extract a constant for the superclass supertype_index
In-Reply-To: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
References: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
Message-ID: <5cxv8tOnSv3bzQbclI_fPRDsBRCk_jPtTCEB6fslc-o=.2c7002de-a1b6-4bcc-a248-fe16ae8d0bb2@github.com>

On Thu, 12 Sep 2024 16:33:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi, please consider this cleanup to extract a literal to a documented constant in `ClassReader`, see [JDK-8340024](https://bugs.openjdk.org/browse/JDK-8340024).

looks good, thanks for doing this change

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20970#pullrequestreview-2334135858

From cushon at openjdk.org  Fri Sep 27 16:23:43 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 27 Sep 2024 16:23:43 GMT
Subject: Integrated: 8340024: In ClassReader,
 extract a constant for the superclass supertype_index
In-Reply-To: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
References: <iDLKHtZx2YiL-ttpyLE_QnfXgFZwao3zXExyxtSNsLY=.55e324e6-ffdb-44ec-af4c-7839225a6d6c@github.com>
Message-ID: <Fs6IN09z4jWg1SpHrxaSV3x8ScgCGSMgdHMzwvzyPog=.87d094cc-cada-43eb-85e1-6fa7f9be3523@github.com>

On Thu, 12 Sep 2024 16:33:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi, please consider this cleanup to extract a literal to a documented constant in `ClassReader`, see [JDK-8340024](https://bugs.openjdk.org/browse/JDK-8340024).

This pull request has now been integrated.

Changeset: 68c4f368
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68c4f36857a8ce62731cc73e251e969d48e526ef
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8340024: In ClassReader, extract a constant for the superclass supertype_index

Reviewed-by: vromero

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

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

From duke at openjdk.org  Fri Sep 27 16:32:46 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 27 Sep 2024 16:32:46 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I?wish?that the?concrete `PoolEntry`?subtypes had?`of(?)` factory?methods which?would create?instances using?the?`TemporaryConstantPool`, as?I?find?it?necessary to?create `PoolEntry`?instances in?contexts where?a?`ConstantPoolBuilder` is?not?easily?available (and?`ConstantPoolBuilder.of()` is?relatively?expensive when?creating a?one?off `PoolEntry`?instance) and?the?current `TemporaryConstantPool`?implementation doesn?t?support all?the?creation?methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2379656905

From darcy at openjdk.org  Fri Sep 27 17:21:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Sep 2024 17:21:15 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v3]
In-Reply-To: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
Message-ID: <tDQTQm_oy5fKpW2jOIJcOsxYj-Pzu3e-3G8MZbjHtxY=.75785635-5082-4956-bdb7-435dda892261@github.com>

> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

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/21193/files
  - new: https://git.openjdk.org/jdk/pull/21193/files/5d7309ba..0c1a3ecc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21193&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21193&range=01-02

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

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

From darcy at openjdk.org  Fri Sep 27 17:21:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Sep 2024 17:21:15 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v2]
In-Reply-To: <TYta0JPCgO-etnMPEUCclfqqUeIVGgbmKArVcucp514=.5ceb79e0-a612-47cb-8cf9-d6865db9d0d8@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
 <TYta0JPCgO-etnMPEUCclfqqUeIVGgbmKArVcucp514=.5ceb79e0-a612-47cb-8cf9-d6865db9d0d8@github.com>
Message-ID: <UCS5Hyr61DFOS0LyapYwwmfiT7q5VZF8GxGPspOPGbQ=.8f893ef5-f47d-48ca-83df-1b7701735d20@github.com>

On Fri, 27 Sep 2024 12:10:42 GMT, Maurizio Cimadamore <mcimadamore 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/util/Types.java line 280:
> 
>> 278:      *
>> 279:      * @throws IllegalArgumentException if bounds are not valid,
>> 280:      * including for types that are <em>not</em> {@linkplain ReferenceType
> 
> I find "including for types" hard to parse and connect to the previous clause. Did you mean "e.g. if if the bounds are not reference types" ?

Okay; I'll rephrase this to be more clear. Something like:

"throws IllegalArgumentException - if bounds are not valid. Invalid bounds include all types that are not reference types."

The intention of the phrasing is meant to imply there are reference type arguments that could be invalid, per any restrictions from the JLS. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1778927419

From prappo at openjdk.org  Fri Sep 27 19:15:36 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 27 Sep 2024 19:15:36 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v3]
In-Reply-To: <ZqKvJBjOaHMNvwT3BV4rpu7XIjMbm_7d9DifEwWtTsM=.6854d2ac-d83c-43bd-9097-0b6d98f96723@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <2YOj7tWgw5Q2GvC-e1CLk0nDBga6bo-FM-XS8ishF9Y=.6c1b71ac-2843-4239-ba0b-cb124b6f2a5c@github.com>
 <ZqKvJBjOaHMNvwT3BV4rpu7XIjMbm_7d9DifEwWtTsM=.6854d2ac-d83c-43bd-9097-0b6d98f96723@github.com>
Message-ID: <Vg2inG3_-_WZk42goQNkAze133PDQRs449rCeM2ek6M=.8d7abe38-0139-407a-a176-99ca1dba7484@github.com>

On Fri, 27 Sep 2024 08:58:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 164:
> 
>> 162:         // Reference types are ArrayType, DeclaredType, ErrorType, NullType, TypeVariable
>> 163:         // non-reference: ExecutableType, IntersectionType, NoType, PrimitiveType, UnionType, WildcardType
>> 164:         var invalidInputs = List.of( arrayType,
> 
> Do we need to change `getWildcardType`'s behaviour for `ArrayType` or specification? `ArrayType` is a reference type, and `getWildcardType` is now specified to throw IAE for all reference types.

Oops, disregard that previous comment. My bad, was sloppily reviewing this part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1779050260

From prappo at openjdk.org  Fri Sep 27 19:18:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 27 Sep 2024 19:18:38 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v3]
In-Reply-To: <tDQTQm_oy5fKpW2jOIJcOsxYj-Pzu3e-3G8MZbjHtxY=.75785635-5082-4956-bdb7-435dda892261@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <tDQTQm_oy5fKpW2jOIJcOsxYj-Pzu3e-3G8MZbjHtxY=.75785635-5082-4956-bdb7-435dda892261@github.com>
Message-ID: <E5_aZAWhFOBWuVyngKWYswIBdLvipKaJMNsUXYAINCY=.86f8c0d9-34a6-4bb5-821e-dea49850df8b@github.com>

On Fri, 27 Sep 2024 17:21:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Now looks good.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21193#pullrequestreview-2334474159

From darcy at openjdk.org  Fri Sep 27 20:43:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Sep 2024 20:43:36 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v3]
In-Reply-To: <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <cBPO9kgXrdwSsOyO2naOr2RV65bKQp3zRJ6DUqR8khk=.2e7fbab1-8bdb-41d5-a218-3286ec54aff1@github.com>
Message-ID: <yJTVIp_SIZRat0SNx0mieTqdl_5IWpJKplWu6D-8bMg=.e31a96ad-2986-44c1-a204-1c24d8845c23@github.com>

On Thu, 26 Sep 2024 10:35:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java line 51:
> 
>> 49:     private ArrayType        arrayType;
>> 50:     private DeclaredType     declaredType;
>> 51:     // private ErrorType        errorType; // skip for now
> 
> Any plans on how to test `ErrorType` in the future?

I think doing that reliably could take a bit of extra effort and need to step outside of the one-file-for-a-test methodology. For example, have an "Erroneous.java" test that was only compiled during the annotation processioning phase and not when the annotation processor itself is built.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21193#discussion_r1779133306

From mcimadamore at openjdk.org  Fri Sep 27 21:45:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Sep 2024 21:45:42 GMT
Subject: RFR: 8340721: Clarify special case handling of unboxedType and
 getWildcardType [v3]
In-Reply-To: <tDQTQm_oy5fKpW2jOIJcOsxYj-Pzu3e-3G8MZbjHtxY=.75785635-5082-4956-bdb7-435dda892261@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
 <tDQTQm_oy5fKpW2jOIJcOsxYj-Pzu3e-3G8MZbjHtxY=.75785635-5082-4956-bdb7-435dda892261@github.com>
Message-ID: <9DO85bTylcXVdfHlVgr8DPcxVg7xjaoZf-zazOXgKBI=.6ea9bf61-689e-45f3-8523-952088de09ae@github.com>

On Fri, 27 Sep 2024 17:21:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21193#pullrequestreview-2334686295

From darcy at openjdk.org  Fri Sep 27 23:36:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Sep 2024 23:36:54 GMT
Subject: Integrated: 8340721: Clarify special case handling of unboxedType and
 getWildcardType
In-Reply-To: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
References: <sd5mlqlOzeDdZrMt5Qt0tM9kGed09StLZpg0T18pXLY=.7352e937-5f79-4bcc-b261-5f00beebd9a2@github.com>
Message-ID: <uAN_9kDq7RDEUGv1AjrtjBwplttRiffTnYNQyAfNkb0=.c5b2def2-e2c5-4417-b899-6232c541599c@github.com>

On Wed, 25 Sep 2024 22:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First piece of a larger set of updates that may be made for JDK-8055219 to clarify the exceptional behavior of `javax.lang.model.util.Types`.

This pull request has now been integrated.

Changeset: 73ebb848
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73ebb848fdb66861e912ea747c039ddd1f7a5f48
Stats:     196 lines in 2 files changed: 194 ins; 0 del; 2 mod

8340721: Clarify special case handling of unboxedType and getWildcardType

Reviewed-by: prappo, mcimadamore

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

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

From jpai at openjdk.org  Sat Sep 28 13:55:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 13:55:45 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
Message-ID: <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>

On Fri, 27 Sep 2024 01:41:17 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:
>> 
>>> 314: main.help.opt.extract.keep-old-files=\
>>> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
>>> 316: \                             In particular, if a file appears more than once in an\n\
>> 
>> In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.
>> 
>> Here is the verbiage from tar to give you a start
>> 
>> ` -x      Extract to disk from the archive.  If a file with the same name appears more than
>>              once in the archive, each copy will be extracted, with later copies overwriting
>>              (replacing) earlier copies.  The long option form is --extract.`
>
> Updated.

Hello Henry, I think this `-k` option help text would need a slight modification. Right now it states that if a file appears more than once in an archive, then this setting this flag will not overwrite the earlier copies. In reality, it doesn't matter how many times the file appears in the archive - even if it appears just once, and if the file is being extracted into a directory which already has the same named file at that path, then this `-k` flag will not overwrite that existing file.

So I think we should reword it to talk about its behaviour in context of some file already existing in the destination directory where the jar contents are being extracted. 

I wonder if we should make a mention that we don't do any case sensitive checks for the existence of the file in the destination directory and instead we use filesystem API to check for existence (which depending on the filesystem may be case insensitive, like macosx).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779492170

From jpai at openjdk.org  Sat Sep 28 14:11:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:11:34 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <6OAyg7t0GLznmc8NQaepLkn-Jz4j83YVYJVLNEeIKb0=.eff09bc1-c232-4045-9c46-d8d7144665ac@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 168:

> 166: 
> 167:     private Stream<Path> mkpath(String... args) {
> 168:         return Arrays.stream(args).map(d -> Paths.get(".", d.split("/")));

For newer code usages, like this one, it's recommended to use `Path.of(...)` instead of `Paths.get(...)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779494948

From jpai at openjdk.org  Sat Sep 28 14:14:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:14:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <Mqr5-E4_z-rRUQ8adRmq7xz7VEQdRxpcR4FoN99b24s=.62f49497-844b-41c5-b7fd-b01133a3d1d3@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 207:

> 205:         try {
> 206:             var p = Paths.get(".", path.split("/"));
> 207:             return String.join(nl, Files.readAllLines(p));

Do you think this could be simplified to `return Files.readString(p)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779496134

From jpai at openjdk.org  Sat Sep 28 14:35:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:35:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 236:

> 234:         PrintStream err = new PrintStream(baes);
> 235:         PrintStream saveErr = System.err;
> 236:         System.setErr(err);

Given that we are updating the runtime level state, I think we should use `/othervm` in this test's definition to avoid any interference with other parts of the runtime.

test/jdk/tools/jar/ExtractFilesTest.java line 238:

> 236:         System.setErr(err);
> 237:         int rc = JAR_TOOL.run(out, err, cmdline.split(" +"));
> 238:         System.setErr(saveErr);

Doing a

try {
int rc = JAR_TOOL.run(out, err, cmdline.split(" +"));
}finally {
System.setErr(saveErr);
}

would be safer.

test/jdk/tools/jar/ExtractFilesTest.java line 241:

> 239:         if (rc != 0) {
> 240:             String s = baes.toString();
> 241:             if (s.startsWith("java.util.zip.ZipException: duplicate entry: ")) {

This method runs any arbitrary `jar` "command". Is there any significance why we are checking for a "duplicate entry" in the exception message? Maybe we could just remove this entire if block and just throw a `new IOException(s)`? As far as I can see in this test, we don't do any exception type checks on the thrown exception from this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779499876
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779500135
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779501074

From jpai at openjdk.org  Sat Sep 28 14:39:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:39:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <chgru-eK0dp3Ry1ReWcafs638yzkBtuyPK3MmjTeSBI=.f5e457a2-0a1b-4e87-98a0-03a3d276367b@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/MultipleManifestTest.java line 67:

> 65: 
> 66: @TestInstance(Lifecycle.PER_CLASS)
> 67: @TestMethodOrder(MethodName.class)

Is the use of these annotations intentional? Especially the method ordering?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779501649

From duke at openjdk.org  Sat Sep 28 15:27:50 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 28 Sep 2024 15:27:50 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v5]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <G-8zz2PGFc58xtP_ah0EX4VNAeq-XRYRK-5eLtbTA38=.4867e55b-b334-4858-b5b6-af03bd2c9b27@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  more test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/b7a5c47e..f0021f43

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

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

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

From duke at openjdk.org  Sat Sep 28 17:48:04 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 28 Sep 2024 17:48:04 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v6]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <FS8XFo5YkJIpG63yv8Qj7q1a59rT6LaDA6cZQFwlgvs=.86bc1318-8502-4db8-87a6-df07a6d3f19b@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  fix testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/f0021f43..b879275e

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

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

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

From duke at openjdk.org  Sat Sep 28 22:31:14 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 28 Sep 2024 22:31:14 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  remove trailing line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/b879275e..3d6d5749

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

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

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

From duke at openjdk.org  Sun Sep 29 08:38:36 2024
From: duke at openjdk.org (Evemose)
Date: Sun, 29 Sep 2024 08:38:36 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v4]
In-Reply-To: <csiRIyv5-mn6jpVGaBJ1iqx4EZSL5C0LeI6ZXigmJ08=.06f181f9-ec20-46d8-9d38-dea9503d66e2@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <cTmCyLgDWCYD2qLh8WRVCTgOJrh_outWBI2oyeD6vrk=.f3f19aca-baee-4d68-bd74-33fdb6f5a2c8@github.com>
 <csiRIyv5-mn6jpVGaBJ1iqx4EZSL5C0LeI6ZXigmJ08=.06f181f9-ec20-46d8-9d38-dea9503d66e2@github.com>
Message-ID: <5PfwZlIwqKNsGVEWdZb85wO64nIyZ5pjHLBXL5xVhkw=.1de0ca1c-642c-4acb-a540-5c8bb82dda0c@github.com>

On Fri, 27 Sep 2024 16:04:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think this change needs more test cases so that we can be sure that we are testing most of the possible combinations

I have tried to imagine some test cases where something could go wrong. Not really sure how to verify everything concidering the fact that permits is the last clause before attributing class code, which is allowed to access any private members, but I added some test cases veryfying everything from a different angles

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2381263576

From asotona at openjdk.org  Mon Sep 30 09:27:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 09:27:39 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
 <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>
Message-ID: <QPdSqODYrQQQUNjsPKuxoOmi8z9J1mFyvXlSQ5pbbZk=.c0eabecf-25d7-4e56-974f-47e7aa34b3bf@github.com>

On Fri, 27 Sep 2024 16:29:30 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?wish?that the?concrete `PoolEntry`?subtypes had?`of(?)` factory?methods...

Please forward the proposal on clasfile-api-dev mailing list, where it can be discussed. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2382597723

From lancea at openjdk.org  Mon Sep 30 11:26:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 11:26:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 587:

> 585:                             break;
> 586:                         case 'k':
> 587:                             kflag = true;

I am wondering if a warning should be displayed if this options is specified with any option other than 'x'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1780928849

From lancea at openjdk.org  Mon Sep 30 11:40:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 11:40:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
Message-ID: <DyVLK1xTDwn9QJ3yWozmK0pGrSgQCr15FSM3zZdKDC4=.77bec2de-aa4d-48ad-bfb2-202d63876d2d@github.com>

On Fri, 27 Sep 2024 01:42:26 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:
>> 
>>> 167:         extracted: {0}
>>> 168: out.kept=\
>>> 169:         \ \ skipped: {0}
>> 
>> We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk
>
> I follow existing pattern with short status update. Open to suggestions.

Perhaps something like:

` \ \  file: {0}  exists, skipped`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1780957293

From jlahoda at openjdk.org  Mon Sep 30 11:46:04 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 30 Sep 2024 11:46:04 GMT
Subject: RFR: 8341070: javac fails with an exception when compiling import
 module under source level 8
Message-ID: <HhFPc6CZ0T3UYP0G524s1J41pNAvcAsc1lYpaod2IJ8=.dc80a438-120f-4fbb-9aaa-3187181e5db6@github.com>

Consider code like:

package test;

import module java.base;

public class Test {
    List<String> l;
}


Compiling this may cause javac to fail with an exception under some circumstances:

$ javac --source 8 -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
warning: [options] bootstrap class path is not set in conjunction with -source 8
  not setting the bootstrap class path may lead to class files that cannot run on JDK 8
    --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically
warning: [options] source value 8 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
/tmp/Test.java:3: error: module imports are a preview feature and are disabled by default.
import module java.base;
       ^
  (use --enable-preview to enable module imports)
1 error
3 warnings
An exception has occurred in the compiler (23-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot invoke "java.util.Set.contains(Object)" because "this.env.toplevel.modle.readModules" is null
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doModuleImport(TypeEnter.java:477)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:414)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.runPhase(TypeEnter.java:318)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:279)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:248)
        at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.complete(TypeEnter.java:195)
        at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:687)
        at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1455)
        at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:632)
        at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:599)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
printing javac parameters to: /tmp/javac.20240927_093418.args


The reason is that while there are no modules under `--source 8`, the javac's `Symtab` still has a partial `java.base` module as a consequence of the initialization order. This partial modules is then found while evaluating `import module java.base;`, and leads to the subsequent crash.

The proposal herein is to reorganize the `Symtab` initialization a little, to ensure there's no partial `java.base` module.

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

Commit messages:
 - Simplifying test.
 - Preventing a NPE when --source 8 + -XDshould-stop.at=FLOW is used in combination with import module java.base;

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

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

From nbenalla at openjdk.org  Mon Sep 30 11:50:43 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 30 Sep 2024 11:50:43 GMT
Subject: RFR: 8341201: Broken link in AbstractAnnotationValueVisitor7 due to
 extra quotation mark
Message-ID: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>

Can I get a review for this trivial doc fix?

TIA

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

Commit messages:
 - remote quote

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

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

From iris at openjdk.org  Mon Sep 30 14:38:35 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 30 Sep 2024 14:38:35 GMT
Subject: RFR: 8341201: Broken link in AbstractAnnotationValueVisitor7 due
 to extra quotation mark
In-Reply-To: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
References: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
Message-ID: <yfYvJmqUh-BUqBhNYz_CFTbVvei2HhZonem6o-rDSJs=.a5370fba-cb3d-4bc3-aed2-ca696965b074@github.com>

On Mon, 30 Sep 2024 11:43:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this trivial doc fix?
> 
> TIA

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21263#pullrequestreview-2337773676

From henryjen at openjdk.org  Mon Sep 30 15:11:39 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:11:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
Message-ID: <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>

On Mon, 30 Sep 2024 11:23:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 587:
> 
>> 585:                             break;
>> 586:                         case 'k':
>> 587:                             kflag = true;
> 
> I am wondering if a warning should be displayed if this options is specified with any option other than 'x'

I considered that, but didn't implement it after confirmed other similar options didn't display any warning.
I do think it make sense to show a warning when using an option not valid in specific mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781320078

From henryjen at openjdk.org  Mon Sep 30 15:24:37 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:24:37 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
Message-ID: <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>

On Sat, 28 Sep 2024 14:32:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks
>
> test/jdk/tools/jar/ExtractFilesTest.java line 241:
> 
>> 239:         if (rc != 0) {
>> 240:             String s = baes.toString();
>> 241:             if (s.startsWith("java.util.zip.ZipException: duplicate entry: ")) {
> 
> This method runs any arbitrary `jar` "command". Is there any significance why we are checking for a "duplicate entry" in the exception message? Maybe we could just remove this entire if block and just throw a `new IOException(s)`? As far as I can see in this test, we don't do any exception type checks on the thrown exception from this method.

I copied the method from another test that do the create jar, so it does that. Some other comments also related to copied code, I can do a round of clean up.

> test/jdk/tools/jar/MultipleManifestTest.java line 67:
> 
>> 65: 
>> 66: @TestInstance(Lifecycle.PER_CLASS)
>> 67: @TestMethodOrder(MethodName.class)
> 
> Is the use of these annotations intentional? Especially the method ordering?

I had some test failure earlier so I added those to ensure not the race condition or left over even though I don't think that's the case.
I later figured out the real cause, so I think I can remove those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781337548
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781333864

From henryjen at openjdk.org  Mon Sep 30 15:28:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:28:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
 <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>
Message-ID: <PHcgSgtgxfAHpFOS16ibX_Z_8jcLDscDDfiM1GVnrlI=.ce3fa939-852e-40ce-87c4-2fe425660710@github.com>

On Sat, 28 Sep 2024 13:53:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Updated.
>
> Hello Henry, I think this `-k` option help text would need a slight modification. Right now it states that if a file appears more than once in an archive, then this setting this flag will not overwrite the earlier copies. In reality, it doesn't matter how many times the file appears in the archive - even if it appears just once, and if the file is being extracted into a directory which already has the same named file at that path, then this `-k` flag will not overwrite that existing file.
> 
> So I think we should reword it to talk about its behaviour in context of some file already existing in the destination directory where the jar contents are being extracted. 
> 
> I wonder if we should make a mention that we don't do any case sensitive checks for the existence of the file in the destination directory and instead we use filesystem API to check for existence (which depending on the filesystem may be case insensitive, like macosx).

You have valid point. I refer to the tar man page, and I thought do not overwrite existing files says it. The in particular is just to call out a specific use case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781344445

From lancea at openjdk.org  Mon Sep 30 15:54:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 15:54:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
 <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
Message-ID: <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>

On Mon, 30 Sep 2024 15:09:21 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> I considered that, but didn't implement it after confirmed other similar options didn't display any warning. I do think it make sense to show a warning when using an option not valid in specific mode.

We do display a warning/error is some cases:  For example when we specify 'c' and 'x' we get the following message


jar cxvf foo.jar
You may not specify more than one '-cuxtid' options
Try `jar --help' for more information.


given '-k' is only relevant when used with the  '-x' option, we could specify a warning (or indicate it is ignored...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781381620

From darcy at openjdk.org  Mon Sep 30 16:23:44 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 16:23:44 GMT
Subject: RFR: 8341201: Broken link in AbstractAnnotationValueVisitor7 due
 to extra quotation mark
In-Reply-To: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
References: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
Message-ID: <veS3VBk9TlLtKUmK3zJ5eTN68jfrXNgFvtO-rA4Itrs=.9bb82509-7879-4f62-b837-77bfe8740f60@github.com>

On Mon, 30 Sep 2024 11:43:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this trivial doc fix?
> 
> TIA

Marked as reviewed by darcy (Reviewer).

The change looks fine in and of itself. Why wasn't the bad link detected by the existing doclint and similar changes?

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

PR Review: https://git.openjdk.org/jdk/pull/21263#pullrequestreview-2338040885
PR Comment: https://git.openjdk.org/jdk/pull/21263#issuecomment-2383647262

From jjg at openjdk.org  Mon Sep 30 17:00:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 30 Sep 2024 17:00:38 GMT
Subject: RFR: 8341201: Broken link in AbstractAnnotationValueVisitor7 due
 to extra quotation mark
In-Reply-To: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
References: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
Message-ID: <ph64rN1HemEkOqF0zywQwwzlWZmcbF1SMOR4c7IX-VU=.c382700f-0505-479f-9f5a-23fab358503e@github.com>

On Mon, 30 Sep 2024 11:43:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this trivial doc fix?
> 
> TIA

Currently, we do not check the target of `##` links at the time they are handled. That's a medium big complicated thing to do, given that possible sources of ids in the target file.

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

PR Review: https://git.openjdk.org/jdk/pull/21263#pullrequestreview-2338113109

From jlahoda at openjdk.org  Mon Sep 30 17:08:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 30 Sep 2024 17:08:38 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <c37XGcgu0CvT4-bHLudu8KkAgYkkrN1NVmy3BR3XSx8=.306d0f8b-e8c4-4afa-8cf8-df58f2a9eb63@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
 <5kW66NJeIr4Vd1Q6iAV0if5lXtZW9IaCrTOsPKkeQ8w=.75965288-6372-4799-8ec7-2314c3ebb85f@github.com>
 <c37XGcgu0CvT4-bHLudu8KkAgYkkrN1NVmy3BR3XSx8=.306d0f8b-e8c4-4afa-8cf8-df58f2a9eb63@github.com>
Message-ID: <JXYAhWfouL2Pk0jYmha3ELU5ubUVxyd_BdG1cIiUj7o=.da6877b9-1964-4967-aadd-b25592cfce52@github.com>

On Fri, 27 Sep 2024 15:02:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.
> 
> I agree with Maurizio that we are probably doing too much in speculative mode in the switch. I wonder if this patch should be part of the code that will refactor what we are doing there. I would expect any refactoring of what it is done in the switch code to affect this current PR

That depends on what the merit of this PR is. There's a type that is inherently unsafe in javac (`Symtab.unknownType`) and leads to problems like `StackOverflowError` when sent to various methods on `Types`. This PR considers the specific problem with pattern matching switch just as a symptom of the problem with the type, and fixes the problem with the type. The intent in this PR is that any change to what is done during speculative attribution of pattern matching switches shouldn't affect it much.

Note that even though we don't know about any usecase right now where the problem would happen outside of speculative attribution, as long as `Attr.PostAttrAnalyzer` will set the `unknownType` to AST nodes, there's always a potential it will break unless the `unknownType` is fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20990#issuecomment-2383732455

From vromero at openjdk.org  Mon Sep 30 17:17:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Sep 2024 17:17:35 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <lsad-owhGZhQHPOnSCNhk-arYhnn9-eeo7Zv_rE02hA=.30c9fc21-fa11-4960-bb15-74ec223c9da4@github.com>

On Fri, 13 Sep 2024 09:23:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20990#pullrequestreview-2338170912

From vromero at openjdk.org  Mon Sep 30 17:17:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Sep 2024 17:17:36 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <JXYAhWfouL2Pk0jYmha3ELU5ubUVxyd_BdG1cIiUj7o=.da6877b9-1964-4967-aadd-b25592cfce52@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <iLyL2NNQnuPWnT8Eht8ZCHlXWAQ5eDI-8Fx5WANLKW4=.bc38c92a-2d7b-462e-a28d-26931f9fde73@github.com>
 <5kW66NJeIr4Vd1Q6iAV0if5lXtZW9IaCrTOsPKkeQ8w=.75965288-6372-4799-8ec7-2314c3ebb85f@github.com>
 <c37XGcgu0CvT4-bHLudu8KkAgYkkrN1NVmy3BR3XSx8=.306d0f8b-e8c4-4afa-8cf8-df58f2a9eb63@github.com>
 <JXYAhWfouL2Pk0jYmha3ELU5ubUVxyd_BdG1cIiUj7o=.da6877b9-1964-4967-aadd-b25592cfce52@github.com>
Message-ID: <OWWKIZfkBjYsrQKclJi58UqjiU96avOcjQPUt5DO6t0=.95b62e50-3d47-4563-9072-02fd917e25f6@github.com>

On Mon, 30 Sep 2024 17:05:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > > The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.
> > 
> > 
> > I agree with Maurizio that we are probably doing too much in speculative mode in the switch. I wonder if this patch should be part of the code that will refactor what we are doing there. I would expect any refactoring of what it is done in the switch code to affect this current PR
> 
> That depends on what the merit of this PR is. There's a type that is inherently unsafe in javac (`Symtab.unknownType`) and leads to problems like `StackOverflowError` when sent to various methods on `Types`. This PR considers the specific problem with pattern matching switch just as a symptom of the problem with the type, and fixes the problem with the type. The intent in this PR is that any change to what is done during speculative attribution of pattern matching switches shouldn't affect it much.
> 
> Note that even though we don't know about any usecase right now where the problem would happen outside of speculative attribution, as long as `Attr.PostAttrAnalyzer` will set the `unknownType` to AST nodes, there's always a potential it will break unless the `unknownType` is fixed.

yep that makes sense to me we can revisit this issue later on if needed

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

PR Comment: https://git.openjdk.org/jdk/pull/20990#issuecomment-2383748651