From acobbs at openjdk.org  Tue Jul  1 16:03:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 1 Jul 2025 16:03:33 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

 - Merge branch 'master' into MandatoryWarningCleanup
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - Apply some review suggestions.
 - Refactor MandatoryWarningHandler to just be an aggregator.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25810/files
  - new: https://git.openjdk.org/jdk/pull/25810/files/95b368fb..94cda824

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

  Stats: 37873 lines in 1141 files changed: 20469 ins; 11683 del; 5721 mod
  Patch: https://git.openjdk.org/jdk/pull/25810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25810/head:pull/25810

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

From vromero at openjdk.org  Wed Jul  2 18:06:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 18:06:24 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as an
 abstract class
Message-ID: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>

Javac is failing to compile this code:

abstract class Base<T> {}
abstract class Derived1<T> extends Base<T> {}
abstract class Derived2<T> extends Base<T> {
    Derived2(Derived1<T> obj) {}
}

class Test {
    Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
}

issuing error message:

Test.java:8: error: Derived1 is abstract; cannot be instantiated
    Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };

basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,

TIA

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

Commit messages:
 - adding test case
 - minor change to test
 - Merge branch 'master' into JDK-8361214
 - 8361214: An anonymous class is erroneously being classify as an abstract class

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

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

From jlu at openjdk.org  Wed Jul  2 21:11:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Jul 2025 21:11:49 GMT
Subject: RFR: 8361303: L10n comment for javac.opt.Xlint.desc.synchronization in
 javac.properties
Message-ID: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>

Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Wed Jul  2 21:41:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 21:41:14 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when running in
 repeat
Message-ID: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>

The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.

This problem is evident when running from intellij idea. It can also be reproduced consistently by:

make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2


Testing: that make test line above now passes.

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

Commit messages:
 - 8360022: ClassRefDupInConstantPoolTest.java fails when running in repeat

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

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

From vromero at openjdk.org  Wed Jul  2 21:51:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 21:51:42 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <TY8nUaNU979lDpzMV_uV65hfDiAHJ54CcmPOa2rjL50=.07f473f8-fa7e-499e-8612-29ef17473051@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

looks good, please consider placing the `@clean` directive after the `@run` one

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26106#pullrequestreview-2980733808

From naoto at openjdk.org  Wed Jul  2 22:12:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Jul 2025 22:12:40 GMT
Subject: RFR: 8361303: L10n comment for
 javac.opt.Xlint.desc.synchronization in javac.properties
In-Reply-To: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
References: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
Message-ID: <4tCuq_CiVXYNLgj3X_KDQwhSqn7PgnS9lFZ9GJRYftw=.e04528d0-6622-4147-a2ab-3acbd4ea6968@github.com>

On Wed, 2 Jul 2025 21:07:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26105#pullrequestreview-2980777591

From liach at openjdk.org  Wed Jul  2 22:29:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 22:29:41 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <Yy_x-V-kmI42vluYHLMWzXzPO0pVV3s55mbIXwh5zvI=.4603b1f7-1f55-4f20-ae91-f75851f1ea16@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

The placement of clean and run doesn't matter here - for both fails and successes. Per my understanding, they usually are only important when there are multiple run directives in one jtreg header.

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

PR Comment: https://git.openjdk.org/jdk/pull/26106#issuecomment-3029489025

From liach at openjdk.org  Wed Jul  2 23:08:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:08:38 GMT
Subject: RFR: 8361303: L10n comment for
 javac.opt.Xlint.desc.synchronization in javac.properties
In-Reply-To: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
References: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
Message-ID: <SiC2qzNLTSnV1bcAXKVmQUA83ma1Sih3XD-GmAnaxss=.2c003346-c32f-4b70-82f2-1dda8f55ffe7@github.com>

On Wed, 2 Jul 2025 21:07:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

Indeed, this is a javac command line flag instead of a word to be translated.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26105#pullrequestreview-2980875250

From liach at openjdk.org  Wed Jul  2 23:12:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:12:20 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally matching
 primitive patterns
Message-ID: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>

A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.

Testing: langtools/tools/javac

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

Commit messages:
 - Fix
 - Fixup
 - 8357185: Redundant local variables with unconditionally matching primitive patterns

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

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

From liach at openjdk.org  Wed Jul  2 23:18:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:18:37 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as
 an abstract class
In-Reply-To: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
References: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
Message-ID: <JXh9UfQQXPTRMpiHCuXYchLbD6o03FuGhHXmvgJh_rs=.3880075e-ca4f-46f5-9318-8edff94b8e45@github.com>

On Wed, 2 Jul 2025 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is failing to compile this code:
> 
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>     Derived2(Derived1<T> obj) {}
> }
> 
> class Test {
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> }
> 
> issuing error message:
> 
> Test.java:8: error: Derived1 is abstract; cannot be instantiated
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> 
> basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,
> 
> TIA

Looks reasonable.

I see there are two sites of `cdef != null && clazztype.tsym.isInterface()`; do they need to check this too?

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26103#pullrequestreview-2980889360

From jlahoda at openjdk.org  Thu Jul  3 07:20:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Jul 2025 07:20:49 GMT
Subject: Integrated: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
Message-ID: <uK_NIODWlF0Hk5YY2rsAdVVMqqrC37wT2xNJWWraMnQ=.c68b74af-2e2f-494a-9ac5-ff9436e3e423@github.com>

On Tue, 17 Jun 2025 10:01:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> 
> public class Main {
> 
>     private boolean test(String s, int i) {
>         if (s.subSequence(0, 1) instanceof Runnable r) {
>             return true;
>         }
> 
>         Integer dummy;
>         switch (i) {
>             case 0:
>                 String clashing = null;
>                 return true;
>             default:
>                 return true;
>         }
>     }
> 
>     public static void main(String[] args) {
>     }
> }
> 
> 
> javac will produce code that won't (rightfully) pass the verifier:
> 
> 
> $ java Main.java
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
> Exception Details:
>   Location:
>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>   Reason:
>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>   Current Frame:
>     bci: @25
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer }
>     stack: { integer }
>   Stackmap Frame:
>     bci: @49
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>     stack: { }
>   Bytecode:
>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>     0000030: ac04 ac
>   Stackmap Table:
>     same_frame(@24)
>     same_frame(@44)
>     append_frame(@49,Top,Object[#8])
> 
>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> 
> 
> 
> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
> 
> 
> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>     return true;
> }
> 
> 
> (`$temp` is register/local variable number 4)
> specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is...

This pull request has now been integrated.

Changeset: fd13e1ce
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd13e1ce9805a903ab60ad9b476eb5a6687d22ee
Stats:     144 lines in 2 files changed: 144 ins; 0 del; 0 mod

8358801: javac produces class that does not pass verifier.

Reviewed-by: mcimadamore, liach

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

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

From jlahoda at openjdk.org  Thu Jul  3 09:17:38 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Jul 2025 09:17:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>

On Wed, 2 Jul 2025 23:06:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

This seems like a reasonable direction, but please see inline for suggestions for improvements.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:

> 2844: 
> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable

While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 88:

> 86:     public void testExpressionExecution() {
> 87:         int a = 0;
> 88:         boolean b = (a = 5) instanceof int;

I would suggest to also include the same test cases with binding patterns instead of types. In the current state/code shape, there should be no difference, but it would be better to not be caught later if the code shape changes.

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

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2982391708
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182280878
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182284238

From abimpoudis at openjdk.org  Thu Jul  3 09:27:41 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 09:27:41 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
Message-ID: <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>

On Thu, 3 Jul 2025 09:13:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
> 
>> 2844: 
>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
> 
> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

On the flipside, in the tests we already have this:


    public static int meth() {return 42;}
    public static boolean exprMethod() {
        return meth() instanceof int ii;
    }


However this is not sufficient. Can we also add one that actually has side effects and a null check as well and confirm that i is incremented once?


    static int i = 0;
    public static Integer meth_sideEffect() {  i++; return 42;}
    public static boolean exprMethod2() {
        return meth_sideEffect() instanceof int ii;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182305255

From mcimadamore at openjdk.org  Thu Jul  3 10:08:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 10:08:45 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
Message-ID: <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>

On Tue, 1 Jul 2025 16:03:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into MandatoryWarningCleanup
>  - Move (most) SOURCE_LEVEL flags into compiler.properties.
>  - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
>  - Apply some review suggestions.
>  - Refactor MandatoryWarningHandler to just be an aggregator.

make/langtools/tools/propertiesparser/resources/templates.properties line 93:

> 91: diagnostic.flags=\n\
> 92:   '  'Stream.of({0})\n\
> 93:   '    '.map(s -> s.replace(''-'', ''_''))\n\

These transformations could be also done in Java code inside `ClassGenerator` right?

make/langtools/tools/propertiesparser/resources/templates.properties line 96:

> 94:   '    '.map(s -> s.toUpperCase(Locale.ROOT))\n\
> 95:   '    '.map(DiagnosticFlag::valueOf)\n\
> 96:   '    '.toArray(DiagnosticFlag[]::new)

If instead of an array we returned a list, or a set, maybe we could use empty list/set if there's no flag (instead of `null` as we do now?)

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 512:

> 510:         DiagnosticType type;
> 511: 
> 512:         /** A set of diagnostic flags to be automatically added to newly created JCDiagnostics (if not null). */

As commented elsewhere -- should we use `null` or something like an empty list/set?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 585:

> 583: 
> 584:         public boolean hasFlag(DiagnosticFlag flag) {
> 585:             return flags != null && Arrays.asList(flags).contains(flag);

This is where it seems that encoding as a possibly null array has a cost

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 685:

> 683:         if (diagnosticInfo.flags != null) {
> 684:             for (DiagnosticFlag flag : diagnosticInfo.flags) {
> 685:                 this.flags.add(flag);

This could be `addAll` (if flags were not arrays)

src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningAggregator.java line 131:

> 129:      *                that may be generated, or null to infer from the lint category.
> 130:      */
> 131:     public MandatoryWarningAggregator(Log log, Source source, LintCategory lc, String prefix) {

I think we should call it just `WarningAggregator`. While for now the cases where we aggregate are mandatory warnings, it is not clear to me that we want to give this coupling much importance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182380617
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182382167
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182385914
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182387337
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182388765
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182392534

From mcimadamore at openjdk.org  Thu Jul  3 10:17:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 10:17:42 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
Message-ID: <dEBVBLrTs-GRo3b_Td0Qyv74qNgB-HNB9jBAMA63Fic=.2337869d-7a69-4a33-a1cd-d003016a7ff0@github.com>

On Tue, 1 Jul 2025 16:03:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into MandatoryWarningCleanup
>  - Move (most) SOURCE_LEVEL flags into compiler.properties.
>  - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
>  - Apply some review suggestions.
>  - Refactor MandatoryWarningHandler to just be an aggregator.

I like capturing flags in the diagnostic key -- it seems to go in the direction of trying to make the diagnostic subsystem more robust and "statically self-described" -- a direction we've kept pushing for quite some time now. I have some (minor) quibbles re. use of nulls.

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

PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2982595048

From liach at openjdk.org  Thu Jul  3 13:45:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 13:45:02 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v6]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <CR9SL_8QfaRIkg4yyD2zsBzyLyJCHevsJJQkLmyGyOM=.e060bbf3-9ddf-4934-bcb4-61fa7572291f@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=05
  Stats: 1265 lines in 6 files changed: 1123 ins; 83 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From liach at openjdk.org  Thu Jul  3 14:45:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 14:45:50 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
 <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
Message-ID: <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>

On Thu, 3 Jul 2025 09:24:33 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
>> 
>>> 2844: 
>>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
>> 
>> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.
>
> On the flipside, in the tests we already have this (in `PrimitiveInstanceOfPatternOpWithTopLevelPatterns` but also as a type comparison op in `PrimitiveInstanceOfTypeComparisonOp`):
> 
> 
>     public static int meth() {return 42;}
>     public static boolean exprMethod() {
>         return meth() instanceof int ii;
>     }
> 
> 
> However this is not sufficient. Can we also add one (one in each file) that actually has side effects and a null check as well and confirm that i is incremented once?
> 
> 
>     static int i = 0;
>     public static Integer meth_sideEffect() {  i++; return 42;}
>     public static boolean exprMethod2() {
>         return meth_sideEffect() instanceof int ii;
>     }

Do I just paste this block into both tests and call them in main?

    static int sideEffect;
    public static Integer methSideEffect() { sideEffect++; return 42;}
    public static boolean exprMethodSideEffect() {
        sideEffect = 5;
        return methSideEffect() instanceof int ii && sideEffect == 6;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182970222

From abimpoudis at openjdk.org  Thu Jul  3 14:45:50 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 14:45:50 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
 <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
 <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>
Message-ID: <6iLjpA5m0_wMfBLilFB131aX53XipiLXO9BkUA1j-GQ=.cf0b3879-3f55-4641-8cd6-2ba23fed4649@github.com>

On Thu, 3 Jul 2025 14:41:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> On the flipside, in the tests we already have this (in `PrimitiveInstanceOfPatternOpWithTopLevelPatterns` but also as a type comparison op in `PrimitiveInstanceOfTypeComparisonOp`):
>> 
>> 
>>     public static int meth() {return 42;}
>>     public static boolean exprMethod() {
>>         return meth() instanceof int ii;
>>     }
>> 
>> 
>> However this is not sufficient. Can we also add one (one in each file) that actually has side effects and a null check as well and confirm that i is incremented once?
>> 
>> 
>>     static int i = 0;
>>     public static Integer meth_sideEffect() {  i++; return 42;}
>>     public static boolean exprMethod2() {
>>         return meth_sideEffect() instanceof int ii;
>>     }
>
> Do I just paste this block into both tests and call them in main?
> 
>     static int sideEffect;
>     public static Integer methSideEffect() { sideEffect++; return 42;}
>     public static boolean exprMethodSideEffect() {
>         sideEffect = 5;
>         return methSideEffect() instanceof int ii && sideEffect == 6;
>     }

Sure. One with `int ii` and the other with just `int`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182974720

From liach at openjdk.org  Thu Jul  3 14:50:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 14:50:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
Message-ID: <HwxqtLs9cPWN56US8saskfMeHXWsXc6LGSGuFy29Xco=.31cee469-ee9f-4f93-9396-928db521bd19@github.com>

On Thu, 3 Jul 2025 09:13:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
> 
>> 2844: 
>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
> 
> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

Re @lahodaj: I don't see how the primitive branch uses the value only once - it computes the value, and use it twice: 1st for ExactConversionSupport, 2nd for the expression result. I don't think we can elide the variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182985619

From liach at openjdk.org  Thu Jul  3 15:31:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 15:31:01 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Further improvements and testing per suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26107/files
  - new: https://git.openjdk.org/jdk/pull/26107/files/c577875b..544822b0

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

  Stats: 88 lines in 4 files changed: 46 ins; 18 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/26107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26107/head:pull/26107

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

From acobbs at openjdk.org  Thu Jul  3 16:28:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 16:28:27 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25810/files
  - new: https://git.openjdk.org/jdk/pull/25810/files/94cda824..2b16d657

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

  Stats: 68 lines in 5 files changed: 13 ins; 14 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25810/head:pull/25810

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

From acobbs at openjdk.org  Thu Jul  3 16:28:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 16:28:27 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
 <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>
Message-ID: <JQhqkwng2Cwfl-i_DwxCOGFqxcq2wIrij98PlO_PygM=.b6fc1877-7635-4bef-b70e-660a79d65ba0@github.com>

On Thu, 3 Jul 2025 10:00:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> These transformations could be also done in Java code inside `ClassGenerator` right?

Yes, that's simpler. Thanks for this and your other suggestions - all good ones. They should all be addressed in 2b16d65758b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2183204177

From mcimadamore at openjdk.org  Thu Jul  3 17:58:41 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 17:58:41 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
Message-ID: <a0oLOUljihFNwKnCEkvEY9wGsJ9m9xDZ5woQYm87SVQ=.fab9ef92-8d53-4ba2-9989-6e70f699416f@github.com>

On Thu, 3 Jul 2025 16:28:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review suggestions.
>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2984134010

From acobbs at openjdk.org  Thu Jul  3 18:15:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 18:15:50 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
Message-ID: <9g4fYx4fjc-Ugrc1sANarOyZYAXEOVI5u9QpkpcbrOQ=.18ef2010-a865-48f7-bb1f-eaa5f7e072bc@github.com>

On Thu, 3 Jul 2025 16:28:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review suggestions.
>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25810#issuecomment-3033139885

From acobbs at openjdk.org  Thu Jul  3 18:15:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 18:15:51 GMT
Subject: Integrated: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <imDmHS_yHF3Qxfg712iDAFK64gLqEpfcsxwMxWm7FpI=.9e504053-aae7-4569-8bcd-24c0c0069360@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

This pull request has now been integrated.

Changeset: 25ed36f3
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25ed36f3ef1fe1d6914689c762910f104775f48c
Stats:     919 lines in 17 files changed: 440 ins; 417 del; 62 mod

8359493: Refactor how aggregated mandatory warnings are handled in the compiler
8350514: Refactor MandatoryWarningHandler to support dynamic verbosity

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after
 attribution
Message-ID: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>

This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.

A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.

In addition, several other factors complicate things:
* Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
* Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
* Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
* Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
* Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
* Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
* Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.

Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".

The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

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

Commit messages:
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Merge branch 'master' into MandatoryWarningCleanup
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - Apply some review suggestions.
 - ... and 76 more: https://git.openjdk.org/jdk/compare/25ed36f3...ec02990a

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348611
  Stats: 1999 lines in 57 files changed: 1065 ins; 587 del; 347 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <DjwL7B3A49wsthxqPnQUB-JrtEy15CpEzRDYZOE6AgQ=.62dbff04-cb76-4049-97d9-03fb8e7bbb51@github.com>

On Thu, 10 Apr 2025 20:23:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Goals:

* Eliminate `DeferredLintHandler` and the requirement for code to configure and use it in order to log warnings
* Allow all warnings to be logged via `log.warning()` without having to know if/how `@SuppressWarnings` might apply
* Eliminate (mostly) the need for manual `Lint` instance manipulation

Design overview:

* Maintain mappings from source code position to `Lint` configuration in the `LintMapper` class
* Notify `LintMapper` when attribution completes so `Lint` configurations can be updated
* Hold/defer lint warnings in `Log.DiagnosticHandler` if the `Lint` configuration is not yet known
* Notify `Log` when held/deferred warnings should be reconsidered and flushed

Patch overview:
* `LintMapper.java`, `Log.java` - Replacing the functionality of `DeferredLintHandler` as described above
* `JavacTrees.java` - Add a couple of missing calls to `Log.useSource()`
* Other `src` classes - Derivative changes and cleanups/code removal
* `test` classes - Warning/error reorderings, plus a few new tests

Recommend ignoring whitespace when viewing the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-2835563690

From abimpoudis at openjdk.org  Thu Jul  3 19:15:40 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 19:15:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <czDVyX5XkuJ5nWuY8dPv59BfMCe3_w_6gDYdUHao80s=.b70f7b4d-2bd0-4f24-9b7c-7b496bea2c34@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 86:

> 84:     @Test
> 85:     public void testExpressionExecution() {
> 86:         int a = 0;

I wonder, should we also include a test that uses assignment to a reference type? 

e.g., `Long` so that we generate both the `null` check and the ECS call. I am 95% sure that everything will be fine. Up to you @liach

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183595443

From abimpoudis at openjdk.org  Thu Jul  3 19:48:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 19:48:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

Looks good from my side.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:

> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
> 2839:                 // instanceOfExpr; true
> 2840:                 sideEffect = make.Exec(instanceOfExpr);

maybe `evaluatedLHS` or `memoizedLHS`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2880:

> 2878:                 }
> 2879:             } else {
> 2880:                 throw Assert.error("Non primitive or reference type");

Nice!

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

PR Comment: https://git.openjdk.org/jdk/pull/26107#issuecomment-3033424938
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183635855
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183636159

From liach at openjdk.org  Thu Jul  3 20:50:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:50:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
Message-ID: <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>

On Thu, 3 Jul 2025 19:45:04 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further improvements and testing per suggestions
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:
> 
>> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2839:                 // instanceOfExpr; true
>> 2840:                 sideEffect = make.Exec(instanceOfExpr);
> 
> maybe `evaluatedLHS` or `memoizedLHS`.

This is not really a lhs - we are trying to generate "statement; expression", maybe rename this to `prefixStatement`?

> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 86:
> 
>> 84:     @Test
>> 85:     public void testExpressionExecution() {
>> 86:         int a = 0;
> 
> I wonder, should we also include a test that uses assignment to a reference type? 
> 
> e.g., `Long` so that we generate both the `null` check and the ECS call. I am 95% sure that everything will be fine. Up to you @liach

This test aims to ensure side effects are generated. Do we have no such tests yet? I think they better belong to the other 2 existing tests modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183724653
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183727330

From liach at openjdk.org  Thu Jul  3 20:51:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:51:43 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <gVwKFjlUGe4MKl2JCYrT-aRd26Uy9BHx2xBt7XWx1KY=.95b0bf69-e08f-4ebd-adaf-52e67dc3e17e@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26106#issuecomment-3033598244

From liach at openjdk.org  Thu Jul  3 20:51:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:51:43 GMT
Subject: Integrated: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <gSeH0ViymoV9cSpUWBMjgscoN83frpec7AccTWIeCtI=.0647b68c-acd9-4eba-843e-5f595e0330aa@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

This pull request has now been integrated.

Changeset: 566279af
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/566279af49a7cf47e6030222e989417855caf1a9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8360022: ClassRefDupInConstantPoolTest.java fails when running in repeat

Reviewed-by: vromero

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

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

From abimpoudis at openjdk.org  Thu Jul  3 20:56:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 20:56:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
 <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>
Message-ID: <v2-cQsy12wfZxcRc3r7-HxriDkPdtclYNVshbU1NcX4=.eb79253d-e2f4-4702-a040-d3af1569f6ef@github.com>

On Thu, 3 Jul 2025 20:45:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:
>> 
>>> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>>> 2839:                 // instanceOfExpr; true
>>> 2840:                 sideEffect = make.Exec(instanceOfExpr);
>> 
>> maybe `evaluatedLHS` or `memoizedLHS`.
>
> This is not really a lhs - we are trying to generate "statement; expression", maybe rename this to `prefixStatement`?

True. Yes, good name. Go for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183737197

From abimpoudis at openjdk.org  Thu Jul  3 21:36:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 21:36:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:

> 35: 
> 36: /*
> 37:  * @test

The name of this test should be `T8357185` I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183783683

From liach at openjdk.org  Fri Jul  4 01:00:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Jul 2025 01:00:58 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
Message-ID: <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>

On Thu, 3 Jul 2025 21:34:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further improvements and testing per suggestions
>
> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:
> 
>> 35: 
>> 36: /*
>> 37:  * @test
> 
> The name of this test should be `T8357185` I think.

I think we aim to name tests by the content instead of uninformative bug ids - ids are tracked with the bug jtreg directive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2184013173

From abimpoudis at openjdk.org  Fri Jul  4 07:39:40 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 4 Jul 2025 07:39:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
 <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
Message-ID: <4pskHhl0w3f-_fEZiRuJpEtIhst8W49B0frxFIEYZ1I=.4d699614-cffe-415e-8fed-7cce83a32262@github.com>

On Fri, 4 Jul 2025 00:58:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:
>> 
>>> 35: 
>>> 36: /*
>>> 37:  * @test
>> 
>> The name of this test should be `T8357185` I think.
>
> I think we aim to name tests by the content instead of uninformative bug ids - ids are tracked with the bug jtreg directive.

Both styles are adopted as we can observe in `jdk/test/langtools/tools/javac`. 

In any case the current name is definitely not descriptive as it has nothing to do with unconditionally exact testing inherently. This is done in `test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java` or other tests. Unconditionally exact conversion is the context but not the observed effect. 

The test name can be either `T8357185` or something descriptive like `RedundantVariablesInPrimitivePatterns`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2184634119

From nbenalla at openjdk.org  Fri Jul  4 11:39:12 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 4 Jul 2025 11:39:12 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25 build
 29
Message-ID: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>

Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

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

Commit messages:
 - Update --release 25 symbol information for JDK 25 build 29

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

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

From mcimadamore at openjdk.org  Fri Jul  4 15:23:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Jul 2025 15:23:53 GMT
Subject: RFR: 8361401: Warnings for use of Sun APIs should not be mandatory
Message-ID: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>

During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:

* warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
* warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)

The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.

This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.

I've tweaked an existing test to check the kind of the Sun API warnings.

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

Commit messages:
 - Remove Log::strictWarning
 - Merge with latest compiler changes
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/26129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361401
  Stats: 69 lines in 6 files changed: 38 ins; 16 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26129/head:pull/26129

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

From jlahoda at openjdk.org  Fri Jul  4 15:28:41 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 15:28:41 GMT
Subject: RFR: 8361401: Warnings for use of Sun APIs should not be mandatory
In-Reply-To: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
References: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
Message-ID: <vFtp7nD2aamWawY4BowzzUPNbS3YjiqZCD9Fy6EndLc=.8ede6fec-8e3b-4fa7-81e4-3ff2a6643ac6@github.com>

On Fri, 4 Jul 2025 10:57:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:
> 
> * warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
> * warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)
> 
> The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.
> 
> This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.
> 
> I've tweaked an existing test to check the kind of the Sun API warnings.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26129#pullrequestreview-2987683863

From jlahoda at openjdk.org  Fri Jul  4 17:44:39 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 17:44:39 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <e9XJNooBk9h67GgXFBa1Ir10JzLOJVkgTqnEPfleAK0=.ccd38271-437e-40fd-9e76-3cf924d29ab9@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

Overall, looks reasonable to me. A stylistic comment for consideration inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2834:

> 2832:     public void visitTypeTest(JCInstanceOf tree) {
> 2833:         if (tree.expr.type.isPrimitive() || tree.pattern.type.isPrimitive()) {
> 2834:             JCStatement sideEffect;

As a mostly stylistic comment: if I were doing this, I would create a variable like: `List<JCStatement> statements;` (or any other name), and then would assign either `List.nil()` or `List.of(...)` to it. That way there would be no `null` checks later.

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

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2987974182
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2185851259

From jlahoda at openjdk.org  Fri Jul  4 17:44:40 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 17:44:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <4pskHhl0w3f-_fEZiRuJpEtIhst8W49B0frxFIEYZ1I=.4d699614-cffe-415e-8fed-7cce83a32262@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
 <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
 <4pskHhl0w3f-_fEZiRuJpEtIhst8W49B0frxFIEYZ1I=.4d699614-cffe-415e-8fed-7cce83a32262@github.com>
Message-ID: <7jo5xLZe2L_CAMgCTDLm2NsReUjx0uuiJEHxpcpQzk8=.548ccee7-de39-48be-aa1a-552ea0bc8b7c@github.com>

On Fri, 4 Jul 2025 07:37:16 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> I think we aim to name tests by the content instead of uninformative bug ids - ids are tracked with the bug jtreg directive.
>
> Both styles are adopted as we can observe in `jdk/test/langtools/tools/javac`. 
> 
> In any case the current name is definitely not descriptive as it has nothing to do with unconditionally exact testing inherently. This is done in `test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java` or other tests. Unconditionally exact conversion is the context but not the observed effect. 
> 
> The test name can be either `T8357185` or something descriptive like `RedundantVariablesInPrimitivePatterns`.

The `T<number>` format is mostly frowned upon, and we mostly try to not use the convention for new tests. If we can have a good name, that's better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2185851338

From jlahoda at openjdk.org  Sun Jul  6 07:45:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Sun, 6 Jul 2025 07:45:57 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
Message-ID: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>

Consider this code:

@SuppressWarnings(CONST)
public class Ann {
    public static final String CONST = "";
}


javac will crash attempting to compile it:

$ javac -XDdev /tmp/Ann.java
/tmp/Ann.java:1: error: cannot find symbol
@SuppressWarnings(CONST)
                  ^
  symbol: variable CONST
1 error
An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
        at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
...


The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

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

Commit messages:
 - 8361445: javac crashes on unresolvable constant in @SuppressWarnings

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

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

From liach at openjdk.org  Sun Jul  6 12:12:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Jul 2025 12:12:37 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
Message-ID: <UW73uejWNzmJSqTqCXFn-5YcRW2uDqQLklUlRGSmX-c=.e45b3ff5-b794-4a2e-ac23-3d5b59d94f42@github.com>

On Sun, 6 Jul 2025 07:40:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> @SuppressWarnings(CONST)
> public class Ann {
>     public static final String CONST = "";
> }
> 
> 
> javac will crash attempting to compile it:
> 
> $ javac -XDdev /tmp/Ann.java
> /tmp/Ann.java:1: error: cannot find symbol
> @SuppressWarnings(CONST)
>                   ^
>   symbol: variable CONST
> 1 error
> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
> ...
> 
> 
> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

Does this also cover using a non-String constant?

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

PR Comment: https://git.openjdk.org/jdk/pull/26142#issuecomment-3041391614

From duke at openjdk.org  Sun Jul  6 17:29:38 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 6 Jul 2025 17:29:38 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
Message-ID: <stY2tyHAUpdcBuX4We87eXND0bbvKglWyulGhQ0Yk8g=.562c39a6-8c09-4c37-98a2-3b9bf0b309ea@github.com>

On Sun, 6 Jul 2025 07:40:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> @SuppressWarnings(CONST)
> public class Ann {
>     public static final String CONST = "";
> }
> 
> 
> javac will crash attempting to compile it:
> 
> $ javac -XDdev /tmp/Ann.java
> /tmp/Ann.java:1: error: cannot find symbol
> @SuppressWarnings(CONST)
>                   ^
>   symbol: variable CONST
> 1 error
> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
> ...
> 
> 
> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 538:

> 536:               .flatMap(LintCategory::get)
> 537:               .filter(lc -> lc.annotationSuppression)
> 538:               .ifPresent(result::add);

It?might be?better to?do?the?following, which?also?fixes the?non?`String`?case:
Suggestion:

            if (value instanceof Attribute.Constant c && c.value instanceof String s) {
                LintCategory.get(s)
                    .filter(lc -> lc.annotationSuppression)
                    .ifPresent(result::add);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26142#discussion_r2188478615

From jlahoda at openjdk.org  Mon Jul  7 08:30:41 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 08:30:41 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <stY2tyHAUpdcBuX4We87eXND0bbvKglWyulGhQ0Yk8g=.562c39a6-8c09-4c37-98a2-3b9bf0b309ea@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <stY2tyHAUpdcBuX4We87eXND0bbvKglWyulGhQ0Yk8g=.562c39a6-8c09-4c37-98a2-3b9bf0b309ea@github.com>
Message-ID: <VRnXOgadIfmYAovvB8NdRE17DPUEAR_cBj-y7wkqlik=.665aa7b4-b710-41d9-842f-e9c4d0129a0a@github.com>

On Sun, 6 Jul 2025 17:17:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Consider this code:
>> 
>> @SuppressWarnings(CONST)
>> public class Ann {
>>     public static final String CONST = "";
>> }
>> 
>> 
>> javac will crash attempting to compile it:
>> 
>> $ javac -XDdev /tmp/Ann.java
>> /tmp/Ann.java:1: error: cannot find symbol
>> @SuppressWarnings(CONST)
>>                   ^
>>   symbol: variable CONST
>> 1 error
>> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
>> ...
>> 
>> 
>> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 538:
> 
>> 536:               .flatMap(LintCategory::get)
>> 537:               .filter(lc -> lc.annotationSuppression)
>> 538:               .ifPresent(result::add);
> 
> It?might be?better to?do?the?following, which?also?fixes the?non?`String`?case:
> Suggestion:
> 
>             if (value instanceof Attribute.Constant c && c.value instanceof String s) {
>                 LintCategory.get(s)
>                     .filter(lc -> lc.annotationSuppression)
>                     .ifPresent(result::add);
>             }

Is there a reason to believe the non-`String` case is not covered by the current code? In the test, there is `testSuppressWarningsErroneousAttribute2` which shows the current code works for non-`String` constant of type `int`, is there a case we can add to the tests showing the current code not working?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26142#discussion_r2189353976

From mcimadamore at openjdk.org  Mon Jul  7 11:21:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 11:21:00 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object classInitial push
Message-ID: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>

The JLS says:

> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."

Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.

But a constructor in `Object` doesn't contain an explicit constructor invocation:

> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.

In other words, a constructor in the Object class has no prologue.

Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.

This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.

The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.

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

Commit messages:
 - Initial push

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

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

From jlahoda at openjdk.org  Mon Jul  7 12:07:37 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 12:07:37 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object class
In-Reply-To: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
Message-ID: <nkCtzQoc3Roao7nreCnTok0XJ4cq1_4XRogfE_34-Qg=.a0d11944-f43e-4cb1-aa8b-8cd52861552a@github.com>

On Mon, 7 Jul 2025 11:15:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The JLS says:
> 
>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
> 
> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
> 
> But a constructor in `Object` doesn't contain an explicit constructor invocation:
> 
>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
> 
> In other words, a constructor in the Object class has no prologue.
> 
> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
> 
> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
> 
> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26158#pullrequestreview-2993524614

From liach at openjdk.org  Mon Jul  7 12:15:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 12:15:39 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object class
In-Reply-To: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
Message-ID: <rbte9mDJp2uv5XPfxlTuWRMRlXup8cTn49FaB49-vJg=.59e4ff6e-fbf0-4722-bb50-efe656d6540a@github.com>

On Mon, 7 Jul 2025 11:15:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The JLS says:
> 
>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
> 
> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
> 
> But a constructor in `Object` doesn't contain an explicit constructor invocation:
> 
>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
> 
> In other words, a constructor in the Object class has no prologue.
> 
> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
> 
> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
> 
> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.

test/langtools/tools/javac/ObjectEarlyContext/java/lang/Object.java line 28:

> 26:  * @bug 8361481
> 27:  * @summary Flexible Constructor Bodies generates a compilation error when compiling a user supplied java.lang.Object class
> 28:  * @compile -source 8 Object.java

IMO the source 8 is redundant. A method call like toString in the ctor body should be sufficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26158#discussion_r2189883671

From jlahoda at openjdk.org  Mon Jul  7 12:31:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 12:31:53 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v2]
In-Reply-To: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
Message-ID: <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>

> Consider this code:
> 
> @SuppressWarnings(CONST)
> public class Ann {
>     public static final String CONST = "";
> }
> 
> 
> javac will crash attempting to compile it:
> 
> $ javac -XDdev /tmp/Ann.java
> /tmp/Ann.java:1: error: cannot find symbol
> @SuppressWarnings(CONST)
>                   ^
>   symbol: variable CONST
> 1 error
> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
> ...
> 
> 
> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

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

  Adding a more complex test ensuring incompatible types don't cause javac crashes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26142/files
  - new: https://git.openjdk.org/jdk/pull/26142/files/7dc9235e..db4d5686

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

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

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

From liach at openjdk.org  Mon Jul  7 12:36:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 12:36:46 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v2]
In-Reply-To: <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
Message-ID: <rSmh0tTfJhhDPkQe85cf0IOd4QcNmFcG6Tx3SxqlEJE=.2af092b0-d77f-487b-87b4-e66c211591d3@github.com>

On Mon, 7 Jul 2025 12:31:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider this code:
>> 
>> @SuppressWarnings(CONST)
>> public class Ann {
>>     public static final String CONST = "";
>> }
>> 
>> 
>> javac will crash attempting to compile it:
>> 
>> $ javac -XDdev /tmp/Ann.java
>> /tmp/Ann.java:1: error: cannot find symbol
>> @SuppressWarnings(CONST)
>>                   ^
>>   symbol: variable CONST
>> 1 error
>> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
>> ...
>> 
>> 
>> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a more complex test ensuring incompatible types don't cause javac crashes.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26142#pullrequestreview-2993641542

From abimpoudis at openjdk.org  Mon Jul  7 13:08:37 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Jul 2025 13:08:37 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v4]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <xbbHN-vr4-wwjUyyG5y-GoIT92uv9s28xobA1DsmNbE=.37e7f812-fd1f-4fd0-b746-6943c7c30740@github.com>

> In the following example, `G.Getter` is erroneously treated as a raw type by javac:
> 
> 
> static abstract class Getters<X> {
>   abstract class Getter {
>       abstract X get();
>   }
> }
> 
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> 
> The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 
> 
> While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 
> 
> - `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
> - Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
> - Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).
> 
> Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:
> 
> As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
> As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
> - An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
> - An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be the same.
> 
> The test now includes bytecode tests additionally t...

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

  Add test from 8357472 and simplify both methods getOuterSuper/getOwnerSuper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/68364b85..846c1f30

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

  Stats: 104 lines in 5 files changed: 86 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25451.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25451/head:pull/25451

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

From abimpoudis at openjdk.org  Mon Jul  7 13:16:05 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Jul 2025 13:16:05 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v5]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <Xk0X1wWHLFKRqmRvRmTWs-rPWin7X8zannqHjBxlGjc=.022ac039-43d2-41c0-aee1-86bb7982634b@github.com>

> In the following example, `G.Getter` is erroneously treated as a raw type by javac:
> 
> 
> static abstract class Getters<X> {
>   abstract class Getter {
>       abstract X get();
>   }
> }
> 
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> 
> The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 
> 
> While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 
> 
> - `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
> - Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
> - Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).
> 
> Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:
> 
> As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
> As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
> - An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
> - An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be the same.
> 
> The test now includes bytecode tests additionally t...

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

  Revert rename of asEnclosingSuper/asOuterSuper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/846c1f30..6b0429c3

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

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

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

From mcimadamore at openjdk.org  Mon Jul  7 14:05:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 14:05:40 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v5]
In-Reply-To: <Xk0X1wWHLFKRqmRvRmTWs-rPWin7X8zannqHjBxlGjc=.022ac039-43d2-41c0-aee1-86bb7982634b@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <Xk0X1wWHLFKRqmRvRmTWs-rPWin7X8zannqHjBxlGjc=.022ac039-43d2-41c0-aee1-86bb7982634b@github.com>
Message-ID: <hUzGn87Yih4r3BAVEGwZs9iRpEMs8ca2FRC80u7Fc6E=.f28b74dd-aaf8-48cb-92a1-61fdcd28130f@github.com>

On Mon, 7 Jul 2025 13:16:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> In the following example, `G.Getter` is erroneously treated as a raw type by javac:
>> 
>> 
>> static abstract class Getters<X> {
>>   abstract class Getter {
>>       abstract X get();
>>   }
>> }
>> 
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> 
>> The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 
>> 
>> While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 
>> 
>> - `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
>> - Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
>> - Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).
>> 
>> Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:
>> 
>> As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
>> As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
>> - An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
>> - An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be th...
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert rename of asEnclosingSuper/asOuterSuper

The new fix looks good. IMHO the main thing we need to add here is some better comments for `asEnclosingSuper` and `asOuterSuper` to describe in which cases they should be used.

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2994045735

From mcimadamore at openjdk.org  Mon Jul  7 14:53:39 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 14:53:39 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as
 an abstract class
In-Reply-To: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
References: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
Message-ID: <cACCMnwAKEZmVOd5RBME_2-yDoCleNMPgIyMluPXkEo=.31fafd9e-9b96-421f-b196-cd2c83e1ba2e@github.com>

On Wed, 2 Jul 2025 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is failing to compile this code:
> 
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>     Derived2(Derived1<T> obj) {}
> }
> 
> class Test {
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> }
> 
> issuing error message:
> 
> Test.java:8: error: Derived1 is abstract; cannot be instantiated
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> 
> basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,
> 
> TIA

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26103#pullrequestreview-2994225070

From vromero at openjdk.org  Mon Jul  7 15:01:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Jul 2025 15:01:50 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as
 an abstract class
In-Reply-To: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
References: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
Message-ID: <r00h8-CW71g6uUPEGvW80GcZn6EbBQUBOBYTz2P_uY0=.b8cb3746-e1b5-4677-bd03-45832308137d@github.com>

On Wed, 2 Jul 2025 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is failing to compile this code:
> 
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>     Derived2(Derived1<T> obj) {}
> }
> 
> class Test {
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> }
> 
> issuing error message:
> 
> Test.java:8: error: Derived1 is abstract; cannot be instantiated
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> 
> basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,
> 
> TIA

thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26103#issuecomment-3045516441

From asotona at openjdk.org  Mon Jul  7 15:01:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Jul 2025 15:01:43 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v2]
In-Reply-To: <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
Message-ID: <MsfNfUwmU4Pxv1_FQJeJbA2aZKDvfVFTjag37V_DgS4=.23789c4e-0b64-4a74-aea1-c1cb3f68d431@github.com>

On Mon, 7 Jul 2025 12:31:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider this code:
>> 
>> @SuppressWarnings(CONST)
>> public class Ann {
>>     public static final String CONST = "";
>> }
>> 
>> 
>> javac will crash attempting to compile it:
>> 
>> $ javac -XDdev /tmp/Ann.java
>> /tmp/Ann.java:1: error: cannot find symbol
>> @SuppressWarnings(CONST)
>>                   ^
>>   symbol: variable CONST
>> 1 error
>> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
>> ...
>> 
>> 
>> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a more complex test ensuring incompatible types don't cause javac crashes.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26142#pullrequestreview-2994252919

From vromero at openjdk.org  Mon Jul  7 15:01:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Jul 2025 15:01:51 GMT
Subject: Integrated: 8361214: An anonymous class is erroneously being classify
 as an abstract class
In-Reply-To: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
References: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
Message-ID: <STi73RRp-p53ngJPAUgYVSlNuaBWZS45vPIJaefMWVU=.22629a2d-114a-444e-a092-41c8644fa0c0@github.com>

On Wed, 2 Jul 2025 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is failing to compile this code:
> 
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>     Derived2(Derived1<T> obj) {}
> }
> 
> class Test {
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> }
> 
> issuing error message:
> 
> Test.java:8: error: Derived1 is abstract; cannot be instantiated
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> 
> basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,
> 
> TIA

This pull request has now been integrated.

Changeset: 05c9eec8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05c9eec8d087cbfffed19031a531b72ad18a52cf
Stats:     45 lines in 2 files changed: 44 ins; 0 del; 1 mod

8361214: An anonymous class is erroneously being classify as an abstract class

Reviewed-by: liach, mcimadamore

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

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

From abimpoudis at openjdk.org  Mon Jul  7 15:21:31 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Jul 2025 15:21:31 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v6]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <nd_LjZdsYOgwHoS9FpFhwIhimANQTmHWy2wdAUQ4wOU=.77e91161-494d-4254-b00b-d70decb1c2d1@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Improve comments of asEnclosingSuper/asOuterSuper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/6b0429c3..cc6523a8

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

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

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

From abimpoudis at openjdk.org  Mon Jul  7 15:21:32 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Jul 2025 15:21:32 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v5]
In-Reply-To: <Xk0X1wWHLFKRqmRvRmTWs-rPWin7X8zannqHjBxlGjc=.022ac039-43d2-41c0-aee1-86bb7982634b@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <Xk0X1wWHLFKRqmRvRmTWs-rPWin7X8zannqHjBxlGjc=.022ac039-43d2-41c0-aee1-86bb7982634b@github.com>
Message-ID: <HpcNYvxSPuYWKyRAB2fHrQvuF2Za1HnCifFpQvoBqzM=.e583789e-4a8f-496a-99a3-88a8f7818573@github.com>

On Mon, 7 Jul 2025 13:16:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert rename of asEnclosingSuper/asOuterSuper

I revised the text a bit. Let me know if that's a good direction.

I am still think about the opportunity we may have here o unify the two methods; maybe also by introducing some enum to emphasize the different modes of interpretation for qualified types?

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

PR Comment: https://git.openjdk.org/jdk/pull/25451#issuecomment-3045593424

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From mcimadamore at openjdk.org  Mon Jul  7 15:50:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 15:50:09 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object class [v2]
In-Reply-To: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
Message-ID: <_TUYrv0V9PYPKFFfhnrBZPxeQK3zu--wkEUPMNCNK-Q=.aea5ea51-42dc-4f5d-9add-c9b0698b28a3@github.com>

> The JLS says:
> 
>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
> 
> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
> 
> But a constructor in `Object` doesn't contain an explicit constructor invocation:
> 
>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
> 
> In other words, a constructor in the Object class has no prologue.
> 
> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
> 
> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
> 
> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak test to work with latest source version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26158/files
  - new: https://git.openjdk.org/jdk/pull/26158/files/2bd99e00..4189ba17

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

  Stats: 128 lines in 3 files changed: 89 ins; 39 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26158/head:pull/26158

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

From jlahoda at openjdk.org  Mon Jul  7 16:07:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 16:07:53 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v3]
In-Reply-To: <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
Message-ID: <MUmG6mGnbkhKPZlmNuOYBm-8H77SWKT22i_-zESy-fg=.8df3e814-8698-49e2-8ec2-5836cd0d7c08@github.com>

On Tue, 24 Jun 2025 13:40:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups per review comments.

FWIW, I am sorry, I missed the backport went to JDK 25u - that would not be part of JDK 25 GA. I've opened:
https://github.com/openjdk/jdk/pull/26163
which should go into the `jdk25` branch, and should eventually end up in JDK 25 GA, AFAIK. Sorry for missing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-3045738318

From jlahoda at openjdk.org  Mon Jul  7 16:10:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 16:10:08 GMT
Subject: [jdk25] RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given
Message-ID: <a9_CBPvmCALHQfvd-HjG7rWrVu9sAjqt0jZMvTQ8zAw=.3a105458-4e45-4672-8752-2e94aa168412@github.com>

Hi all,

This pull request contains a backport of commit [3525a40f](https://github.com/openjdk/jdk/commit/3525a40f39a966b8592f694a9b3cd4c5dc449266) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Archie Cobbs on 27 Jun 2025 and was reviewed by Maurizio Cimadamore and Uwe Schindler.

Thanks!

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

Commit messages:
 - Backport 3525a40f39a966b8592f694a9b3cd4c5dc449266

Changes: https://git.openjdk.org/jdk/pull/26163/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26163&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359596
  Stats: 104 lines in 6 files changed: 69 ins; 15 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26163/head:pull/26163

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

From acobbs at openjdk.org  Mon Jul  7 16:24:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Jul 2025 16:24:47 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v3]
In-Reply-To: <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
Message-ID: <O1uxcCwRglVFnFRv-hFHcWThyXKVGCuy0KK6EikONKk=.5edb7b3c-c02a-428e-bfd6-118b09065477@github.com>

On Tue, 24 Jun 2025 13:40:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups per review comments.

> FWIW, I am sorry, I missed the backport went to JDK 25u - that would not be part of JDK 25 GA. I've opened: #26163 which should go into the `jdk25` branch, and should eventually end up in JDK 25 GA, AFAIK. Sorry for missing this.

It's also my fault for not understanding `jdk25` vs. `jdk25u`. I didn't realize there already existed distinct branches at this point and had originally intended to backport this to the 25 initial release.

Thanks for fixing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-3045799837

From vromero at openjdk.org  Mon Jul  7 16:25:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Jul 2025 16:25:38 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object class [v2]
In-Reply-To: <_TUYrv0V9PYPKFFfhnrBZPxeQK3zu--wkEUPMNCNK-Q=.aea5ea51-42dc-4f5d-9add-c9b0698b28a3@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
 <_TUYrv0V9PYPKFFfhnrBZPxeQK3zu--wkEUPMNCNK-Q=.aea5ea51-42dc-4f5d-9add-c9b0698b28a3@github.com>
Message-ID: <eGZtx5ngS5gFmxVblU2ie7-el1kLsAbyKoSA9W_0yZg=.3c93e93b-9723-4f43-a794-16601fdb5218@github.com>

On Mon, 7 Jul 2025 15:50:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The JLS says:
>> 
>>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
>> 
>> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
>> 
>> But a constructor in `Object` doesn't contain an explicit constructor invocation:
>> 
>>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
>> 
>> In other words, a constructor in the Object class has no prologue.
>> 
>> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
>> 
>> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
>> 
>> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak test to work with latest source version

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26158#pullrequestreview-2994563438

From liach at openjdk.org  Mon Jul  7 16:37:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 16:37:38 GMT
Subject: RFR: 8361481: Flexible Constructor Bodies generates a compilation
 error when compiling a user supplied java.lang.Object class [v2]
In-Reply-To: <_TUYrv0V9PYPKFFfhnrBZPxeQK3zu--wkEUPMNCNK-Q=.aea5ea51-42dc-4f5d-9add-c9b0698b28a3@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
 <_TUYrv0V9PYPKFFfhnrBZPxeQK3zu--wkEUPMNCNK-Q=.aea5ea51-42dc-4f5d-9add-c9b0698b28a3@github.com>
Message-ID: <18ZrDUYXEhp4jX38q6vmo6QjBaXcXHcIyfKYmVb-n8E=.c0b0a122-96a9-4cb1-a087-f19f7d5ceda5@github.com>

On Mon, 7 Jul 2025 15:50:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The JLS says:
>> 
>>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
>> 
>> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
>> 
>> But a constructor in `Object` doesn't contain an explicit constructor invocation:
>> 
>>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
>> 
>> In other words, a constructor in the Object class has no prologue.
>> 
>> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
>> 
>> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
>> 
>> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak test to work with latest source version

The new test looks way better!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26158#pullrequestreview-2994635154

From mcimadamore at openjdk.org  Mon Jul  7 17:13:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 17:13:44 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v6]
In-Reply-To: <nd_LjZdsYOgwHoS9FpFhwIhimANQTmHWy2wdAUQ4wOU=.77e91161-494d-4254-b00b-d70decb1c2d1@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <nd_LjZdsYOgwHoS9FpFhwIhimANQTmHWy2wdAUQ4wOU=.77e91161-494d-4254-b00b-d70decb1c2d1@github.com>
Message-ID: <t4TrzHBL9ezB3R2SwRKiiOYH2byyz6OO4uZnoRn0E5M=.fdbb191c-17ba-478d-b281-58be0ddcee99@github.com>

On Mon, 7 Jul 2025 15:21:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments of asEnclosingSuper/asOuterSuper

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2240:

> 2238:      * with the given symbol. If none exists, return null.
> 2239:      *
> 2240:      * This is typically used when there is an explicit qualification of a type.

I don't think this is quite correct. The "classic" case for `asOuterType` is something like this (AFAIU):


class Sup<F> {
        public F f;
    }

class Outer {
    static class Sub extends Sup<String> {
        class I {
            void test() {
                String f2 = f;
            }
        }
    }
 }


Here, we see an access to a field `f`. The "site" for this method call is `I` (the class where the access comes from). What is the instantiated type of `m()` ? To answer that question we need to:

1. compute an instantiated receiver type -- e.g. some type that is related to `I` and that matches `Sup` (the class where `f` is declared). In this case such type is `Sup<String>`
2. replace the type parameters in the instantiated receiver type  in the (declared) signature of the field -- `[F=String]F` = `String`. That is the field signature we should use.

Step (1) here is typically done using `asOuterType`. This will keep trying with all the enclosing types of the input type. So, first `I`, then `Sub`. It will not try to use `Outer` -- which is correct as inside `I` we can't really access instance members in `Outer` (since `I` is an inner class of `Sub`, and `Sub` is `static`). So, from a coding perspective, using `getEnclosingType()` here is "more correct", as using `enclClass()` would "overshoot".

(That said, since we lookup from inner to outer, it is very likely that `asOuterSuper` and `asEnclosingSuper` yield the same result, even in this case -- although I'd prefer if our code did the correct thing and refused to look into unrelated classes).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2190659241

From mcimadamore at openjdk.org  Mon Jul  7 17:24:41 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Jul 2025 17:24:41 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v6]
In-Reply-To: <t4TrzHBL9ezB3R2SwRKiiOYH2byyz6OO4uZnoRn0E5M=.fdbb191c-17ba-478d-b281-58be0ddcee99@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <nd_LjZdsYOgwHoS9FpFhwIhimANQTmHWy2wdAUQ4wOU=.77e91161-494d-4254-b00b-d70decb1c2d1@github.com>
 <t4TrzHBL9ezB3R2SwRKiiOYH2byyz6OO4uZnoRn0E5M=.fdbb191c-17ba-478d-b281-58be0ddcee99@github.com>
Message-ID: <iCOx6Bsq9pbj2Xa27pEapXcu1KPuqR0FI1IHg7TkjE0=.2d8c53f1-b3a0-49fb-9829-ead25aba39cc@github.com>

On Mon, 7 Jul 2025 17:10:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments of asEnclosingSuper/asOuterSuper
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2240:
> 
>> 2238:      * with the given symbol. If none exists, return null.
>> 2239:      *
>> 2240:      * This is typically used when there is an explicit qualification of a type.
> 
> I don't think this is quite correct. The "classic" case for `asOuterType` is something like this (AFAIU):
> 
> 
> class Sup<F> {
>         public F f;
>     }
> 
> class Outer {
>     static class Sub extends Sup<String> {
>         class I {
>             void test() {
>                 String f2 = f;
>             }
>         }
>     }
>  }
> 
> 
> Here, we see an access to a field `f`. The "site" for this method call is `I` (the class where the access comes from). What is the instantiated type of `m()` ? To answer that question we need to:
> 
> 1. compute an instantiated receiver type -- e.g. some type that is related to `I` and that matches `Sup` (the class where `f` is declared). In this case such type is `Sup<String>`
> 2. replace the type parameters in the instantiated receiver type  in the (declared) signature of the field -- `[F=String]F` = `String`. That is the field signature we should use.
> 
> Step (1) here is typically done using `asOuterType`. This will keep trying with all the enclosing types of the input type. So, first `I`, then `Sub`. It will not try to use `Outer` -- which is correct as inside `I` we can't really access instance members in `Outer` (since `I` is an inner class of `Sub`, and `Sub` is `static`). So, from a coding perspective, using `getEnclosingType()` here is "more correct", as using `enclClass()` would "overshoot".
> 
> (That said, since we lookup from inner to outer, it is very likely that `asOuterSuper` and `asEnclosingSuper` yield the same result, even in this case -- although I'd prefer if our code did the correct thing and refused to look into unrelated classes).

In other words, sometimes (in `Types.memberType`) we have to find the instantiated owner type of a given instance member (field or method), so we can determine the member's instantiated type.

This only happens when the member access is a simple name (because if it is, say `<expr>.m()`, then we know of which type `m` is a member of -- namely the type of `<expr>`).

When the member access is a simple name, the input type to `memberType` is usually the class type in which access occurs -- and since the member can sometimes be a member of an enclosing class of the current class, we need to recurse.

Note that there would be nothing wrong in using `enclClass()` -- because, at the end of the day, `enclClass()` is what we used to resolve the symbol reference in the first place (see `Resolve::findVar` / `Resolve::findMethod` -- which uses `env.outer` -- which is like `enclClass`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2190677909

From liach at openjdk.org  Mon Jul  7 17:37:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 17:37:35 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v3]
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Review remarks, test adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26107/files
  - new: https://git.openjdk.org/jdk/pull/26107/files/544822b0..2507bf23

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

  Stats: 190 lines in 3 files changed: 83 ins; 100 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26107/head:pull/26107

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

From cushon at openjdk.org  Mon Jul  7 18:08:44 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 7 Jul 2025 18:08:44 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class [v2]
In-Reply-To: <Emxf5G5iVLbrdC4Qmj1-_13G_CJTjhoANXNZqrIQltY=.b0425f0c-bc34-4442-8409-ebbb09c6b0f7@github.com>
References: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
 <Emxf5G5iVLbrdC4Qmj1-_13G_CJTjhoANXNZqrIQltY=.b0425f0c-bc34-4442-8409-ebbb09c6b0f7@github.com>
Message-ID: <aysgoT1MAgtuNGVjQrSvVkbkt44n8UjfhsU9-mrsoog=.905161af-31ed-4281-875e-c58258e6ba34@github.com>

On Sun, 6 Apr 2025 04:52:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive.
>> 
>> As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug.
>> 
>> However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't.
>
> 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:
> 
>  - Handle error types in InferenceUnitTest
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - 8347291: Exhaustive switch over a generic sealed abstract class

I still think this is an improvement over the status quo, I am also fine dropping this if there's a preference for sticking with the status quo until it's possible to fix the inference crash and avoid the `InferenceException` entirely

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

PR Comment: https://git.openjdk.org/jdk/pull/23286#issuecomment-3046098072

From liach at openjdk.org  Mon Jul  7 21:16:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 21:16:41 GMT
Subject: [jdk25] RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given
In-Reply-To: <a9_CBPvmCALHQfvd-HjG7rWrVu9sAjqt0jZMvTQ8zAw=.3a105458-4e45-4672-8752-2e94aa168412@github.com>
References: <a9_CBPvmCALHQfvd-HjG7rWrVu9sAjqt0jZMvTQ8zAw=.3a105458-4e45-4672-8752-2e94aa168412@github.com>
Message-ID: <QOgWyk7gzuM2WMtVX452WUtmIwYhwb3LneRzWp-tPEM=.e080063a-9b2f-4bd3-81d2-d4694748913f@github.com>

On Mon, 7 Jul 2025 16:04:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [3525a40f](https://github.com/openjdk/jdk/commit/3525a40f39a966b8592f694a9b3cd4c5dc449266) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Archie Cobbs on 27 Jun 2025 and was reviewed by Maurizio Cimadamore and Uwe Schindler.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26163#pullrequestreview-2995292169

From jlu at openjdk.org  Mon Jul  7 21:57:44 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 7 Jul 2025 21:57:44 GMT
Subject: Integrated: 8361303: L10n comment for
 javac.opt.Xlint.desc.synchronization in javac.properties
In-Reply-To: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
References: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
Message-ID: <dWdv4sgCrGCzM5IOUyBOa8Xl_ROwV0zXixVEZhVrn5Q=.21a5bc53-8c64-4e64-a8c7-be326df96cbf@github.com>

On Wed, 2 Jul 2025 21:07:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

This pull request has now been integrated.

Changeset: 197fde53
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/197fde5363e314de7cd6090ecd77521f3a90c56d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8361303: L10n comment for javac.opt.Xlint.desc.synchronization in javac.properties

Reviewed-by: naoto, liach

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

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

From duke at openjdk.org  Mon Jul  7 22:02:43 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 7 Jul 2025 22:02:43 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v2]
In-Reply-To: <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
Message-ID: <UHjL1TX2RsFhTzLYZ1oyiK-7dXXvFDICihREZjlUwog=.08cc5f89-8fb0-4d93-a6aa-8eadb0e2e319@github.com>

On Mon, 7 Jul 2025 12:31:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider this code:
>> 
>> @SuppressWarnings(CONST)
>> public class Ann {
>>     public static final String CONST = "";
>> }
>> 
>> 
>> javac will crash attempting to compile it:
>> 
>> $ javac -XDdev /tmp/Ann.java
>> /tmp/Ann.java:1: error: cannot find symbol
>> @SuppressWarnings(CONST)
>>                   ^
>>   symbol: variable CONST
>> 1 error
>> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
>> ...
>> 
>> 
>> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a more complex test ensuring incompatible types don't cause javac crashes.

test/langtools/tools/javac/recovery/AnnotationRecovery.java line 178:

> 176:             "Test.CHAR",
> 177:             "Test.class",
> 178:             "@Deprecated"

Missing enum?constant test?case:
Suggestion:

            "E.A",
            "@Deprecated",

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26142#discussion_r2191070936

From darcy at openjdk.org  Tue Jul  8 05:04:38 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 8 Jul 2025 05:04:38 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25
 build 29
In-Reply-To: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
References: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
Message-ID: <0XYv_Lu7JAUhJKCIXglC2UxdD4Zl0TbuYFSGJw6fo_I=.363bb9f2-1441-4795-a4ee-ed5c3fe65591@github.com>

On Fri, 4 Jul 2025 11:33:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26131#pullrequestreview-2995981554

From iris at openjdk.org  Tue Jul  8 05:57:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 8 Jul 2025 05:57:38 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25
 build 29
In-Reply-To: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
References: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
Message-ID: <V6TNZL6nwB_qpn0u2CqnT_67QNzGlyd_mS0-bMr5rOQ=.6647f663-8539-41ba-ac6a-72ece1e3fa8e@github.com>

On Fri, 4 Jul 2025 11:33:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26131#pullrequestreview-2996084263

From jlahoda at openjdk.org  Tue Jul  8 07:13:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 07:13:22 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v3]
In-Reply-To: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
Message-ID: <JFXO65slNDNwsVrNK01xolzpju3ACXn_4ztjdu19Xkg=.bb1c2d3c-8211-420e-a66a-885143ba1007@github.com>

> Consider this code:
> 
> @SuppressWarnings(CONST)
> public class Ann {
>     public static final String CONST = "";
> }
> 
> 
> javac will crash attempting to compile it:
> 
> $ javac -XDdev /tmp/Ann.java
> /tmp/Ann.java:1: error: cannot find symbol
> @SuppressWarnings(CONST)
>                   ^
>   symbol: variable CONST
> 1 error
> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
> ...
> 
> 
> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

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

  Adding test for enum constants, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26142/files
  - new: https://git.openjdk.org/jdk/pull/26142/files/db4d5686..9527969e

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

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

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

From jlahoda at openjdk.org  Tue Jul  8 07:13:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 07:13:22 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v2]
In-Reply-To: <UHjL1TX2RsFhTzLYZ1oyiK-7dXXvFDICihREZjlUwog=.08cc5f89-8fb0-4d93-a6aa-8eadb0e2e319@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <RtEfLrRx5WwIdozgt12Nwx5YLgjlUFik_U65XpYEjhY=.a977b48a-341d-49a0-9591-f3c50b06dd8a@github.com>
 <UHjL1TX2RsFhTzLYZ1oyiK-7dXXvFDICihREZjlUwog=.08cc5f89-8fb0-4d93-a6aa-8eadb0e2e319@github.com>
Message-ID: <0UbN-bHTCM3voyQLallu4zfQfFQP0Ei4DKfUJtmtGm4=.d2ac69c0-abb2-4204-8df5-e5583c985ce2@github.com>

On Mon, 7 Jul 2025 21:58:55 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a more complex test ensuring incompatible types don't cause javac crashes.
>
> test/langtools/tools/javac/recovery/AnnotationRecovery.java line 178:
> 
>> 176:             "Test.CHAR",
>> 177:             "Test.class",
>> 178:             "@Deprecated"
> 
> Missing enum?constant test?case:
> Suggestion:
> 
>             "E.A",
>             "@Deprecated",

Oops, thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26142#discussion_r2191670190

From jlahoda at openjdk.org  Tue Jul  8 07:19:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 07:19:52 GMT
Subject: [jdk25] Integrated: 8359596: Behavior change when both -Xlint:options
 and -Xlint:-options flags are given
In-Reply-To: <a9_CBPvmCALHQfvd-HjG7rWrVu9sAjqt0jZMvTQ8zAw=.3a105458-4e45-4672-8752-2e94aa168412@github.com>
References: <a9_CBPvmCALHQfvd-HjG7rWrVu9sAjqt0jZMvTQ8zAw=.3a105458-4e45-4672-8752-2e94aa168412@github.com>
Message-ID: <gpl3GBqKFAht3CEqFbbql2FqX1cDgwjeMUITfef4Pxo=.13d33807-a013-4d1d-a4e8-23c6eb7b1eb9@github.com>

On Mon, 7 Jul 2025 16:04:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [3525a40f](https://github.com/openjdk/jdk/commit/3525a40f39a966b8592f694a9b3cd4c5dc449266) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Archie Cobbs on 27 Jun 2025 and was reviewed by Maurizio Cimadamore and Uwe Schindler.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 5e716fd7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e716fd7d1187d03f1320aa6aae2a9943388b1b9
Stats:     104 lines in 6 files changed: 69 ins; 15 del; 20 mod

8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given

Reviewed-by: liach
Backport-of: 3525a40f39a966b8592f694a9b3cd4c5dc449266

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

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

From asotona at openjdk.org  Tue Jul  8 07:46:40 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 8 Jul 2025 07:46:40 GMT
Subject: RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings [v3]
In-Reply-To: <JFXO65slNDNwsVrNK01xolzpju3ACXn_4ztjdu19Xkg=.bb1c2d3c-8211-420e-a66a-885143ba1007@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
 <JFXO65slNDNwsVrNK01xolzpju3ACXn_4ztjdu19Xkg=.bb1c2d3c-8211-420e-a66a-885143ba1007@github.com>
Message-ID: <iEKsI_hUTf5BVUbf8bWsKYOmyVtIXcGAEcNZLrauXmY=.73fb6776-d341-4431-a7e4-c2928c60e214@github.com>

On Tue, 8 Jul 2025 07:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider this code:
>> 
>> @SuppressWarnings(CONST)
>> public class Ann {
>>     public static final String CONST = "";
>> }
>> 
>> 
>> javac will crash attempting to compile it:
>> 
>> $ javac -XDdev /tmp/Ann.java
>> /tmp/Ann.java:1: error: cannot find symbol
>> @SuppressWarnings(CONST)
>>                   ^
>>   symbol: variable CONST
>> 1 error
>> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
>> ...
>> 
>> 
>> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test for enum constants, as suggested.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26142#pullrequestreview-2996393115

From jlahoda at openjdk.org  Tue Jul  8 08:03:24 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 08:03:24 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error
Message-ID: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>

Consider code like this:

$ cat /tmp/T.java 
import java.lang.ref.*;
public class T {
    public static void main(String[] args) {
        new WeakReference<>(null) {};
    }
}


Compiling this with JDK 25/26 leads to:

$ ./jdk-25/bin/javac /tmp/T.java
/tmp/T.java:4: error: modifier sealed not allowed here
        new WeakReference<>(null) {};
                                  ^
1 error


Which does not make much sense.

The reason for this is as follows:
- the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
- as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
- when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
- then javac goes on and checks whether the flags on the field are correct. And it sees the value for `SEALED` is set, and reports the error

Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.

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

Commit messages:
 - 8361570: Incorrect 'sealed is not allowed here' compile-time error

Changes: https://git.openjdk.org/jdk/pull/26181/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361570
  Stats: 112 lines in 3 files changed: 101 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26181/head:pull/26181

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

From jlahoda at openjdk.org  Tue Jul  8 09:28:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 09:28:58 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
Message-ID: <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>

> Consider code like this:
> 
> $ cat /tmp/T.java 
> import java.lang.ref.*;
> public class T {
>     public static void main(String[] args) {
>         new WeakReference<>(null) {};
>     }
> }
> 
> 
> Compiling this with JDK 25/26 leads to:
> 
> $ ./jdk-25/bin/javac /tmp/T.java
> /tmp/T.java:4: error: modifier sealed not allowed here
>         new WeakReference<>(null) {};
>                                   ^
> 1 error
> 
> 
> Which does not make much sense.
> 
> The reason for this is as follows:
> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
> - then javac goes on and checks whether the flags on the field are correct. And it sees the value for `SEALED` is set, and reports the error
> 
> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.

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

  Fixing tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26181/files
  - new: https://git.openjdk.org/jdk/pull/26181/files/efc83ed9..118503f0

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

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

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

From mcimadamore at openjdk.org  Tue Jul  8 10:41:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Jul 2025 10:41:47 GMT
Subject: Integrated: 8361481: Flexible Constructor Bodies generates a
 compilation error when compiling a user supplied java.lang.Object class
In-Reply-To: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
References: <bCgr93LeZmIflbFDWDWvkB6zJ7cSFTm5sT4P5DlIDyw=.91c0748d-f5b1-4b3a-bbc6-5d5466afbf3b@github.com>
Message-ID: <RPyWQj8dyTae6tPEtRJ6lNYvyoNjpIZj0NjjJzxsREg=.d4863e56-4d98-4343-b121-b33f1b5f6653@github.com>

On Mon, 7 Jul 2025 11:15:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The JLS says:
> 
>> IF a constructor body contains an explicit constructor invocation, the BlockStatements preceding the explicit constructor invocation are called the prologue of the constructor body."
> 
> Note the "IF". Only constructors that contain an explicit constructor invocation have a prologue.
> 
> But a constructor in `Object` doesn't contain an explicit constructor invocation:
> 
>> If a constructor body does not begin with an explicit constructor invocation **and the constructor being declared is not part of the primordial class Object**, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments.
> 
> In other words, a constructor in the Object class has no prologue.
> 
> Unfortunately javac misses this, and sets the `env.info.ctorPrologue` at the start of all constructors (even those in `Object`). However, since no implicit `super` call is added to `Object` constructors, this flag remains set for the entire body of the `Object` constructor -- that is, it's as if the whole constructor body was one big prologue.
> 
> This results in spurious errors being generated (and referring to preview features), as demonstrated in the issue linked to this PR.
> 
> The fix is not to set the `ctorPrologue` flag if we're in a constructor of the `Object` class.

This pull request has now been integrated.

Changeset: 1934bd8d
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1934bd8d2c02cdb1ba9caaef227ed073fb5e1a9d
Stats:     91 lines in 3 files changed: 89 ins; 0 del; 2 mod

8361481: Flexible Constructor Bodies generates a compilation error when compiling a user supplied java.lang.Object class

Reviewed-by: vromero, liach, jlahoda

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

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

From jlahoda at openjdk.org  Tue Jul  8 12:06:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 12:06:46 GMT
Subject: Integrated: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
References: <OSfTltEWwXa1_akqVnHrGHajejUKVB-RpBGYeza1F4U=.60555fe4-0d57-476c-8cba-5d098e17ecdc@github.com>
Message-ID: <a5joGliDLqdr8DPcS4hwYOg_vjePd6IuwRE-xEOv3s8=.7e8edcea-8725-45d9-8929-3fb2bfe88751@github.com>

On Sun, 6 Jul 2025 07:40:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> @SuppressWarnings(CONST)
> public class Ann {
>     public static final String CONST = "";
> }
> 
> 
> javac will crash attempting to compile it:
> 
> $ javac -XDdev /tmp/Ann.java
> /tmp/Ann.java:1: error: cannot find symbol
> @SuppressWarnings(CONST)
>                   ^
>   symbol: variable CONST
> 1 error
> An exception has occurred in the compiler (26-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.ClassCastException: class com.sun.tools.javac.code.Attribute$Error cannot be cast to class com.sun.tools.javac.code.Attribute$Constant (com.sun.tools.javac.code.Attribute$Error and com.sun.tools.javac.code.Attribute$Constant are in module jdk.compiler of loader 'app')
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:533)
> ...
> 
> 
> The reason is that the unresolvable constant will be `Attribute.Error`, not `Attribute.Constant`, and there's an unguarded cast. The proposal herein is to improve error recovery by ignoring non-constant annotation attributes in `Lint.suppressionsFrom`. Such erroneous cases should have already been reported as compile-time errors anyway.

This pull request has now been integrated.

Changeset: 0bd2f9cb
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd
Stats:     119 lines in 2 files changed: 116 ins; 0 del; 3 mod

8361445: javac crashes on unresolvable constant in @SuppressWarnings

Reviewed-by: asotona, liach

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

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

From mcimadamore at openjdk.org  Tue Jul  8 12:30:39 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Jul 2025 12:30:39 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
 <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
Message-ID: <lQAFHilqKyw_PEws1Ug4BMRZRYFXga-1mgVibneuuug=.6c3fe992-3edc-4b9c-b184-62f4149cab6f@github.com>

On Tue, 8 Jul 2025 09:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like this:
>> 
>> $ cat /tmp/T.java 
>> import java.lang.ref.*;
>> public class T {
>>     public static void main(String[] args) {
>>         new WeakReference<>(null) {};
>>     }
>> }
>> 
>> 
>> Compiling this with JDK 25/26 leads to:
>> 
>> $ ./jdk-25/bin/javac /tmp/T.java
>> /tmp/T.java:4: error: modifier sealed not allowed here
>>         new WeakReference<>(null) {};
>>                                   ^
>> 1 error
>> 
>> 
>> Which does not make much sense.
>> 
>> The reason for this is as follows:
>> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
>> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
>> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
>> - then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for `SEALED` is set, and reports the error
>> 
>> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

Fix looks good -- and thanks for the test.

I think we might be able to take the test a step further (in a separate PR) by introducing annotations to all flags, to denote whether a non-standard flag applies to:

* everything (such as extended standard flags)
* var-only (e.g. HAS_INIT)
* method-only (e.g. BRIDGE)
* type-only (e.g. ACYCLIC)

If we do this work, then we can write a test to make sure non-standard flags are truly disjoint. The test could also report an error when it finds any flag that doesn't have the associated annotation.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26181#pullrequestreview-2997428662

From liach at openjdk.org  Tue Jul  8 12:30:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 12:30:40 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
 <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
Message-ID: <OKL3MjB8gDdzAdPH8DKfyXEi6ewkKc3zAo6AL3a_2CE=.ecccd51b-2439-4ccc-9fc6-099f920f303e@github.com>

On Tue, 8 Jul 2025 09:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like this:
>> 
>> $ cat /tmp/T.java 
>> import java.lang.ref.*;
>> public class T {
>>     public static void main(String[] args) {
>>         new WeakReference<>(null) {};
>>     }
>> }
>> 
>> 
>> Compiling this with JDK 25/26 leads to:
>> 
>> $ ./jdk-25/bin/javac /tmp/T.java
>> /tmp/T.java:4: error: modifier sealed not allowed here
>>         new WeakReference<>(null) {};
>>                                   ^
>> 1 error
>> 
>> 
>> Which does not make much sense.
>> 
>> The reason for this is as follows:
>> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
>> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
>> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
>> - then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for `SEALED` is set, and reports the error
>> 
>> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 559:

> 557:         RECORD(Flags.RECORD),
> 558:         RECOVERABLE(Flags.RECOVERABLE),
> 559:         RESTRICTED(Flags.RESTRICTED),

Why do we need to add RESTRCITED this time?

test/langtools/tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java line 66:

> 64:             }
> 65:             long flag = ((Number) f.get(null)).longValue();
> 66:             value2FlagFields.computeIfAbsent(flag, _ -> new ArrayList<>())

If we are performing general flag checks, I recommend including checks to ensure there is exactly one bit set (like `Long.lowestOneBit(flag) == flag`)

So we no longer need a map, but can use a Field[64] and use `Long.numberOfTrailingZeros` to map to the array index.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26181#discussion_r2192368072
PR Review Comment: https://git.openjdk.org/jdk/pull/26181#discussion_r2192378480

From jlahoda at openjdk.org  Tue Jul  8 13:16:39 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 13:16:39 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <OKL3MjB8gDdzAdPH8DKfyXEi6ewkKc3zAo6AL3a_2CE=.ecccd51b-2439-4ccc-9fc6-099f920f303e@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
 <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
 <OKL3MjB8gDdzAdPH8DKfyXEi6ewkKc3zAo6AL3a_2CE=.ecccd51b-2439-4ccc-9fc6-099f920f303e@github.com>
Message-ID: <GjzjZQeTcqYmKhM64F1f8D-9bnpBd-04-Csy3VGcflw=.e08a9804-bac0-4b9f-a086-9c624f232665@github.com>

On Tue, 8 Jul 2025 12:23:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 559:
> 
>> 557:         RECORD(Flags.RECORD),
>> 558:         RECOVERABLE(Flags.RECOVERABLE),
>> 559:         RESTRICTED(Flags.RESTRICTED),
> 
> Why do we need to add RESTRCITED this time?

For every `long` value, the needs to be a `enum Flag` constant (which is weak, of course, as there are conceptually multiple flags using the same value, so the mapping to the enum would need to include the Symbol kind). As sealed now has a different number than `RESTRICTED`, `RESTRICTED` needs its own constant.

> test/langtools/tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java line 66:
> 
>> 64:             }
>> 65:             long flag = ((Number) f.get(null)).longValue();
>> 66:             value2FlagFields.computeIfAbsent(flag, _ -> new ArrayList<>())
> 
> If we are performing general flag checks, I recommend including checks to ensure there is exactly one bit set (like `Long.lowestOneBit(flag) == flag`)
> 
> So we no longer need a map, but can use a Field[64] and use `Long.numberOfTrailingZeros` to map to the array index.

I don't think this check is very general, it is more like a test checking one corner that is apparently problematic. Maurizio proposed a more general test below. There are constants in `Flags` that have multiple bits set (like `ExtendedStandardFlags`). We could filter those out, but having the map allows to collect all flags with the same value, not only 1+1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26181#discussion_r2192490897
PR Review Comment: https://git.openjdk.org/jdk/pull/26181#discussion_r2192497227

From jlahoda at openjdk.org  Tue Jul  8 13:26:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 13:26:22 GMT
Subject: [jdk25] RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
Message-ID: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>

Hi all,

This pull request contains a backport of commit [0bd2f9cb](https://github.com/openjdk/jdk/commit/0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Adam Sotona and Chen Liang.

Thanks!

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

Commit messages:
 - Backport 0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd

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

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

From liach at openjdk.org  Tue Jul  8 14:17:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:17:39 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <e9XJNooBk9h67GgXFBa1Ir10JzLOJVkgTqnEPfleAK0=.ccd38271-437e-40fd-9e76-3cf924d29ab9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <e9XJNooBk9h67GgXFBa1Ir10JzLOJVkgTqnEPfleAK0=.ccd38271-437e-40fd-9e76-3cf924d29ab9@github.com>
Message-ID: <uPUnjKVg7WbWUL9jz2DdfbzdxA26kaJ0VRQ5kjI1GQk=.8e4d9c5d-6936-4b19-a77f-795bb4bad27d@github.com>

On Fri, 4 Jul 2025 17:41:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further improvements and testing per suggestions
>
> Overall, looks reasonable to me. A stylistic comment for consideration inline.

@lahodaj @biboudis Can you review this again?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2834:
> 
>> 2832:     public void visitTypeTest(JCInstanceOf tree) {
>> 2833:         if (tree.expr.type.isPrimitive() || tree.pattern.type.isPrimitive()) {
>> 2834:             JCStatement sideEffect;
> 
> As a mostly stylistic comment: if I were doing this, I would create a variable like: `List<JCStatement> statements;` (or any other name), and then would assign either `List.nil()` or `List.of(...)` to it. That way there would be no `null` checks later.

Passing a nil list still creates a let expression; I don't think I wish to create a redundant let.

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

PR Comment: https://git.openjdk.org/jdk/pull/26107#issuecomment-3049142504
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2192652841

From liach at openjdk.org  Tue Jul  8 14:17:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:17:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <7jo5xLZe2L_CAMgCTDLm2NsReUjx0uuiJEHxpcpQzk8=.548ccee7-de39-48be-aa1a-552ea0bc8b7c@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
 <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
 <4pskHhl0w3f-_fEZiRuJpEtIhst8W49B0frxFIEYZ1I=.4d699614-cffe-415e-8fed-7cce83a32262@github.com>
 <7jo5xLZe2L_CAMgCTDLm2NsReUjx0uuiJEHxpcpQzk8=.548ccee7-de39-48be-aa1a-552ea0bc8b7c@github.com>
Message-ID: <5u_XUj10583vT227Q7jeBJ40iL5q8hvoz72HAGS1MzE=.6efe3f2d-a8dd-4e91-900e-0b314bd45e7b@github.com>

On Fri, 4 Jul 2025 17:40:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Both styles are adopted as we can observe in `jdk/test/langtools/tools/javac`. 
>> 
>> In any case the current name is definitely not descriptive as it has nothing to do with unconditionally exact testing inherently. This is done in `test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java` or other tests. Unconditionally exact conversion is the context but not the observed effect. 
>> 
>> The test name can be either `T8357185` or something descriptive like `RedundantVariablesInPrimitivePatterns`.
>
> The `T<number>` format is mostly frowned upon, and we mostly try to not use the convention for new tests. If we can have a good name, that's better.

I have readjusted this to be a classfile-focused test for primitive patterns and renamed accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2192653788

From vromero at openjdk.org  Tue Jul  8 14:20:49 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 14:20:49 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
 <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
Message-ID: <mZ8e1AGlktGYi8VZyXJ48RSL6un6Go-DNcgQLCWYTrs=.bf0e6b73-b68d-47e3-acd6-a0e85046f4e3@github.com>

On Tue, 8 Jul 2025 09:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like this:
>> 
>> $ cat /tmp/T.java 
>> import java.lang.ref.*;
>> public class T {
>>     public static void main(String[] args) {
>>         new WeakReference<>(null) {};
>>     }
>> }
>> 
>> 
>> Compiling this with JDK 25/26 leads to:
>> 
>> $ ./jdk-25/bin/javac /tmp/T.java
>> /tmp/T.java:4: error: modifier sealed not allowed here
>>         new WeakReference<>(null) {};
>>                                   ^
>> 1 error
>> 
>> 
>> Which does not make much sense.
>> 
>> The reason for this is as follows:
>> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
>> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
>> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
>> - then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for `SEALED` is set, and reports the error
>> 
>> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26181#pullrequestreview-2997869175

From duke at openjdk.org  Tue Jul  8 14:20:49 2025
From: duke at openjdk.org (Michael Bien)
Date: Tue, 8 Jul 2025 14:20:49 GMT
Subject: RFR: 8361570: Incorrect 'sealed is not allowed here' compile-time
 error [v2]
In-Reply-To: <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
 <qHG80CibhdQImroUy8Jlc3_FGG7ZbomgIh7hhFTjKLo=.a86f2bbf-ac65-472e-b72b-ca62caff3b80@github.com>
Message-ID: <yFKdvdRH8Cf0-t_DFBDazYDxCeWrYirTCc1DFNJwAPc=.6e2cab25-57c9-4389-b962-3c9dcb8758ae@github.com>

On Tue, 8 Jul 2025 09:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like this:
>> 
>> $ cat /tmp/T.java 
>> import java.lang.ref.*;
>> public class T {
>>     public static void main(String[] args) {
>>         new WeakReference<>(null) {};
>>     }
>> }
>> 
>> 
>> Compiling this with JDK 25/26 leads to:
>> 
>> $ ./jdk-25/bin/javac /tmp/T.java
>> /tmp/T.java:4: error: modifier sealed not allowed here
>>         new WeakReference<>(null) {};
>>                                   ^
>> 1 error
>> 
>> 
>> Which does not make much sense.
>> 
>> The reason for this is as follows:
>> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
>> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
>> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
>> - then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for `SEALED` is set, and reports the error
>> 
>> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

kudos to @lahodaj and colleagues who are working on the fixes - you guys are super fast. This PR appeared ~10h after the Apache NetBeans smoke test found it, the CCE issue (JDK-8361445) before that is also already fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26181#issuecomment-3049157819

From liach at openjdk.org  Tue Jul  8 14:24:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:24:46 GMT
Subject: [jdk25] RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
References: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
Message-ID: <dW7qLXpXQFVTJonzcpGIRRmOok2jq38cylFascBCisA=.e435525c-80ec-48ef-9264-1692250125ec@github.com>

On Tue, 8 Jul 2025 13:19:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0bd2f9cb](https://github.com/openjdk/jdk/commit/0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Adam Sotona and Chen Liang.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26183#pullrequestreview-2997895458

From asotona at openjdk.org  Tue Jul  8 14:31:40 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 8 Jul 2025 14:31:40 GMT
Subject: [jdk25] RFR: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
References: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
Message-ID: <E9_PzbM_bzP3uZa02F1UvNaQU-tWPPEOwsfiQqD4EVo=.e55b6ec3-6ba8-4281-a2ce-a9c921e067b7@github.com>

On Tue, 8 Jul 2025 13:19:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0bd2f9cb](https://github.com/openjdk/jdk/commit/0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Adam Sotona and Chen Liang.
> 
> Thanks!

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26183#pullrequestreview-2997920109

From vicente.romero at oracle.com  Tue Jul  8 14:36:37 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 8 Jul 2025 10:36:37 -0400
Subject: Javac incorrectly claims that class is abstract
In-Reply-To: <CAJEpuXQqikmgzS0Zdi36k5tiOtgN7_MqadoetJY6hxLbgOavGQ@mail.gmail.com>
References: <CAJEpuXQqikmgzS0Zdi36k5tiOtgN7_MqadoetJY6hxLbgOavGQ@mail.gmail.com>
Message-ID: <681d4398-ded3-4396-868e-f048e3a51f6b@oracle.com>

Hi Michael,

Thanks again for the issue you reported. It has been fixed in JDK 26,

Vicente

On 6/28/25 11:50, Michael Strau? wrote:
> The following program produces a compiler error on 24.0.1:
>
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>      Derived2(Derived1<T> obj) {}
> }
>
> Base<String> obj = new Derived2<>(
>      new Derived1<>() {
>          // not abstract
>      }) {
>          // not abstract
>      };
>
> --> error: Derived1 is abstract; cannot be instantiated
>
>
> However, when I explicitly specify the inferred type argument in
> either Derived1<String> or Derived2<String>, the program compiles:
>
> Base<String> obj = new Derived2<String>(
>      new Derived1<>() {
>          // not abstract
>      }) {
>          // not abstract
>      };
>
> --> OK


From jlahoda at openjdk.org  Tue Jul  8 14:37:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 14:37:52 GMT
Subject: Integrated: 8361570: Incorrect 'sealed is not allowed here'
 compile-time error
In-Reply-To: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
References: <FQogS8yMpT2iRmGi_ceNt_3LF9F01bdDHyAc2htb7ZQ=.08eaac5a-352d-41c4-adc6-e2cbe42dd417@github.com>
Message-ID: <KFSFktCZt-Gu1w1kMRJ0vlG4Qc9bOAsHqM0HH0Nk1TA=.41d102be-0e07-4caa-8324-c2319d0e2d48@github.com>

On Tue, 8 Jul 2025 07:58:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
> $ cat /tmp/T.java 
> import java.lang.ref.*;
> public class T {
>     public static void main(String[] args) {
>         new WeakReference<>(null) {};
>     }
> }
> 
> 
> Compiling this with JDK 25/26 leads to:
> 
> $ ./jdk-25/bin/javac /tmp/T.java
> /tmp/T.java:4: error: modifier sealed not allowed here
>         new WeakReference<>(null) {};
>                                   ^
> 1 error
> 
> 
> Which does not make much sense.
> 
> The reason for this is as follows:
> - the type parameter for `WeakReference` is marked with `@jdk.internal.RequiresIdentity`, and the `WeakReference`'s constructor has a parameter whose type is this type parameter.
> - as a consequence, this parameter has internally in javac flag `REQUIRES_IDENTITY`. Note this flag has currently the same `long` value as `SEALED`, as the value is reused to mean different things for different Symbol kinds.
> - when creating the anonymous class, javac creates a constructor, copying the `REQUIRES_IDENTITY` together with the constructor's parameter
> - then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for `SEALED` is set, and reports the error
> 
> Ultimately, I don't think we can reuse the value of `SEALED` to mean different things (and the same for all other similar cases). This PR assigns a different value for `SEALED`, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no `Flags` in `ExtendedStandardFlags` can be reused.

This pull request has now been integrated.

Changeset: 85331943
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/853319439e7887ddd54f8c4a3d79aa62ec51fd64
Stats:     118 lines in 4 files changed: 105 ins; 5 del; 8 mod

8361570: Incorrect 'sealed is not allowed here' compile-time error

Reviewed-by: mcimadamore, vromero

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

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

From jlahoda at openjdk.org  Tue Jul  8 14:39:40 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 14:39:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v3]
In-Reply-To: <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
Message-ID: <0IyUaVFN3HgE172iwhg4s0NXCMNJ2S2Meg_8ywE6Cnw=.bd69245b-9dc8-45a5-9b39-2e514ce5417c@github.com>

On Mon, 7 Jul 2025 17:37:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, test adjustment

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2997952205

From jlahoda at openjdk.org  Tue Jul  8 14:41:21 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Jul 2025 14:41:21 GMT
Subject: [jdk25] RFR: 8361570: Incorrect 'sealed is not allowed here'
 compile-time error
Message-ID: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>

Hi all,

This pull request contains a backport of commit [85331943](https://github.com/openjdk/jdk/commit/853319439e7887ddd54f8c4a3d79aa62ec51fd64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Maurizio Cimadamore and Vicente Romero.

Thanks!

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

Commit messages:
 - Backport 853319439e7887ddd54f8c4a3d79aa62ec51fd64

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

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

From liach at openjdk.org  Tue Jul  8 14:45:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:45:41 GMT
Subject: [jdk25] RFR: 8361570: Incorrect 'sealed is not allowed here'
 compile-time error
In-Reply-To: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
References: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
Message-ID: <5vlkMpSifdt0erhLoapStUTbYGwwWO7nLvxyDn_JDTo=.4c10bd87-f1c7-453c-b270-919b7fc31f19@github.com>

On Tue, 8 Jul 2025 14:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [85331943](https://github.com/openjdk/jdk/commit/853319439e7887ddd54f8c4a3d79aa62ec51fd64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Maurizio Cimadamore and Vicente Romero.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26188#pullrequestreview-2997978475

From vromero at openjdk.org  Tue Jul  8 15:39:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 15:39:39 GMT
Subject: [jdk25] RFR: 8361570: Incorrect 'sealed is not allowed here'
 compile-time error
In-Reply-To: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
References: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
Message-ID: <mDgGsJrXuvfNxWyZeN2-IuMqNqH0rH_9LLotDCVcemE=.ebaa21a2-71da-4639-9409-9e0cad2a67ef@github.com>

On Tue, 8 Jul 2025 14:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [85331943](https://github.com/openjdk/jdk/commit/853319439e7887ddd54f8c4a3d79aa62ec51fd64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Maurizio Cimadamore and Vicente Romero.
> 
> Thanks!

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26188#pullrequestreview-2998189617

From vromero at openjdk.org  Tue Jul  8 15:50:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 15:50:17 GMT
Subject: [jdk25] RFR: 8361214: An anonymous class is erroneously being classify
 as an abstract class
Message-ID: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>

Hi all,

This pull request contains a backport of commit [05c9eec8](https://github.com/openjdk/jdk/commit/05c9eec8d087cbfffed19031a531b72ad18a52cf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Vicente Romero on 7 Jul 2025 and was reviewed by Chen Liang and Maurizio Cimadamore.

Thanks!

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

Commit messages:
 - Backport 05c9eec8d087cbfffed19031a531b72ad18a52cf

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

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

From liach at openjdk.org  Tue Jul  8 16:00:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 16:00:39 GMT
Subject: [jdk25] RFR: 8361214: An anonymous class is erroneously being
 classify as an abstract class
In-Reply-To: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>
References: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>
Message-ID: <yziujv4rxNERNsEAUAHkY1Q39KntgWoBrjyEE8wwWHU=.281cd7b7-7e38-49ad-bed1-5883e8e5c177@github.com>

On Tue, 8 Jul 2025 15:42:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [05c9eec8](https://github.com/openjdk/jdk/commit/05c9eec8d087cbfffed19031a531b72ad18a52cf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Vicente Romero on 7 Jul 2025 and was reviewed by Chen Liang and Maurizio Cimadamore.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26191#pullrequestreview-2998252033

From abimpoudis at openjdk.org  Tue Jul  8 16:40:40 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 8 Jul 2025 16:40:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v3]
In-Reply-To: <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
Message-ID: <lmk1EJCKgOPydaN9aL91VWR4wxTX2kmrVaSKpuutNkM=.48c0fd45-3815-433c-8c1a-0dc1f76f8c40@github.com>

On Mon, 7 Jul 2025 17:37:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, test adjustment

Nice one! Looks good indeed.

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2998375696

From abimpoudis at openjdk.org  Tue Jul  8 19:41:35 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 8 Jul 2025 19:41:35 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v7]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <4TPp7SKKJgLCk4VY3LgR8RLf1jFDwuZMlWBwsWK_pQA=.46907bea-c823-46fe-b6e0-cc99f07fd2d6@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Extract common functionality from asOuterSuper/asEnclosingSuper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/cc6523a8..1f93dc7b

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

  Stats: 61 lines in 1 file changed: 11 ins; 28 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25451.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25451/head:pull/25451

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

From abimpoudis at openjdk.org  Tue Jul  8 20:01:43 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 8 Jul 2025 20:01:43 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v8]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <hZrJGbSwLvtGPCtt_h_dfMg1RUui_u4PE294R16Z2eA=.7d0f89f3-d385-466d-8cf8-3cd350cdd07b@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

 - Merge branch 'master' into JDK-8357653
 - Restore missing imports
 - Extract common functionality from asOuterSuper/asEnclosingSuper
 - Improve comments of asEnclosingSuper/asOuterSuper
 - Revert rename of asEnclosingSuper/asOuterSuper
 - Add test from 8357472 and simplify both methods getOuterSuper/getOwnerSuper
 - Remove unused field in test
 - Restore formatting of asOuterSuper
 - Address review
 - 8357653: Inner classes of type parameters emitted as raw types in signatures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/1f93dc7b..95f458f0

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

  Stats: 123245 lines in 2481 files changed: 73542 ins; 31287 del; 18416 mod
  Patch: https://git.openjdk.org/jdk/pull/25451.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25451/head:pull/25451

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

From abimpoudis at openjdk.org  Tue Jul  8 20:05:21 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 8 Jul 2025 20:05:21 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v9]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <jBiS2mVUSDu8zjliUh-dokdqC5TV7xAAXK9Hlu670D8=.0598f5f2-0221-48da-8220-cd81e9bdf544@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Move T8357653b to correct directory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/95f458f0..83730ea9

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

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

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

From abimpoudis at openjdk.org  Tue Jul  8 20:07:57 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 8 Jul 2025 20:07:57 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Fix imports again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/83730ea9..278aee7a

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

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

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

From mcimadamore at openjdk.org  Tue Jul  8 21:11:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Jul 2025 21:11:40 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
Message-ID: <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>

On Tue, 8 Jul 2025 20:07:57 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix imports again

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2260:

> 2258:      */
> 2259:     public Type asEnclosingSuper(Type t, Symbol sym) {
> 2260:         return asOuter(t, sym, type -> getOwnerEnclosingClassType(type));

You could also use a method reference here.

Also... I guess here we have to decide whether it's better to use a method reference, and leave a method like `getOwnerEnclosingClassType` permanently there, or, perhaps, just accept the fact that the logic represented by `getOwnerEnclosingClassType` is a bit weird, and has only really one use, and it belongs to a lambda expression, so as to achieve full encapsulation.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2280:

> 2278:      * @param nextType a unary operator that emits the next type to be examined
> 2279:      */
> 2280:     public Type asOuter(Type t, Symbol sym, UnaryOperator<Type> nextType) {

IMHO, this method should be called `asSuperXYZ` -- because that's what it does. It basically calls `asSuper` repeatedly (on the types returned by the unary operator) until a match is found.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2193444372
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2193447110

From vromero at openjdk.org  Tue Jul  8 21:14:19 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 21:14:19 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with -Xjcov
Message-ID: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>

After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,

TIA

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

Commit messages:
 - 8361499: intersection type cast causes javac crash with -Xjcov

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

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

From mcimadamore at openjdk.org  Tue Jul  8 21:15:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Jul 2025 21:15:40 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
Message-ID: <ghGJn7SMhHIltvUvHdOfM_hGgjGYm4XSoyHphA6j6Cc=.3d4e7fe8-2b5a-4cbd-9aa7-b0b0e624d269@github.com>

On Tue, 8 Jul 2025 20:07:57 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix imports again

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2270:

> 2268: 
> 2269:     /**
> 2270:      * Return the (most specific) base type of t that starts with

Base type smells like "raw" type -- e.g. non-parameterized. I wonder if it would be clearer to specify in a more direct way:

Calls `asSuper(S, sym)` on a sequence of types until a match is found. The sequence of types starts with `t` and the next type in the sequence is obtained by passing the previous type in the sequence to the unary operator `nextType`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2193452921

From vromero at openjdk.org  Tue Jul  8 21:16:44 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 21:16:44 GMT
Subject: [jdk25] RFR: 8361214: An anonymous class is erroneously being
 classify as an abstract class
In-Reply-To: <yziujv4rxNERNsEAUAHkY1Q39KntgWoBrjyEE8wwWHU=.281cd7b7-7e38-49ad-bed1-5883e8e5c177@github.com>
References: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>
 <yziujv4rxNERNsEAUAHkY1Q39KntgWoBrjyEE8wwWHU=.281cd7b7-7e38-49ad-bed1-5883e8e5c177@github.com>
Message-ID: <2NKr-N2udEiz9xH200cajhqLMni0bAWrgu-pltPeUpY=.73740e8f-58cb-4d8b-9c2f-b1b51d7303bf@github.com>

On Tue, 8 Jul 2025 15:57:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [05c9eec8](https://github.com/openjdk/jdk/commit/05c9eec8d087cbfffed19031a531b72ad18a52cf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Vicente Romero on 7 Jul 2025 and was reviewed by Chen Liang and Maurizio Cimadamore.
>> 
>> Thanks!
>
> Marked as reviewed by liach (Reviewer).

@liach thansk for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26191#issuecomment-3050313546

From vromero at openjdk.org  Tue Jul  8 21:16:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Jul 2025 21:16:45 GMT
Subject: [jdk25] Integrated: 8361214: An anonymous class is erroneously being
 classify as an abstract class
In-Reply-To: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>
References: <Fy0rWeywl6YcAokbWBvpBZeUd0sOjkIkd5Ctc3IQYmg=.efeac97f-b3dc-4740-96e7-d94b24bac06a@github.com>
Message-ID: <T4jvbeNbX0g81ZqyCA13DjNx7Jk30OWd66W0qJA9LoI=.60809873-cc94-4f98-920a-b9694d5ba02e@github.com>

On Tue, 8 Jul 2025 15:42:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [05c9eec8](https://github.com/openjdk/jdk/commit/05c9eec8d087cbfffed19031a531b72ad18a52cf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Vicente Romero on 7 Jul 2025 and was reviewed by Chen Liang and Maurizio Cimadamore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0e4422b2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e4422b284ab25064d67afc1473e2711f585886b
Stats:     45 lines in 2 files changed: 44 ins; 0 del; 1 mod

8361214: An anonymous class is erroneously being classify as an abstract class

Reviewed-by: liach
Backport-of: 05c9eec8d087cbfffed19031a531b72ad18a52cf

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

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

From mcimadamore at openjdk.org  Tue Jul  8 21:20:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Jul 2025 21:20:40 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <ghGJn7SMhHIltvUvHdOfM_hGgjGYm4XSoyHphA6j6Cc=.3d4e7fe8-2b5a-4cbd-9aa7-b0b0e624d269@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
 <ghGJn7SMhHIltvUvHdOfM_hGgjGYm4XSoyHphA6j6Cc=.3d4e7fe8-2b5a-4cbd-9aa7-b0b0e624d269@github.com>
Message-ID: <Aj1ac869XmugWdzEA4u91xHKI50x5hCg81d8iObMTSM=.ddfe0908-6abc-43e4-97f2-50c08e6dbbdf@github.com>

On Tue, 8 Jul 2025 21:13:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix imports again
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2270:
> 
>> 2268: 
>> 2269:     /**
>> 2270:      * Return the (most specific) base type of t that starts with
> 
> Base type smells like "raw" type -- e.g. non-parameterized. I wonder if it would be clearer to specify in a more direct way:
> 
> Calls `asSuper(S, sym)` on a sequence of types until a match is found. The sequence of types starts with `t` and the next type in the sequence is obtained by passing the previous type in the sequence to the unary operator `nextType`.

The text I wrote above can also be "specialized" for `asOuterSuper`:


Calls `asSuper(S, sym)` on a sequence of types until a match is found. The sequence of types starts with `t` and the next type in the sequence is obtained by calling `getEnclosingType()` on  the previous type in the sequence.


And similarly, for `asEnclosingSuper`:


Calls `asSuper(S, sym)` on a sequence of types until a match is found. The sequence of types starts with `t` and the next type in the sequence is obtained by obtaining innermost lexically enclosing class type of the previous type in the sequence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2193459134

From jlahoda at openjdk.org  Wed Jul  9 05:09:48 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Jul 2025 05:09:48 GMT
Subject: [jdk25] Integrated: 8361445: javac crashes on unresolvable constant in
 @SuppressWarnings
In-Reply-To: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
References: <OL_nw41PU2w0_0YeDI1-cFtFOkMgEGBQGbMFnliW4Mw=.4bbdd06f-2f9f-4944-a434-74c5c42bb566@github.com>
Message-ID: <Gs6hMQx1Bs234KffXiwB6IkuVDt4CctXUnEDrFNTQZ0=.c373c380-b656-4233-ac77-9fc257a419c1@github.com>

On Tue, 8 Jul 2025 13:19:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0bd2f9cb](https://github.com/openjdk/jdk/commit/0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Adam Sotona and Chen Liang.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 21cb2acd
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21cb2acda0d70cc838dfa097d235e86338609e7e
Stats:     119 lines in 2 files changed: 116 ins; 0 del; 3 mod

8361445: javac crashes on unresolvable constant in @SuppressWarnings

Reviewed-by: liach, asotona
Backport-of: 0bd2f9cba2118ed5a112b4c70b8ff4a1a58f21dd

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

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

From mcimadamore at openjdk.org  Wed Jul  9 10:32:39 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Jul 2025 10:32:39 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov
In-Reply-To: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
Message-ID: <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>

On Tue, 8 Jul 2025 21:08:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 1145:

> 1143: 
> 1144:     public void visitTypeIntersection(JCTypeIntersection tree) {
> 1145:         result = translate(tree.bounds, null).head;

Are we 100% sure that the type of the new result is the same as the old one? I'm trying to locate what `erasure(tree.type)` might have done -- but I can't see any code in `Types.erasure` that deals with intersections??

test/langtools/tools/javac/NoTypeIntersectionASTAfterTransTypesTest.java line 73:

> 71:     }
> 72: 
> 73:     static class MyTransTypes extends TransTypes {

I suppose another possible way to test would have been to register a task listener onto the compiler, and run that after the desugaring step. That way you don't have to extend TransTypes and use preRegister

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2194665449
PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2194663315

From abimpoudis at openjdk.org  Wed Jul  9 11:43:51 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 9 Jul 2025 11:43:51 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
 <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>
Message-ID: <7IElcMDhRlnX9BLoFi8Fuf_MuTMTDoSOf5XzRbn3quo=.42ad9002-4caa-417c-94bd-9ad778980499@github.com>

On Tue, 8 Jul 2025 21:07:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix imports again
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2260:
> 
>> 2258:      */
>> 2259:     public Type asEnclosingSuper(Type t, Symbol sym) {
>> 2260:         return asOuter(t, sym, type -> getOwnerEnclosingClassType(type));
> 
> You could also use a method reference here.
> 
> Also... I guess here we have to decide whether it's better to use a method reference, and leave a method like `getOwnerEnclosingClassType` permanently there, or, perhaps, just accept the fact that the logic represented by `getOwnerEnclosingClassType` is a bit weird, and has only really one use, and it belongs to a lambda expression, so as to achieve full encapsulation.

Also, the one is on `Type::getEnclosingType` and the other would be on `Types::getOwnerEnclosingClassType`.

I this this is too special to make it part of the hierarchy of `Type` and specially the `class DeclaredType`.
I think I would slightly prefer to keep it as a lambda ultimately to promote the custom logic here. I would strongly prefer to inline it even in the lambda, but there we lose the nice name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2194799326

From abimpoudis at openjdk.org  Wed Jul  9 11:47:41 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 9 Jul 2025 11:47:41 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
 <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>
Message-ID: <JdeRpwL3UVu_GfpdUVRvagWtMQp4nBpmnyUcAsw2tcE=.ed1f8c8b-5379-422a-8838-393317099b69@github.com>

On Tue, 8 Jul 2025 21:09:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix imports again
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2280:
> 
>> 2278:      * @param nextType a unary operator that emits the next type to be examined
>> 2279:      */
>> 2280:     public Type asOuter(Type t, Symbol sym, UnaryOperator<Type> nextType) {
> 
> IMHO, this method should be called `asSuperXYZ` -- because that's what it does. It basically calls `asSuper` repeatedly (on the types returned by the unary operator) until a match is found.

Ah, `asSuperClosure` would be nice. But there is another one called `superClosure`. What about `asSuperUpward`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2194805139

From liach at openjdk.org  Wed Jul  9 12:16:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Jul 2025 12:16:47 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v3]
In-Reply-To: <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <4M6lfbSQ3pTs8gFCGjkPgI6c3wmTuVyux9LAbng4HB8=.a0d8eac7-2d89-4446-b288-d56b6fb48c38@github.com>
Message-ID: <HaBPOG5tAP-zY-hOBWWU4Pqm1fuhutva71ZNsPF1j0o=.430737a3-c4d0-47d6-b6ab-d6de08197a48@github.com>

On Mon, 7 Jul 2025 17:37:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, test adjustment

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26107#issuecomment-3052422272

From liach at openjdk.org  Wed Jul  9 12:16:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Jul 2025 12:16:48 GMT
Subject: Integrated: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <IXvDwtTASXyzNB2xarrVTIfvw89GycUBmVx7PeGrcmQ=.1125b561-6b1b-4756-a684-b0dafc27e5fb@github.com>

On Wed, 2 Jul 2025 23:06:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

This pull request has now been integrated.

Changeset: d886ae12
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d886ae12a2ee3ce519c736d8950a17a0ce63ca78
Stats:     161 lines in 4 files changed: 124 ins; 17 del; 20 mod

8357185: Redundant local variables with unconditionally matching primitive patterns

Reviewed-by: jlahoda, abimpoudis

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

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

From abimpoudis at openjdk.org  Wed Jul  9 13:10:21 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 9 Jul 2025 13:10:21 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v11]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <T1zVX3EgODtwdtftHbMOUlBEkTVCHgpxco1C2lgZ-Sw=.651b6c5b-04e2-4ebf-a2e9-fc6480853dde@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/278aee7a..62b16202

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

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

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

From abimpoudis at openjdk.org  Wed Jul  9 13:10:21 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 9 Jul 2025 13:10:21 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
Message-ID: <JUY42cRW7q5_6O6DzxEvmDgAKGqIq0QKOFjD_GeOrIA=.24f60d68-e690-4627-a753-a90351cbd680@github.com>

On Tue, 8 Jul 2025 20:07:57 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix imports again

Updated PR. Let's see ?  how it looks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25451#issuecomment-3052608268

From jlahoda at openjdk.org  Wed Jul  9 13:43:48 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Jul 2025 13:43:48 GMT
Subject: [jdk25] Integrated: 8361570: Incorrect 'sealed is not allowed here'
 compile-time error
In-Reply-To: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
References: <TLLJbuDUXBsjDK4-gMQoQWqVlNLjGbCl4K0X1uMYhHw=.b0a5c84b-d35e-4513-af70-0f728a5d9256@github.com>
Message-ID: <cHWs1QsDxkI8kTw3amAqFGktSlLS4mTtJYxhR-OXsNA=.19381a47-bee5-4a33-be63-ac0863093f00@github.com>

On Tue, 8 Jul 2025 14:35:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [85331943](https://github.com/openjdk/jdk/commit/853319439e7887ddd54f8c4a3d79aa62ec51fd64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Maurizio Cimadamore and Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 50751da5
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50751da5625795e54e5235d18e4277add0ce233e
Stats:     118 lines in 4 files changed: 105 ins; 5 del; 8 mod

8361570: Incorrect 'sealed is not allowed here' compile-time error

Reviewed-by: liach, vromero
Backport-of: 853319439e7887ddd54f8c4a3d79aa62ec51fd64

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

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

From vromero at openjdk.org  Wed Jul  9 14:43:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Jul 2025 14:43:39 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov
In-Reply-To: <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
 <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
Message-ID: <rysm8MXr01eCWb222rrFv5vgkX5MSwQ9gaz3-IahrfU=.662f8d1d-7c61-413c-9c25-0ce88f15a789@github.com>

On Wed, 9 Jul 2025 10:29:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
>> 
>> TIA
>
> test/langtools/tools/javac/NoTypeIntersectionASTAfterTransTypesTest.java line 73:
> 
>> 71:     }
>> 72: 
>> 73:     static class MyTransTypes extends TransTypes {
> 
> I suppose another possible way to test would have been to register a task listener onto the compiler, and run that after the desugaring step. That way you don't have to extend TransTypes and use preRegister

right, I just wanted to be as precise as possible, with the current version we can check at the method level

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2195212101

From vromero at openjdk.org  Wed Jul  9 17:43:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Jul 2025 17:43:38 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov
In-Reply-To: <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
 <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
Message-ID: <RZW2AEgm-gO3URbVJ6JSy36QxEIvAAdMO2lYErtimLM=.0cf8b604-ead0-4c08-9173-e17bd7123f95@github.com>

On Wed, 9 Jul 2025 10:30:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 1145:
> 
>> 1143: 
>> 1144:     public void visitTypeIntersection(JCTypeIntersection tree) {
>> 1145:         result = translate(tree.bounds, null).head;
> 
> Are we 100% sure that the type of the new result is the same as the old one? I'm trying to locate what `erasure(tree.type)` might have done -- but I can't see any code in `Types.erasure` that deals with intersections??

The way the compiler deals with the erasure of intersections is a bit convoluted. Basically when the class symbol representing the intersection is created, its erasure is preset to its first explicit bound, provided that it is not a type variable. The code is at `Types::makeIntersectionType`. Later on, if `Types::erasure` is invoked on the intersection type, this already erased type is just read and returned, see method `visitClassType` at the erasure visitor in `Types`. Pasted below:

           public Type visitClassType(ClassType t, Boolean recurse) {
                Type erased = t.tsym.erasure(Types.this);
                if (recurse) {
                    erased = new ErasedClassType(erased.getEnclosingType(),erased.tsym,
                            t.dropMetadata(Annotations.class).getMetadata());
                    return erased;
                } else {
                    return combineMetadata(erased, t);
                }
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2195630514

From vromero at openjdk.org  Wed Jul  9 18:18:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Jul 2025 18:18:14 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov [v2]
In-Reply-To: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
Message-ID: <iNGe6vPmm9lEPU7ApIDYnW8Bjk4PKB4gZCO8E4EeEcI=.f919d31f-798d-4718-94e8-8daed4f6c0fd@github.com>

> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26203/files
  - new: https://git.openjdk.org/jdk/pull/26203/files/ccee3c67..cffcaee1

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

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

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

From mcimadamore at openjdk.org  Wed Jul  9 21:09:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Jul 2025 21:09:42 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov [v2]
In-Reply-To: <iNGe6vPmm9lEPU7ApIDYnW8Bjk4PKB4gZCO8E4EeEcI=.f919d31f-798d-4718-94e8-8daed4f6c0fd@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
 <iNGe6vPmm9lEPU7ApIDYnW8Bjk4PKB4gZCO8E4EeEcI=.f919d31f-798d-4718-94e8-8daed4f6c0fd@github.com>
Message-ID: <sjtRqJUC-zU34OyKcsz3SUUDjLmcRpVaG3GNpEMkdkU=.9042752d-c4f4-4729-9c82-860527cecd0b@github.com>

On Wed, 9 Jul 2025 18:18:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26203#pullrequestreview-3003092543

From mcimadamore at openjdk.org  Wed Jul  9 21:09:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Jul 2025 21:09:43 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov [v2]
In-Reply-To: <RZW2AEgm-gO3URbVJ6JSy36QxEIvAAdMO2lYErtimLM=.0cf8b604-ead0-4c08-9173-e17bd7123f95@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
 <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
 <RZW2AEgm-gO3URbVJ6JSy36QxEIvAAdMO2lYErtimLM=.0cf8b604-ead0-4c08-9173-e17bd7123f95@github.com>
Message-ID: <4bRwm8W2IUjL8uGqX9cSMKNEJt7R2AOXKeAsDD3fq5U=.3986c019-6ee5-4439-a69f-41920637586c@github.com>

On Wed, 9 Jul 2025 17:40:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 1145:
>> 
>>> 1143: 
>>> 1144:     public void visitTypeIntersection(JCTypeIntersection tree) {
>>> 1145:         result = translate(tree.bounds, null).head;
>> 
>> Are we 100% sure that the type of the new result is the same as the old one? I'm trying to locate what `erasure(tree.type)` might have done -- but I can't see any code in `Types.erasure` that deals with intersections??
>
> The way the compiler deals with the erasure of intersections is a bit convoluted. Basically when the class symbol representing the intersection is created, its erasure is preset to its first explicit bound, provided that it is not a type variable, but this would be an erroneous case anyways. The code is at `Types::makeIntersectionType`. Later on, if `Types::erasure` is invoked on the intersection type, this already erased type is just read and returned, see method `visitClassType` at the erasure visitor in `Types`. Pasted below for quick access:
> 
>            public Type visitClassType(ClassType t, Boolean recurse) {
>                 Type erased = t.tsym.erasure(Types.this);
>                 if (recurse) {
>                     erased = new ErasedClassType(erased.getEnclosingType(),erased.tsym,
>                             t.dropMetadata(Annotations.class).getMetadata());
>                     return erased;
>                 } else {
>                     return combineMetadata(erased, t);
>                 }
>             }

Ok, so the erasure of the intersection seems to be set at the erasure of its "first explicit bound", which should be equivalent to the new code (since it projects the intersection to its first component -- and given that all the components in an intersection type AST _are_ explicit).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2195974388

From mcimadamore at openjdk.org  Wed Jul  9 21:14:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Jul 2025 21:14:43 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v11]
In-Reply-To: <T1zVX3EgODtwdtftHbMOUlBEkTVCHgpxco1C2lgZ-Sw=.651b6c5b-04e2-4ebf-a2e9-fc6480853dde@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <T1zVX3EgODtwdtftHbMOUlBEkTVCHgpxco1C2lgZ-Sw=.651b6c5b-04e2-4ebf-a2e9-fc6480853dde@github.com>
Message-ID: <hfoI387c7jk43H0Kac5s_AA7PskMDSPQUc8iQW6wj9Y=.ac471d3b-0f24-4eb7-83b6-8a2a42128fb9@github.com>

On Wed, 9 Jul 2025 13:10:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks very good. I recommend (as per my other comment) to change the name to `asSuperClosure`, and rename `superClosure` to `supertypeClosure`.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3003114060

From mcimadamore at openjdk.org  Wed Jul  9 21:14:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Jul 2025 21:14:44 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v10]
In-Reply-To: <7IElcMDhRlnX9BLoFi8Fuf_MuTMTDoSOf5XzRbn3quo=.42ad9002-4caa-417c-94bd-9ad778980499@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <KgEk_er5BNtgZtbDBmU0-RVJE1OkldnUfevshtmtss4=.cefc79b2-ca8a-4936-b8ba-aed080a38083@github.com>
 <G01Yw2Ac_vU-mbOyp0lW4pv1ASAeV2fDlFhZIzy4dVs=.b03d216d-f705-413e-8de9-1dd8bb74582e@github.com>
 <7IElcMDhRlnX9BLoFi8Fuf_MuTMTDoSOf5XzRbn3quo=.42ad9002-4caa-417c-94bd-9ad778980499@github.com>
Message-ID: <Q05tbXagzKLwg_DRSd4BUXccJ8hnZvqWgUsuVqJhX1E=.322ab21b-cbe2-4a6d-a394-edd304acdc93@github.com>

On Wed, 9 Jul 2025 11:41:22 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2260:
>> 
>>> 2258:      */
>>> 2259:     public Type asEnclosingSuper(Type t, Symbol sym) {
>>> 2260:         return asOuter(t, sym, type -> getOwnerEnclosingClassType(type));
>> 
>> You could also use a method reference here.
>> 
>> Also... I guess here we have to decide whether it's better to use a method reference, and leave a method like `getOwnerEnclosingClassType` permanently there, or, perhaps, just accept the fact that the logic represented by `getOwnerEnclosingClassType` is a bit weird, and has only really one use, and it belongs to a lambda expression, so as to achieve full encapsulation.
>
> Also, the one is on `Type::getEnclosingType` and the other would be on `Types::getOwnerEnclosingClassType`.
> 
> I this this is too special to make it part of the hierarchy of `Type` and specially the `class DeclaredType`.
> I think I would slightly prefer to keep it as a lambda ultimately to promote the custom logic here. I would strongly prefer to inline it even in the lambda, but there we lose the nice name.

I agree that as a method it would look confusing either in `Type` or in `Symbol`

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2280:
>> 
>>> 2278:      * @param nextType a unary operator that emits the next type to be examined
>>> 2279:      */
>>> 2280:     public Type asOuter(Type t, Symbol sym, UnaryOperator<Type> nextType) {
>> 
>> IMHO, this method should be called `asSuperXYZ` -- because that's what it does. It basically calls `asSuper` repeatedly (on the types returned by the unary operator) until a match is found.
>
> Ah, `asSuperClosure` would be nice. But there is another one called `superClosure`. What about `asSuperUpward`?

I agree `asSuperClosure` is (very) nice. IMHO, use that, and rename the other to `supertypeClosure` as (1) that's what it is and (2) it only has one usage that I can see, so renaming is not a big deal and (3) it's a private method in Types, so no risk of it being exposed and accessed elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2195986619
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2195983582

From vromero at openjdk.org  Thu Jul 10 02:59:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 02:59:39 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v11]
In-Reply-To: <T1zVX3EgODtwdtftHbMOUlBEkTVCHgpxco1C2lgZ-Sw=.651b6c5b-04e2-4ebf-a2e9-fc6480853dde@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <T1zVX3EgODtwdtftHbMOUlBEkTVCHgpxco1C2lgZ-Sw=.651b6c5b-04e2-4ebf-a2e9-fc6480853dde@github.com>
Message-ID: <2EknbsQDSDhXPzQpVaupcIITMsylthmYhn0XtgJVEFE=.9011ec01-c460-4a95-9727-c162950e5d50@github.com>

On Wed, 9 Jul 2025 13:10:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2254:

> 2252:             } while (t.hasTag(CLASS));
> 2253:             return null;
> 2254:         case ARRAY:

should we add test cases including arrays?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2196399147

From abimpoudis at openjdk.org  Thu Jul 10 08:20:05 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 10 Jul 2025 08:20:05 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v12]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <g4xVE7I0Bm4QmRnBD8oQkliUowUWE0jfzcwGr5NCuIA=.d739162f-de24-4555-a6c5-c19ddee87990@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Address review 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/62b16202..60164933

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

  Stats: 64 lines in 4 files changed: 58 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25451.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25451/head:pull/25451

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

From vromero at openjdk.org  Thu Jul 10 10:42:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 10:42:45 GMT
Subject: RFR: 8361499: Intersection type cast causes javac crash with
 -Xjcov [v2]
In-Reply-To: <4bRwm8W2IUjL8uGqX9cSMKNEJt7R2AOXKeAsDD3fq5U=.3986c019-6ee5-4439-a69f-41920637586c@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
 <tytL-s-OJcwUFpBa51Lx5OfG9zYrA4KZhNsajKemNlk=.d78e82f1-b236-4f85-86b5-a5de2a534de4@github.com>
 <RZW2AEgm-gO3URbVJ6JSy36QxEIvAAdMO2lYErtimLM=.0cf8b604-ead0-4c08-9173-e17bd7123f95@github.com>
 <4bRwm8W2IUjL8uGqX9cSMKNEJt7R2AOXKeAsDD3fq5U=.3986c019-6ee5-4439-a69f-41920637586c@github.com>
Message-ID: <tMwZd74ReSy8Hyfn3_TKnWeLQqfnLmvROSioW3wVEDA=.d754882b-c8a5-428c-8692-95bd39b33ad4@github.com>

On Wed, 9 Jul 2025 21:05:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Ok, so the erasure of the intersection seems to be set at the erasure of its "first explicit bound", which should be equivalent to the new code (since it projects the intersection to its first component -- and given that all the components in an intersection type AST _are_ explicit).

correct, this is my understanding, thanks for the review

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2197329384

From vromero at openjdk.org  Thu Jul 10 10:42:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 10:42:46 GMT
Subject: Integrated: 8361499: Intersection type cast causes javac crash with
 -Xjcov
In-Reply-To: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
References: <K5nFYvyqksTSJocaWeR5719cWZJUHDUcLExdcwG3AIo=.cd42f7e5-1aca-46bf-bcc9-72a6a012a338@github.com>
Message-ID: <acK6PoQ3OhjcOpluZUclnMMZPvDvg9924SQsNuWpTSA=.470a889d-7bcd-43a7-aa79-e0a35bb20636@github.com>

On Tue, 8 Jul 2025 21:08:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
> 
> TIA

This pull request has now been integrated.

Changeset: 80662a48
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80662a485af9002d256d18d28a5bfe2a7c30e4d4
Stats:     97 lines in 2 files changed: 94 ins; 2 del; 1 mod

8361499: Intersection type cast causes javac crash with -Xjcov

Reviewed-by: mcimadamore

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

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

From vromero at openjdk.org  Thu Jul 10 10:57:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 10:57:41 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v12]
In-Reply-To: <g4xVE7I0Bm4QmRnBD8oQkliUowUWE0jfzcwGr5NCuIA=.d739162f-de24-4555-a6c5-c19ddee87990@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <g4xVE7I0Bm4QmRnBD8oQkliUowUWE0jfzcwGr5NCuIA=.d739162f-de24-4555-a6c5-c19ddee87990@github.com>
Message-ID: <JbmoTSQmXRhw_QWXUVDrX4OrXBflhdCF86-JkOfmEU8=.d2cac82e-d64d-48a7-8c66-40b1d2930eaa@github.com>

On Thu, 10 Jul 2025 08:20:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review 2

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2238:

> 2236: 
> 2237:     /**
> 2238:      * Calls `asSuper(S, sym)` on a sequence of types until a match is found.

nit: I wonder if we need to update this comment as the implementation is not directly invoking asSuper after all, same for method `asEnclosingSuper`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2197374513

From nbenalla at openjdk.org  Thu Jul 10 11:28:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 10 Jul 2025 11:28:44 GMT
Subject: Integrated: 8360302: Update --release 25 symbol information for JDK 25
 build 29
In-Reply-To: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
References: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
Message-ID: <-KPhJtUlUm-I-scDaCvBdzv1P15_NmFT1P50kPnibnY=.fda0932f-ba05-42d3-886b-a0173a778521@github.com>

On Fri, 4 Jul 2025 11:33:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

This pull request has now been integrated.

Changeset: 73ab54e4
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73ab54e4c33a3af2f2648e649ae41aee25d86f1b
Stats:     5 lines in 1 file changed: 1 ins; 3 del; 1 mod

8360302: Update --release 25 symbol information for JDK 25 build 29

Reviewed-by: darcy, iris

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

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

From nbenalla at openjdk.org  Thu Jul 10 11:28:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 10 Jul 2025 11:28:44 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25
 build 29
In-Reply-To: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
References: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
Message-ID: <b4rJ01Q5hVEXVoizAMxc4nY8yLIMiiv0lpc0isiDmsg=.29971f97-be05-4bc3-9d89-3438f5bcc7fd@github.com>

On Fri, 4 Jul 2025 11:33:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

All tests pass in our CI

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

PR Comment: https://git.openjdk.org/jdk/pull/26131#issuecomment-3057034948

From vromero at openjdk.org  Thu Jul 10 11:43:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 11:43:38 GMT
Subject: RFR: 8361401: Warnings for use of Sun APIs should not be mandatory
In-Reply-To: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
References: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
Message-ID: <2wp7Hza4rGPsWIXmPtEmBKIVu57ZN-ZAz8RJtocxAm8=.13f22f2b-3e00-4791-949f-4c2bd3987716@github.com>

On Fri, 4 Jul 2025 10:57:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:
> 
> * warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
> * warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)
> 
> The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.
> 
> This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.
> 
> I've tweaked an existing test to check the kind of the Sun API warnings.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26129#pullrequestreview-3005297172

From abimpoudis at openjdk.org  Thu Jul 10 12:17:27 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 10 Jul 2025 12:17:27 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v13]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <QXJetD-yyA69AJTgO7R_iFb0UVnLH220jVGNKssSKZI=.4fafc8a4-aa1c-4c49-8acb-7e451c5178d8@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Update comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/60164933..46089d7d

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

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

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

From abimpoudis at openjdk.org  Thu Jul 10 12:20:41 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 10 Jul 2025 12:20:41 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v12]
In-Reply-To: <JbmoTSQmXRhw_QWXUVDrX4OrXBflhdCF86-JkOfmEU8=.d2cac82e-d64d-48a7-8c66-40b1d2930eaa@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <g4xVE7I0Bm4QmRnBD8oQkliUowUWE0jfzcwGr5NCuIA=.d739162f-de24-4555-a6c5-c19ddee87990@github.com>
 <JbmoTSQmXRhw_QWXUVDrX4OrXBflhdCF86-JkOfmEU8=.d2cac82e-d64d-48a7-8c66-40b1d2930eaa@github.com>
Message-ID: <ZloEaxnX-vvkPjS1JPpV1dP6g93iUi0e67S56KSbHcA=.59e1afbf-71ae-4fe1-86f9-633ca54fd9d5@github.com>

On Thu, 10 Jul 2025 10:54:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review 2
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2238:
> 
>> 2236: 
>> 2237:     /**
>> 2238:      * Calls `asSuper(S, sym)` on a sequence of types until a match is found.
> 
> nit: I wonder if we need to update this comment as the implementation is not directly invoking asSuper after all, same for method `asEnclosingSuper`

True. I revised the text a bit trying to make "the sequence" stand out a bit more while keeping it as abstract as possible. There is a bit duplication on the first paragraph but it seems clear to me. However have another look to confirm that it is clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2197565978

From mcimadamore at openjdk.org  Thu Jul 10 12:24:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Jul 2025 12:24:42 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v13]
In-Reply-To: <QXJetD-yyA69AJTgO7R_iFb0UVnLH220jVGNKssSKZI=.4fafc8a4-aa1c-4c49-8acb-7e451c5178d8@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <QXJetD-yyA69AJTgO7R_iFb0UVnLH220jVGNKssSKZI=.4fafc8a4-aa1c-4c49-8acb-7e451c5178d8@github.com>
Message-ID: <8Ff4S5Pv1Kz7tOJtVua9M2VBaRRnP9hhT-JbgV3nBgs=.d4ecd31f-923d-4da9-9897-1bf0fbb8ef1f@github.com>

On Thu, 10 Jul 2025 12:17:27 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2285:

> 2283:      * @param nextType a unary operator that emits the next type to be examined
> 2284:      */
> 2285:     public Type asSuperClosure(Type t, Symbol sym, UnaryOperator<Type> nextType) {

Thinking more about naming -- javac is using the term `closure` typically to denote method that return a "bag of stuff" (e.g. transitive _closure_ of supertypes, members, etc.). Here `closure` doesn't mean really that, so I'm having second thoughts :-(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2197574790

From mcimadamore at openjdk.org  Thu Jul 10 12:34:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Jul 2025 12:34:45 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v13]
In-Reply-To: <8Ff4S5Pv1Kz7tOJtVua9M2VBaRRnP9hhT-JbgV3nBgs=.d4ecd31f-923d-4da9-9897-1bf0fbb8ef1f@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <QXJetD-yyA69AJTgO7R_iFb0UVnLH220jVGNKssSKZI=.4fafc8a4-aa1c-4c49-8acb-7e451c5178d8@github.com>
 <8Ff4S5Pv1Kz7tOJtVua9M2VBaRRnP9hhT-JbgV3nBgs=.d4ecd31f-923d-4da9-9897-1bf0fbb8ef1f@github.com>
Message-ID: <57cw2XSHTSO5-f1cZFpwJ_5nR39oP91tILXbcN3nAaM=.489e1c50-aab9-411e-a61d-013365e75115@github.com>

On Thu, 10 Jul 2025 12:22:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2285:
> 
>> 2283:      * @param nextType a unary operator that emits the next type to be examined
>> 2284:      */
>> 2285:     public Type asSuperClosure(Type t, Symbol sym, UnaryOperator<Type> nextType) {
> 
> Thinking more about naming -- javac is using the term `closure` typically to denote method that return a "bag of stuff" (e.g. transitive _closure_ of supertypes, members, etc.). Here `closure` doesn't mean really that, so I'm having second thoughts :-(

It also occurred to me that this `asSuperClosure` we're trying to add can be expressed using streams (I think):


Type input = ...
UnaryFunction<Type> updateFunction = ...
Function<Type, Type> mapFunction = ...

Stream.iterate(input, updateFunction)
      .map(mapFunction)
      .filter(site -> !site.hasTag(NONE))
      .findFirst();


Where `mapFunction` is `asSuper(t, sym)`, and `updateFunction` differs, depending on whether we want `asEnclosingSuper` or `asOuterSuper`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2197603672

From mcimadamore at openjdk.org  Thu Jul 10 12:39:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Jul 2025 12:39:43 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v13]
In-Reply-To: <57cw2XSHTSO5-f1cZFpwJ_5nR39oP91tILXbcN3nAaM=.489e1c50-aab9-411e-a61d-013365e75115@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <QXJetD-yyA69AJTgO7R_iFb0UVnLH220jVGNKssSKZI=.4fafc8a4-aa1c-4c49-8acb-7e451c5178d8@github.com>
 <8Ff4S5Pv1Kz7tOJtVua9M2VBaRRnP9hhT-JbgV3nBgs=.d4ecd31f-923d-4da9-9897-1bf0fbb8ef1f@github.com>
 <57cw2XSHTSO5-f1cZFpwJ_5nR39oP91tILXbcN3nAaM=.489e1c50-aab9-411e-a61d-013365e75115@github.com>
Message-ID: <nxi3PvaxYXj5v8TXjv0xfHoVh2lVwe1sCpSOf2OH_14=.78e98aea-1842-4958-b834-ef38e7141af2@github.com>

On Thu, 10 Jul 2025 12:32:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2285:
>> 
>>> 2283:      * @param nextType a unary operator that emits the next type to be examined
>>> 2284:      */
>>> 2285:     public Type asSuperClosure(Type t, Symbol sym, UnaryOperator<Type> nextType) {
>> 
>> Thinking more about naming -- javac is using the term `closure` typically to denote method that return a "bag of stuff" (e.g. transitive _closure_ of supertypes, members, etc.). Here `closure` doesn't mean really that, so I'm having second thoughts :-(
>
> It also occurred to me that this `asSuperClosure` we're trying to add can be expressed using streams (I think):
> 
> 
> Type input = ...
> UnaryFunction<Type> updateFunction = ...
> Function<Type, Type> mapFunction = ...
> 
> Stream.iterate(input, updateFunction)
>       .map(mapFunction)
>       .filter(site -> !site.hasTag(NONE))
>       .findFirst();
> 
> 
> Where `mapFunction` is `asSuper(t, sym)`, and `updateFunction` differs, depending on whether we want `asEnclosingSuper` or `asOuterSuper`.

My other feeling is that, while there is indeed some hidden commonality between `asEnclosingSuper` and `asOuterSuper` -- perhaps the addition of this new method is not super interesting -- as it is effectively only used in these two cases -- and it seems too specific to be used anywhere else (because it always uses `asSuper` and cannot be customized much). So perhaps, for now, the more honest approach is to leave it out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2197616611

From abimpoudis at openjdk.org  Thu Jul 10 13:32:31 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 10 Jul 2025 13:32:31 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v14]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <C-GtZqibuwKDf5TVGDvkLZXO2Y6aImESvQfD_-RSmuM=.77e56ada-f1f1-46a2-9e44-5d0a264fbd93@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Re-inline methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/46089d7d..e131c462

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

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

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

From vromero at openjdk.org  Thu Jul 10 15:04:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Jul 2025 15:04:42 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v14]
In-Reply-To: <C-GtZqibuwKDf5TVGDvkLZXO2Y6aImESvQfD_-RSmuM=.77e56ada-f1f1-46a2-9e44-5d0a264fbd93@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <C-GtZqibuwKDf5TVGDvkLZXO2Y6aImESvQfD_-RSmuM=.77e56ada-f1f1-46a2-9e44-5d0a264fbd93@github.com>
Message-ID: <srz_k459xz80UVqr06kYCBpybHo_ZYNwYu_7Wl2AqEs=.e66dbd70-8893-4c01-8d85-7ef7e7fc5882@github.com>

On Thu, 10 Jul 2025 13:32:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-inline methods

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3006145724

From mcimadamore at openjdk.org  Thu Jul 10 18:02:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Jul 2025 18:02:44 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v14]
In-Reply-To: <C-GtZqibuwKDf5TVGDvkLZXO2Y6aImESvQfD_-RSmuM=.77e56ada-f1f1-46a2-9e44-5d0a264fbd93@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <C-GtZqibuwKDf5TVGDvkLZXO2Y6aImESvQfD_-RSmuM=.77e56ada-f1f1-46a2-9e44-5d0a264fbd93@github.com>
Message-ID: <MKMA0ioS0LOQMkv84eZqLU6MNEqR6SM_Wm8utiV3-r0=.e1f0095f-2c05-4a1a-90b6-b73f11459875@github.com>

On Thu, 10 Jul 2025 13:32:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-inline methods

The code looks good to go. If you want to add more examples or comments in the javadoc, that might be useful, but the PR as is looks good.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3006738477

From abimpoudis at openjdk.org  Fri Jul 11 07:34:59 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 11 Jul 2025 07:34:59 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v15]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <7jlVUB7jtz4pW4NeFP4vdZ0HbRtI4iy5owx-PcSN6uU=.b1795e69-d4c4-4d96-935a-a331c103c748@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Add examples

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/e131c462..0e063a56

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

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

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

From cstein at openjdk.org  Fri Jul 11 09:10:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 11 Jul 2025 09:10:19 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 8
Message-ID: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>

Please review the change to update to using jtreg 8.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

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

Commit messages:
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

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

From vromero at openjdk.org  Fri Jul 11 13:27:47 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Jul 2025 13:27:47 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v15]
In-Reply-To: <7jlVUB7jtz4pW4NeFP4vdZ0HbRtI4iy5owx-PcSN6uU=.b1795e69-d4c4-4d96-935a-a331c103c748@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <7jlVUB7jtz4pW4NeFP4vdZ0HbRtI4iy5owx-PcSN6uU=.b1795e69-d4c4-4d96-935a-a331c103c748@github.com>
Message-ID: <441MocY3qAAbbXfOSQt2MNWOpzkO9mV0vvFx47HzVNE=.cf1b761d-ec6d-47c8-a8b3-a4de08f37a5b@github.com>

On Fri, 11 Jul 2025 07:34:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add examples

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2287:

> 2285:     /// previous type in the sequence.
> 2286:     ///
> 2287:     /// Example: The type application `B<?>` is implicitly qualified and the

I love this examples additions, some nit comments:

- there is no B<?> in the example below, I guess it is missing?
- there is a repetition: to discover to discover

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2200745425

From abimpoudis at openjdk.org  Fri Jul 11 13:39:59 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 11 Jul 2025 13:39:59 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v16]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <T3n_63UcA0MLcA8QQQ8590IwogwywHZfy9O_K8YayR0=.f720f898-fb14-453b-965a-94faac76d0e2@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Fix example

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/0e063a56..629ef2a7

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

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

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

From abimpoudis at openjdk.org  Fri Jul 11 13:39:59 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 11 Jul 2025 13:39:59 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v15]
In-Reply-To: <441MocY3qAAbbXfOSQt2MNWOpzkO9mV0vvFx47HzVNE=.cf1b761d-ec6d-47c8-a8b3-a4de08f37a5b@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <7jlVUB7jtz4pW4NeFP4vdZ0HbRtI4iy5owx-PcSN6uU=.b1795e69-d4c4-4d96-935a-a331c103c748@github.com>
 <441MocY3qAAbbXfOSQt2MNWOpzkO9mV0vvFx47HzVNE=.cf1b761d-ec6d-47c8-a8b3-a4de08f37a5b@github.com>
Message-ID: <tYcUqTSBSb4sIrMZb-awmwuETC6UY-Gzqqw1eUhRabg=.bd30363a-6eed-43f9-a9bd-0a5825607450@github.com>

On Fri, 11 Jul 2025 13:25:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add examples
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2287:
> 
>> 2285:     /// previous type in the sequence.
>> 2286:     ///
>> 2287:     /// Example: The type application `B<?>` is implicitly qualified and the
> 
> I love this examples additions, some nit comments:
> 
> - there is no B<?> in the example below, I guess it is missing?
> - there is a repetition: to discover to discover

Yeap, either `B` or `B<?>` demonstrate the same behavior (in different areas of the code). But for the sake of the example a simple type expression `B` is ok. Thanks for catching it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2200773039

From vromero at openjdk.org  Fri Jul 11 15:08:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Jul 2025 15:08:41 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v16]
In-Reply-To: <T3n_63UcA0MLcA8QQQ8590IwogwywHZfy9O_K8YayR0=.f720f898-fb14-453b-965a-94faac76d0e2@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <T3n_63UcA0MLcA8QQQ8590IwogwywHZfy9O_K8YayR0=.f720f898-fb14-453b-965a-94faac76d0e2@github.com>
Message-ID: <Focwk8oEO1nPU31QmXNaN_kZhmX6JWY5eizI1SnAkV8=.967886a0-a1b4-4707-acd2-9f755774db48@github.com>

On Fri, 11 Jul 2025 13:39:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix example

looks good, thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3010660635

From liach at openjdk.org  Fri Jul 11 15:37:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 15:37:44 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v16]
In-Reply-To: <T3n_63UcA0MLcA8QQQ8590IwogwywHZfy9O_K8YayR0=.f720f898-fb14-453b-965a-94faac76d0e2@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <T3n_63UcA0MLcA8QQQ8590IwogwywHZfy9O_K8YayR0=.f720f898-fb14-453b-965a-94faac76d0e2@github.com>
Message-ID: <NaUVmH5BcFNb1PnanBD6bh1NwEg24OSdkFQCXrafh6Y=.ffcb0592-355d-4553-88de-721a445bcbaf@github.com>

On Fri, 11 Jul 2025 13:39:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix example

Bikeshedding

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2240:

> 2238:     ///
> 2239:     /// The sequence of types starts with `t` and the next type in the sequence
> 2240:     /// is obtained by calling `getEnclosingType()` on  the previous type in the

Suggestion:

    /// is obtained by calling `getEnclosingType()` on the previous type in the

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2248:

> 2246:     /// seen as super of in the sequence `Outer.Sub.I`.
> 2247:     ///
> 2248:     /// Can `Sup` be seen as super of  `Outer.Sub.I`? No. Going to the next enclosing type .

Suggestion:

    /// Can `Sup` be seen as super of `Outer.Sub.I`? No. Going to the next enclosing type.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2249:

> 2247:     ///
> 2248:     /// Can `Sup` be seen as super of  `Outer.Sub.I`? No. Going to the next enclosing type .
> 2249:     /// Can `Sup` be seen as super of `Outer.Sub`? Yes! It?s outer results in `Sup<String>`.

Suggestion:

    /// Can `Sup` be seen as super of `Outer.Sub`? Yes! Its outer results in `Sup<String>`.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2264:

> 2262:     /// ```
> 2263:     ///
> 2264:     /// @implNote this is typically used to compute the implicit qualifier in a

Suggestion:

    /// @implNote This is typically used to compute the implicit qualifier in a

This is a new paragraph in a block tag

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2269:

> 2267:     /// @param t a type
> 2268:     /// @param sym a symbol
> 2269:     ///

Suggestion:

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2289:

> 2287:     /// Example: The type expression `B` is implicitly qualified and the
> 2288:     /// proper generic outer needs to be retrieved. Its site is `C.D` and its
> 2289:     /// outer type is `A`.`asEnclosingSuper` will use the enclosing classes to

Suggestion:

    /// outer type is `A`. `asEnclosingSuper` will use the enclosing classes to

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2306:

> 2304:     /// ```
> 2305:     ///
> 2306:     /// @implNote this is typically used to compute the implicit qualifier in

Suggestion:

    /// @implNote This is typically used to compute the implicit qualifier in

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2311:

> 2309:     /// @param t a type
> 2310:     /// @param sym a symbol
> 2311:     ///

Suggestion:

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3010786097
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201036914
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201040024
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201040868
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201042473
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201043202
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201044899
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201046326
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2201046562

From iris at openjdk.org  Fri Jul 11 17:42:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Jul 2025 17:42:38 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <hNvkWs8N0batlQY3XmA-hnwS_Z6Tc5DFIAusJSOoaDI=.0b5f04b6-643a-4c59-babb-f313b362f4ca@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3011356650

From joehw at openjdk.org  Fri Jul 11 17:52:39 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 11 Jul 2025 17:52:39 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <0DTztUpAJe-j6cGqC33j6xyeTb1W_dFdaP65Z7f6NFk=.7bb3d63e-2a5a-4a95-93d2-9249285bcf70@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

test/jaxp/TEST.ROOT looks good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3011378027

From naoto at openjdk.org  Fri Jul 11 18:54:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Jul 2025 18:54:47 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal
Message-ID: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>

In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361613
  Stats: 565 lines in 12 files changed: 221 ins; 237 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/26273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26273/head:pull/26273

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

From aturbanov at openjdk.org  Fri Jul 11 20:37:39 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 11 Jul 2025 20:37:39 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <sPGHxwyEZnTOcAJfWkoid69-mooCq49_icxd9D4Y-Fg=.1afba1fc-b8bb-4c68-b3fd-f25deab49660@github.com>

On Fri, 11 Jul 2025 18:46:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

test/jdk/java/io/Console/LocaleTest.java line 52:

> 50:  */
> 51: public class LocaleTest {
> 52:     private static final Calendar TODAY  = new GregorianCalendar(2024, Calendar.APRIL, 22);

Suggestion:

    private static final Calendar TODAY = new GregorianCalendar(2024, Calendar.APRIL, 22);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2201798509

From naoto at openjdk.org  Fri Jul 11 22:07:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Jul 2025 22:07:01 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/io/Console/LocaleTest.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26273/files
  - new: https://git.openjdk.org/jdk/pull/26273/files/ea72f445..82773085

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

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

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

From abimpoudis at openjdk.org  Mon Jul 14 08:15:24 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 14 Jul 2025 08:15:24 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v17]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <Y63bCCO5ChCXp7f1fvRDcbnl8cezljxxmKCS2RzhxM4=.8f4a095b-aa81-4417-a162-5e24325359e6@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Apply suggestions from code review
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/629ef2a7..4467d125

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

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

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

From liach at openjdk.org  Mon Jul 14 12:05:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 12:05:42 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v17]
In-Reply-To: <Y63bCCO5ChCXp7f1fvRDcbnl8cezljxxmKCS2RzhxM4=.8f4a095b-aa81-4417-a162-5e24325359e6@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <Y63bCCO5ChCXp7f1fvRDcbnl8cezljxxmKCS2RzhxM4=.8f4a095b-aa81-4417-a162-5e24325359e6@github.com>
Message-ID: <pFBQ11L7Ps9FCMtHINJ2NXqlYuPqxQRfkSQhooFIwko=.718c0d9d-72ae-46f0-9556-f54ea318a647@github.com>

On Mon, 14 Jul 2025 08:15:24 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3016073043

From abimpoudis at openjdk.org  Mon Jul 14 12:34:30 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 14 Jul 2025 12:34:30 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v18]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <c2valRhtsLzLvn-R01s-XFiLdN_0TKe8CSTTJ-UsRC0=.f718c1f2-7430-4012-b919-50ef1b5ae6ea@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Reduce comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/4467d125..a39bad3a

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

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

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

From jlahoda at openjdk.org  Mon Jul 14 12:54:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Jul 2025 12:54:16 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell
In-Reply-To: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
Message-ID: <gPziidcYXhQO5J8RpXyADKKyYuBNwiEElF_Tp069Kak=.a720575a-e78f-48e1-9bba-d857fb9cb102@github.com>

On Mon, 14 Jul 2025 12:48:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When in JShell, doing:
> 
> jshell> IO.readln();
> //Ctrl-D
> $1 ==> null
> 
> jshell> IO.readln()
> $2 ==> null //no input allowed
> 
> 
> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 1438:

> 1436:         public Attributes enterRawMode() {
> 1437:             Attributes res = super.enterRawMode();
> 1438:             res.setControlChar(ControlChar.VEOF, 4);

This is to correctly recognize `4`/Ctrl-D in the input in tests. Note this terminal is supposed to only be used by tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26292#discussion_r2204860401

From jlahoda at openjdk.org  Mon Jul 14 12:54:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Jul 2025 12:54:15 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once immediate
 Ctrl+D pressed in JShell
Message-ID: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>

When in JShell, doing:

jshell> IO.readln();
//Ctrl-D
$1 ==> null

jshell> IO.readln()
$2 ==> null //no input allowed


Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

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

Commit messages:
 - 8362116: System.in.read() etc. don't accept input once immediate Ctrl+D pressed in JShell

Changes: https://git.openjdk.org/jdk/pull/26292/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26292&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362116
  Stats: 84 lines in 5 files changed: 78 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26292/head:pull/26292

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

From cstein at openjdk.org  Mon Jul 14 13:17:39 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 14 Jul 2025 13:17:39 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell
In-Reply-To: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
Message-ID: <bpYnHUQ2pn7e5Rsx7FxfDGLy0kb3sKliQE_kfZSvuQY=.a617fab3-f52d-474f-991d-5a6b27e76fb9@github.com>

On Mon, 14 Jul 2025 12:48:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When in JShell, doing:
> 
> jshell> IO.readln();
> //Ctrl-D
> $1 ==> null
> 
> jshell> IO.readln()
> $2 ==> null //no input allowed
> 
> 
> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

`\u0004` can now be declared as a constant in `UITesting.java`, right next to:
https://github.com/openjdk/jdk/blob/bcd86d575fe0682a234228c18b0c2e817d3816da/test/langtools/jdk/jshell/UITesting.java#L48

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

PR Comment: https://git.openjdk.org/jdk/pull/26292#issuecomment-3069580222

From jlahoda at openjdk.org  Mon Jul 14 15:26:04 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Jul 2025 15:26:04 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell [v2]
In-Reply-To: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
Message-ID: <5MbZOzGubRh5-SXhdaxd_LEZ6gzdkamcspn09gnhZZs=.4d244a76-de20-4a19-9ee0-d433fd8b02e4@github.com>

> When in JShell, doing:
> 
> jshell> IO.readln();
> //Ctrl-D
> $1 ==> null
> 
> jshell> IO.readln()
> $2 ==> null //no input allowed
> 
> 
> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

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

  Creating a constant for Ctrl-D, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26292/files
  - new: https://git.openjdk.org/jdk/pull/26292/files/80b6e783..dd1df349

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

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

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

From liach at openjdk.org  Mon Jul 14 15:29:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 15:29:40 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell [v2]
In-Reply-To: <5MbZOzGubRh5-SXhdaxd_LEZ6gzdkamcspn09gnhZZs=.4d244a76-de20-4a19-9ee0-d433fd8b02e4@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
 <5MbZOzGubRh5-SXhdaxd_LEZ6gzdkamcspn09gnhZZs=.4d244a76-de20-4a19-9ee0-d433fd8b02e4@github.com>
Message-ID: <5rbmUhzq8Q3-s7WvCENpFxarMtiJ28PrZKJbgkGrDYM=.a40d9bd0-f736-4cd4-a1ba-8357614b0ceb@github.com>

On Mon, 14 Jul 2025 15:26:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When in JShell, doing:
>> 
>> jshell> IO.readln();
>> //Ctrl-D
>> $1 ==> null
>> 
>> jshell> IO.readln()
>> $2 ==> null //no input allowed
>> 
>> 
>> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Creating a constant for Ctrl-D, as suggested.

Looks reasonable.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26292#pullrequestreview-3016799705

From cstein at openjdk.org  Mon Jul 14 15:43:40 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 14 Jul 2025 15:43:40 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell [v2]
In-Reply-To: <5MbZOzGubRh5-SXhdaxd_LEZ6gzdkamcspn09gnhZZs=.4d244a76-de20-4a19-9ee0-d433fd8b02e4@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
 <5MbZOzGubRh5-SXhdaxd_LEZ6gzdkamcspn09gnhZZs=.4d244a76-de20-4a19-9ee0-d433fd8b02e4@github.com>
Message-ID: <xjJFAibdjOFwY8kNPe_rhyTP9h2Bi1fp7LxD329fZXI=.9e6328d2-f925-4a18-aaf0-4ad16732781e@github.com>

On Mon, 14 Jul 2025 15:26:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When in JShell, doing:
>> 
>> jshell> IO.readln();
>> //Ctrl-D
>> $1 ==> null
>> 
>> jshell> IO.readln()
>> $2 ==> null //no input allowed
>> 
>> 
>> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Creating a constant for Ctrl-D, as suggested.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26292#pullrequestreview-3016849490

From jlu at openjdk.org  Mon Jul 14 18:54:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 18:54:40 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
Message-ID: <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>

On Fri, 11 Jul 2025 22:07:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/io/Console/LocaleTest.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/io/Console/DefaultCharsetTest.java line 52:

> 50:     void testDefaultCharset(String stdoutEncoding) throws Exception {
> 51:         // check "expect" command availability
> 52:         var expect = Paths.get("/usr/bin/expect");

We only need to check "expect" availability once, so we should move this check to a `@BeforeAll` static method. It's also more clear that this check is a precondition, and not part of the actual test. Applies to the other locations, but primarily the other parameterized tests.

test/jdk/java/io/Console/ModuleSelectionTest.java line 32:

> 30:  * @library /test/lib
> 31:  * @build jdk.test.lib.Utils
> 32:  *        jdk.test.lib.JDKToolFinder

Is `jdk.test.lib.JDKToolFinder` needed?

test/jdk/java/io/Console/ModuleSelectionTest.java line 65:

> 63:     @ParameterizedTest
> 64:     @MethodSource("options")
> 65:     void testWithoutExpect(String opts, String expected) throws Exception {

`expected` param looks unused.

test/jdk/java/io/Console/ModuleSelectionTest.java line 75:

> 73:     @ParameterizedTest
> 74:     @MethodSource("options")
> 75:     void testWithExpect(String opts, String expected) throws Exception {

I think it would be more clear if these tests were renamed to `expectConsoleTest` and `noConsoleTest` or something along those lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205500449
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205576522
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205557781
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205573038

From jlahoda at openjdk.org  Mon Jul 14 19:18:25 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Jul 2025 19:18:25 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell [v3]
In-Reply-To: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
Message-ID: <JiakJrhH1WbSyYAf8zBs8JciRqqOyFmaMFSpnbtJlkQ=.2b89168b-ed3b-47dd-bf24-9f2c60356fdf@github.com>

> When in JShell, doing:
> 
> jshell> IO.readln();
> //Ctrl-D
> $1 ==> null
> 
> jshell> IO.readln()
> $2 ==> null //no input allowed
> 
> 
> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

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

  Fixing test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26292/files
  - new: https://git.openjdk.org/jdk/pull/26292/files/dd1df349..5ef03eb8

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

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

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

From naoto at openjdk.org  Mon Jul 14 20:23:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 20:23:25 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26273/files
  - new: https://git.openjdk.org/jdk/pull/26273/files/82773085..5a4114c7

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

  Stats: 12 lines in 2 files changed: 4 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26273/head:pull/26273

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

From naoto at openjdk.org  Mon Jul 14 20:32:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 20:32:44 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
 <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>
Message-ID: <rf5xQ_CGwHtzkolp923Zulecw2CbYqfoYk88vPh3f14=.02f0462a-3f03-4f7e-b626-e85f32e3973b@github.com>

On Mon, 14 Jul 2025 17:57:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/io/Console/LocaleTest.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/java/io/Console/DefaultCharsetTest.java line 52:
> 
>> 50:     void testDefaultCharset(String stdoutEncoding) throws Exception {
>> 51:         // check "expect" command availability
>> 52:         var expect = Paths.get("/usr/bin/expect");
> 
> We only need to check "expect" availability once, so we should move this check to a `@BeforeAll` static method. It's also more clear that this check is a precondition, and not part of the actual test. Applies to the other locations, but primarily the other parameterized tests.

Good point. Modified to use `@BeforeAll`. For `ModuleSelectionTest`, one of the test is not using `expect`, so I left it as it is. In addition to that, I removed the `@requires` condition to allow that test to run on windows.

> test/jdk/java/io/Console/ModuleSelectionTest.java line 75:
> 
>> 73:     @ParameterizedTest
>> 74:     @MethodSource("options")
>> 75:     void testWithExpect(String opts, String expected) throws Exception {
> 
> I think it would be more clear if these tests were renamed to `expectConsoleTest` and `noConsoleTest` or something along those lines.

Yeah, using `expect` command with junit's expect is confusing ?. Just renamed those methods using TTY/NonTTY, as"expect/noConsoleTest" reads somewhat odd as it includes the expected results in the test name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205749625
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205753058

From duke at openjdk.org  Mon Jul 14 20:56:45 2025
From: duke at openjdk.org (Skrue2)
Date: Mon, 14 Jul 2025 20:56:45 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25
 build 29
In-Reply-To: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
References: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>
Message-ID: <A4QUf4DJa9Ehhre3JCVsiL5ZUBRdq0i99cOuV0gmZgk=.19b2dd69-f8a6-4205-a6b4-2c215f7366db@github.com>

On Fri, 4 Jul 2025 11:33:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

Marked as reviewed by Skrue2 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26131#pullrequestreview-3017788555

From mcimadamore at openjdk.org  Mon Jul 14 21:05:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 14 Jul 2025 21:05:43 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v18]
In-Reply-To: <c2valRhtsLzLvn-R01s-XFiLdN_0TKe8CSTTJ-UsRC0=.f718c1f2-7430-4012-b919-50ef1b5ae6ea@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <c2valRhtsLzLvn-R01s-XFiLdN_0TKe8CSTTJ-UsRC0=.f718c1f2-7430-4012-b919-50ef1b5ae6ea@github.com>
Message-ID: <zxP6dhsN5kxoQp-e-ZuL0AF0rLVaV0ETnF0WhHJ0e-Y=.87abf7c4-20a8-4e0c-ab33-26542785cf6c@github.com>

On Mon, 14 Jul 2025 12:34:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce comments

Looks very good, I left two optional minor doc changes

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2248:

> 2246:      *        class I {
> 2247:      *          void test() {
> 2248:      *              String f2 = f; // Sup<String>

Suggestion:

     *              String f2 = f; // Sup<String>::f

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2278:

> 2276:      * class C extends A<String> {
> 2277:      *   static class D {
> 2278:      *      B b; // qualifier is A<String>.B

Suggestion:

     *      B b; // A<String>.B

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3017839826
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2205825684
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2205826160

From egor.ushakov at jetbrains.com  Fri Jul 11 15:08:24 2025
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Fri, 11 Jul 2025 17:08:24 +0200
Subject: lambda method naming changes in jdk 24
Message-ID: <71f259c7-a64e-4550-ae4d-b28b8ed0c792@jetbrains.com>

Hi everyone!

it looks like in jdk 24 compiler started naming lambda methods slightly 
differently,
consider the code:

public class Lambdas1 {
     public static void main(String[]args) {
         Runnable r3 = () -> {
             Runnable r4 = () ->System.out.println(new Exception().getStackTrace()[0]);
             r4.run();
             System.out.println(new Exception().getStackTrace()[0]);
         };
         r3.run();
     }
}

with jdk 23 the output is:
Lambdas1.lambda$main$*0*(Lambdas1.java:7)
Lambdas1.lambda$main$*1*(Lambdas1.java:9)

with jdk 24:
Lambdas1.lambda$main$*1*(Lambdas1.java:4)
Lambdas1.lambda$main$*0*(Lambdas1.java:6)

I know that this is not specified anywhere, but Intellij IDEA relied on 
this and it caused issues with debugger features:
https://youtrack.jetbrains.com/issue/IDEA-375811

Was this change really intended? Could anyone please point me to the fix 
that caused this?

Thanks!
Egor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250711/e5888526/attachment.htm>

From maurizio.cimadamore at oracle.com  Mon Jul 14 21:32:12 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 14 Jul 2025 22:32:12 +0100
Subject: lambda method naming changes in jdk 24
In-Reply-To: <71f259c7-a64e-4550-ae4d-b28b8ed0c792@jetbrains.com>
References: <71f259c7-a64e-4550-ae4d-b28b8ed0c792@jetbrains.com>
Message-ID: <07750800-6bca-46c4-b480-f360dc06d650@oracle.com>

Hi Egor,
I confirm that this change is deliberate. There were several changes 
required to make JEP 513 (Flexible Constructor Bodies) work. Some of 
these changes resulted in significant rewrites of the compiler backend 
(to move lambda translation ahead of inner class translation). The bulk 
of the work (and some history) is here:

https://github.com/openjdk/jdk/pull/19836

This change created some compatibility issues for serializable lambdas, 
which were later addressed here:

https://github.com/openjdk/jdk/pull/20349

This latter change dropped a lot of accidental complexity from the javac 
LambdaToInner pass, and that meant making the logic for computing the 
names serializable and non-serializable lambdas more robust.

This meant that, unfortunately, the (unspecified) name of some 
non-serializable lambda changed. This compatibility issue is described 
in the associated CSR:

https://bugs.openjdk.org/browse/JDK-8337558

The difference you see is caused by when the name of the translated 
lambda method is generated -- it used to be computed _after_ the end of 
the lambda body, now it is computed _before_. This means that as soon as 
we see the outermost lambda for `r3` we give it the first number -- then 
the nested lambda for `r4` gets the second number.

This allows us to avoid having to "patch" the names of the translated 
symbols, which minimizes the amount of mutation in our code, making it 
less brittle. So, unless there's a big reason as to why these names 
should go back the way they were, we'd like to keep the code the way it 
is :-)

Cheers
Maurizio

On 11/07/2025 16:08, Egor Ushakov wrote:
> Hi everyone!
>
> it looks like in jdk 24 compiler started naming lambda methods 
> slightly differently,
> consider the code:
> public class Lambdas1 {
>      public static void main(String[]args) {
>          Runnable r3 = () -> {
>              Runnable r4 = () ->System.out.println(new Exception().getStackTrace()[0]);
>              r4.run();
>              System.out.println(new Exception().getStackTrace()[0]);
>          };
>          r3.run();
>      }
> }
>
> with jdk 23 the output is:
> Lambdas1.lambda$main$*0*(Lambdas1.java:7)
> Lambdas1.lambda$main$*1*(Lambdas1.java:9)
>
> with jdk 24:
> Lambdas1.lambda$main$*1*(Lambdas1.java:4)
> Lambdas1.lambda$main$*0*(Lambdas1.java:6)
>
> I know that this is not specified anywhere, but Intellij IDEA relied 
> on this and it caused issues with debugger features:
> https://youtrack.jetbrains.com/issue/IDEA-375811
>
> Was this change really intended? Could anyone please point me to the 
> fix that caused this?
>
> Thanks!
> Egor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250714/9494bcde/attachment-0001.htm>

From liach at openjdk.org  Mon Jul 14 23:35:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 23:35:38 GMT
Subject: RFR: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell [v3]
In-Reply-To: <JiakJrhH1WbSyYAf8zBs8JciRqqOyFmaMFSpnbtJlkQ=.2b89168b-ed3b-47dd-bf24-9f2c60356fdf@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
 <JiakJrhH1WbSyYAf8zBs8JciRqqOyFmaMFSpnbtJlkQ=.2b89168b-ed3b-47dd-bf24-9f2c60356fdf@github.com>
Message-ID: <2gwgyEaaMqV8qZcf6ukB8hEwULkpkLBGmmz_W3aM-y8=.d4401e3b-999d-40b9-bee8-d510d34bf8ba@github.com>

On Mon, 14 Jul 2025 19:18:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When in JShell, doing:
>> 
>> jshell> IO.readln();
>> //Ctrl-D
>> $1 ==> null
>> 
>> jshell> IO.readln()
>> $2 ==> null //no input allowed
>> 
>> 
>> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26292#pullrequestreview-3018076292

From jlahoda at openjdk.org  Tue Jul 15 06:16:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Jul 2025 06:16:49 GMT
Subject: Integrated: 8362116: System.in.read() etc. don't accept input once
 immediate Ctrl+D pressed in JShell
In-Reply-To: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
References: <guIJjc7eUoSS5Im1rORYdUV6AcdToeP2tsuqZl5OJpA=.10cb4ef1-a0c2-489b-95d4-bdb7c59b2fbb@github.com>
Message-ID: <Ip1SOEKW09BvHD5MUeim-_VQjRNXSM5r3oJswFO1Auc=.c2830a59-ea8f-40b1-b034-82001592e51a@github.com>

On Mon, 14 Jul 2025 12:48:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When in JShell, doing:
> 
> jshell> IO.readln();
> //Ctrl-D
> $1 ==> null
> 
> jshell> IO.readln()
> $2 ==> null //no input allowed
> 
> 
> Where relying input from the main process to the remote/agent process, need to propagate `-1` as `-1` without close, which is what this PR is attempting to do.

This pull request has now been integrated.

Changeset: 40d159d4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40d159d4a9718d8db0aadf66b322583cd5246d0c
Stats:     85 lines in 6 files changed: 79 ins; 1 del; 5 mod

8362116: System.in.read() etc. don't accept input once immediate Ctrl+D pressed in JShell

Reviewed-by: liach, cstein

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

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

From jlahoda at openjdk.org  Tue Jul 15 06:29:38 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Jul 2025 06:29:38 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <dG7hgPRXXcJFrhc5DSjunpSZY_QbgDD1VGelBbvNFyo=.ef1a0ab5-4a61-4f7c-b3f1-2b1d00faeb1f@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Looks good to me, although additional review from core libs might be desirable. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26273#pullrequestreview-3018857714

From abimpoudis at openjdk.org  Tue Jul 15 08:30:59 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 15 Jul 2025 08:30:59 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v19]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <V1OmOWD_jdKy1gV3iWTN8Hf3i1fOh2KgYWADTn24nWw=.830b282f-1578-4975-9b45-a02bf896c941@github.com>

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

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

  Apply suggestions from Maurizios code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/a39bad3a..2d3449f7

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

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

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

From mcimadamore at openjdk.org  Tue Jul 15 08:30:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Jul 2025 08:30:59 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v19]
In-Reply-To: <V1OmOWD_jdKy1gV3iWTN8Hf3i1fOh2KgYWADTn24nWw=.830b282f-1578-4975-9b45-a02bf896c941@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <V1OmOWD_jdKy1gV3iWTN8Hf3i1fOh2KgYWADTn24nWw=.830b282f-1578-4975-9b45-a02bf896c941@github.com>
Message-ID: <p07bDWlT5I2KmmyGDwndsmh50ZOFSHQtUrSaacYTbRA=.52d0760e-d702-49d5-83d8-f655f4daf466@github.com>

On Tue, 15 Jul 2025 08:28:32 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
>> 
>> Briefly:
>> 
>> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
>> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
>> 
>> Semi-formally: 
>> 
>> - A type reference is simple name `R`:
>> 
>>   - `R` is a non-inner class type, nothing to do
>>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
>> 
>> - A type reference is a qualified name `Q.R`
>>   
>>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
>> 
>> 
>> 
>> // example 1
>> static class Usage1<T, G extends Getters<T>> {
>>   public T test(G.Getter getter) {
>>       return getter.get();
>>   }
>> }
>> 
>> // example 2
>> class A<T> {
>>   protected class B<V> {}
>> 
>>   public static <T, M extends A<T>> void f(Object g) {
>>     @SuppressWarnings("unchecked")
>>     M.B<?> mapping = (M.B<?>) g;
>>   }
>> }
>> 
>> // example 3
>> class A<T> {
>>     class B<W> {
>>         public T rett() { return null; }
>>     }
>> }
>> 
>> class C extends A<String> {
>>     static class D {
>>         {
>>             B<?> b = null;
>>             String s = b.rett();
>>         }
>>     }
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from Maurizios code review
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-3019292265

From cstein at openjdk.org  Tue Jul 15 12:28:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Jul 2025 12:28:20 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when exception
 without stack trace is thrown
Message-ID: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>

Please review this change introducing a range check before pruning
stacktrace elements in source launch mode. An additional `null`-check
was also added to this change set.

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

Commit messages:
 - 8362237: IllegalArgumentException in the launcher when exception without stack trace is thrown

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

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

From cstein at openjdk.org  Tue Jul 15 12:48:43 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Jul 2025 12:48:43 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown
In-Reply-To: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
Message-ID: <B7A9xBhQ8UziMHT_3quGGOHSItdrpARKQrlEPtifEKg=.6996ba63-0fff-489a-bc18-926701ebe897@github.com>

On Tue, 15 Jul 2025 12:20:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change introducing a range check before pruning
> stacktrace elements in source launch mode. An additional `null`-check
> was also added to this change set.

I wonder when and why the exception-handling code moved from `InvocationTargetException::getTargetException` to `InvocationTargetException::getCause`? ?

Ah, API documentation of [InvocationTargetException](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/InvocationTargetException.html#getTargetException()) to the rescue:

> API Note:
This method predates the general-purpose exception chaining facility. The [Throwable.getCause()](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Throwable.html#getCause()) method is now the preferred means of obtaining this information.

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

PR Comment: https://git.openjdk.org/jdk/pull/26315#issuecomment-3073464713

From alanb at openjdk.org  Tue Jul 15 13:31:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:31:51 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/lang/System.java line 244:

> 242:      *
> 243:      * @return  The system console, if any, otherwise {@code null}.
> 244:      * @see Console

The method declaration already links to Console so I don't think we need another link in the "See also" section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207473872

From alanb at openjdk.org  Tue Jul 15 13:31:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:31:51 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
Message-ID: <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>

On Tue, 15 Jul 2025 13:25:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 244:
> 
>> 242:      *
>> 243:      * @return  The system console, if any, otherwise {@code null}.
>> 244:      * @see Console
> 
> The method declaration already links to Console so I don't think we need another link in the "See also" section.

Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207483449

From sherman at openjdk.org  Tue Jul 15 14:35:42 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 14:35:42 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
 <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
Message-ID: <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>

On Tue, 15 Jul 2025 13:29:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 244:
>> 
>>> 242:      *
>>> 243:      * @return  The system console, if any, otherwise {@code null}.
>>> 244:      * @see Console
>> 
>> The method declaration already links to Console so I don't think we need another link in the "See also" section.
>
> Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?

we do have wordings like " If the virtual machine is started from an interactive command line without redirecting the standard input AND output streams then its console will exist ..." and "If no console device is
available then an invocation of that method will return <tt>null</tt>" from the very beginning. not very "straightforward" but i think it's clear enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207686213

From naoto at openjdk.org  Tue Jul 15 16:28:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 16:28:48 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
 <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
 <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>
Message-ID: <2tLfcUvYvIIVvxNIZPUkRT-hVw9a4Ew1J-Vf4jNEmhQ=.23dd367a-2b1d-4934-8381-c38313ed097f@github.com>

On Tue, 15 Jul 2025 14:31:45 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?
>
> we do have wordings like " If the virtual machine is started from an interactive command line without redirecting the standard input AND output streams then its console will exist ..." and "If no console device is
> available then an invocation of that method will return <tt>null</tt>" from the very beginning. not very "straightforward" but i think it's clear enough?

I think adding `@see` tag would be more helpful.

As to the spec wording wrt stdin/out, there is another issue filed to make it clearer: JDK-8361972. This PR addresses the implementation part only so that it can be backported to prior LTSes without spec change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207973733

From duke at openjdk.org  Tue Jul 15 21:48:41 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 15 Jul 2025 21:48:41 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown
In-Reply-To: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
Message-ID: <NYtR2zEO6P0j4I4TE0enP2O_3rq1ctjWmfeHEw5vMuk=.34089c67-4e80-43b1-a351-86eb7278d5ad@github.com>

On Tue, 15 Jul 2025 12:20:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change introducing a range check before pruning
> stacktrace elements in source launch mode. An additional `null`-check
> was also added to this change set.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 266:

> 264:             Throwable cause = exception.getCause();
> 265:             if (cause == null) throw exception;
> 266:             StackTraceElement[] elements = cause.getStackTrace();

Note?that `Throwable?::getStackTrace()` is?not?`final`, so?it?can?be?made to?return?`null` by?overriding.
Suggestion:

            StackTraceElement[] elements = cause.getStackTrace();
            if (elements == null) throw exception;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26315#discussion_r2208772126

From kcr at openjdk.org  Tue Jul 15 22:51:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 22:51:38 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown
In-Reply-To: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
Message-ID: <z9duVjbUvjFtmlpuH0tc6g7Sgjnz5M-mYSajOVAkoTU=.d82e98fd-d8c5-4ad8-a55f-4e5e32d9ef7e@github.com>

On Tue, 15 Jul 2025 12:20:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change introducing a range check before pruning
> stacktrace elements in source launch mode. An additional `null`-check
> was also added to this change set.

Looks good to me. I confirm that this also fixes [JDK-8314756](https://bugs.openjdk.org/browse/JDK-8314756). That bug can probably be closed as a duplicate of this one, JDK-8362237.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/26315#pullrequestreview-3022557559

From mcimadamore at openjdk.org  Wed Jul 16 09:57:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Jul 2025 09:57:45 GMT
Subject: Integrated: 8361401: Warnings for use of Sun APIs should not be
 mandatory
In-Reply-To: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
References: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
Message-ID: <Jv-n_E2pLGTi-DWzmqgZO578zu_1Hv91JMhwjyr5FYQ=.b4a84986-54de-4fac-9f03-d90b6da19734@github.com>

On Fri, 4 Jul 2025 10:57:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:
> 
> * warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
> * warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)
> 
> The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.
> 
> This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.
> 
> I've tweaked an existing test to check the kind of the Sun API warnings.

This pull request has now been integrated.

Changeset: b787ad6f
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b787ad6f690df5c82a1efc5ccac658a9238ff201
Stats:     69 lines in 6 files changed: 38 ins; 16 del; 15 mod

8361401: Warnings for use of Sun APIs should not be mandatory

Reviewed-by: jlahoda, vromero

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

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

From abimpoudis at openjdk.org  Wed Jul 16 10:55:49 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 16 Jul 2025 10:55:49 GMT
Subject: Integrated: 8357653: Inner classes of type parameters emitted as raw
 types in signatures
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <riRv4IkeIpwoV5niAFfhTj5R70V8BcHNpOQ2xFH6nm4=.eb438d7a-5759-4e82-8f42-6aa5759b5d1c@github.com>

On Mon, 26 May 2025 15:51:06 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> There are various occasions that the qualifier of an _inner type_ needs to be normalized. 
> 
> Briefly:
> 
> - This occurs when there is an explicit type application in the signature of the method or a type application operation or when type checking an expression operation (e.g., `G.Getter` in the first example, `M.B<?>` in the second example). 
> - The reference to an inner type may not be explicitly qualified (e.g., `B<?>` which is not qualified but its type needs be calculated as seen from `A<String>.B<?>`).
> 
> Semi-formally: 
> 
> - A type reference is simple name `R`:
> 
>   - `R` is a non-inner class type, nothing to do
>   - `R` is an inner class type, we need to find an implicit type qualifier `S<T>.R`, where `S` is the class in which `R` is enclosed
>   - `R` is an array type `A[]`, repeat the analysis for the simple type name `A`, and then use the implicit type qualifier to rewrite the array
> 
> - A type reference is a qualified name `Q.R`
>   
>   - find the supertype of `Q`, namely `S<T>`, where `S` is the class in which `R` is enclosed
> 
> 
> 
> // example 1
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> // example 2
> class A<T> {
>   protected class B<V> {}
> 
>   public static <T, M extends A<T>> void f(Object g) {
>     @SuppressWarnings("unchecked")
>     M.B<?> mapping = (M.B<?>) g;
>   }
> }
> 
> // example 3
> class A<T> {
>     class B<W> {
>         public T rett() { return null; }
>     }
> }
> 
> class C extends A<String> {
>     static class D {
>         {
>             B<?> b = null;
>             String s = b.rett();
>         }
>     }
> }

This pull request has now been integrated.

Changeset: 5e4a2ead
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e4a2ead714814cb4eb90ca88debc226f9c75864
Stats:     452 lines in 5 files changed: 399 ins; 28 del; 25 mod

8357653: Inner classes of type parameters emitted as raw types in signatures
8357472: NPE in Types.containsType for type variable used as a qualifier

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, vromero, liach

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

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

From cstein at openjdk.org  Wed Jul 16 17:41:27 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Jul 2025 17:41:27 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown [v2]
In-Reply-To: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
Message-ID: <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>

> Please review this change introducing a range check before pruning
> stacktrace elements in source launch mode. An additional `null`-check
> was also added to this change set.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add null checks for getStackTrace() results

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26315/files
  - new: https://git.openjdk.org/jdk/pull/26315/files/199dc7e0..c7d4bbf9

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

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

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

From cstein at openjdk.org  Wed Jul 16 17:41:28 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Jul 2025 17:41:28 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown [v2]
In-Reply-To: <NYtR2zEO6P0j4I4TE0enP2O_3rq1ctjWmfeHEw5vMuk=.34089c67-4e80-43b1-a351-86eb7278d5ad@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
 <NYtR2zEO6P0j4I4TE0enP2O_3rq1ctjWmfeHEw5vMuk=.34089c67-4e80-43b1-a351-86eb7278d5ad@github.com>
Message-ID: <ypw3deIui1eK3WJvHn6XEOabVt9swVb3ms3Xrf_bz_c=.d33dd1bf-3f77-4d03-aa93-591ed8f8a7eb@github.com>

On Tue, 15 Jul 2025 21:45:15 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null checks for getStackTrace() results
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 266:
> 
>> 264:             Throwable cause = exception.getCause();
>> 265:             if (cause == null) throw exception;
>> 266:             StackTraceElement[] elements = cause.getStackTrace();
> 
> Note?that `Throwable?::getStackTrace()` is?not?`final`, so?it?can?be?made to?return?`null` by?overriding.
> Suggestion:
> 
>             StackTraceElement[] elements = cause.getStackTrace();
>             if (elements == null) throw exception;

Thanks for the suggestion. I added this and another null check in https://github.com/openjdk/jdk/pull/26315/commits/c7d4bbf9eba2b24bf8f15272024a74caa4ef0faa

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26315#discussion_r2211084212

From kcr at openjdk.org  Wed Jul 16 18:21:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Jul 2025 18:21:39 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown [v2]
In-Reply-To: <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
 <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
Message-ID: <Gmrmq9ZOaycgMv0q_HZpAIg7pdBPtCcRKs8FFEw4dSQ=.14140924-6eda-4e19-9c2f-23250370b236@github.com>

On Wed, 16 Jul 2025 17:41:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change introducing a range check before pruning
>> stacktrace elements in source launch mode. Additional `null`-checks
>> are also added to this change set.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null checks for getStackTrace() results

Null checks look good.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/26315#pullrequestreview-3026307230

From jpai at openjdk.org  Thu Jul 17 09:10:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 09:10:48 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <Y5KgALU_xIs40qkrtuGTXa6uaoL5jnzFSdfP5j2kad4=.783539e5-73e8-4895-9fb4-5bec92d8524c@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3028640169

From vromero at openjdk.org  Thu Jul 17 10:40:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Jul 2025 10:40:48 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown [v2]
In-Reply-To: <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
 <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
Message-ID: <LwoeDnARpLCPcc5mq25lwo7vs8wv78Y207YwekD9ZL4=.b28890c5-c3e7-4b93-bdfb-cbb18aced2ba@github.com>

On Wed, 16 Jul 2025 17:41:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change introducing a range check before pruning
>> stacktrace elements in source launch mode. Additional `null`-checks
>> are also added to this change set.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null checks for getStackTrace() results

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26315#pullrequestreview-3028957120

From duke at openjdk.org  Thu Jul 17 11:07:55 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 17 Jul 2025 11:07:55 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown [v2]
In-Reply-To: <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
 <Br0lKqW9P45MLZELuodgY3pKBK9Tdh4MTpDp1dgNYIw=.684595dd-2b49-4529-983c-384631d03063@github.com>
Message-ID: <EeABFTByl47ltg3n_OnICwSOC0Fh6x_YmzFF53Xlc7E=.48c20276-077b-4c75-b541-169c3e280859@github.com>

On Wed, 16 Jul 2025 17:41:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change introducing a range check before pruning
>> stacktrace elements in source launch mode. Additional `null`-checks
>> are also added to this change set.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null checks for getStackTrace() results

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 265:

> 263:             // remove stack frames for source launcher
> 264:             StackTraceElement[] invocationElements = exception.getStackTrace();
> 265:             if (invocationElements == null) throw exception;

`invocationElements` can?t?be?`null`, as?the?`InvocationTargetException` is?thrown by?the?reflection implementation:
https://github.com/openjdk/jdk/blob/3fd89be6d1a51b6fc99f4c0b5daba7a4bd64a08e/src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java#L103-L120

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26315#discussion_r2213038398

From asotona at openjdk.org  Thu Jul 17 11:59:49 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 17 Jul 2025 11:59:49 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v2]
In-Reply-To: <mmpaUfANdsNA7aAEhRD60pGMonEDxKxcAGlByNOW9us=.c447420e-8f21-4d55-8b8c-fda1e6ba6fb7@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
 <mmpaUfANdsNA7aAEhRD60pGMonEDxKxcAGlByNOW9us=.c447420e-8f21-4d55-8b8c-fda1e6ba6fb7@github.com>
Message-ID: <UMGquf4ZdJD8qLhaxzZNK-7OrEFlqE4k0Dj6hLAi5UY=.20c174d3-bad3-4312-b611-7592ee3f8790@github.com>

On Mon, 7 Jul 2025 13:05:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
>> 
>> There are two problems with this background task:
>> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
>> - the module path is not included in the list of paths to paths to search
>> 
>> This PR proposes to:
>> - use FileManager configured by passing the compile options through javac
>> - include the module path in the search path
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding problems with locked files on Windows.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26137#pullrequestreview-3029214655

From acobbs at openjdk.org  Thu Jul 17 17:08:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 17 Jul 2025 17:08:01 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
Message-ID: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>

The fix for [JDK-8359493](https://bugs.openjdk.org/browse/JDK-8359493) added the ability to associate `DiagnosticFlag`'s to specific warnings at the point of definition in `compiler.properties`. In cases where the flag is an inherent property of the warning itself, `compiler.properties` is a more appropriate place to declare it, instead of having to add it at all the points in the codebase where that particular warning is used.

In particular, the Log API methods `mandatoryWarning()` and `mandatoryNote()` can be removed, as they serve only to add the `MANDATORY` flag to warnings and notes for which "mandatoryness" is inherent. Doing so should help decomplexify the code a bit.

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

Commit messages:
 - Merge branch 'master' into JDK-8361424
 - Eliminate Log.mandatoryNote() and add MANDATORY flags to compiler.properties.
 - Eliminate Log.mandatoryWarning() and add MANDATORY flags to compiler.properties.
 - Remove Log::strictWarning
 - Merge with latest compiler changes
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/26138/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361424
  Stats: 103 lines in 9 files changed: 8 ins; 48 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/26138.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26138/head:pull/26138

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

From mcimadamore at openjdk.org  Thu Jul 17 18:27:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Jul 2025 18:27:48 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
Message-ID: <WIc3bBSww_Y7TSaVue8ukOjB2L_i7S9VgaUwOVvnyek=.a73cea9a-902d-4455-b501-fe22d59e0732@github.com>

On Fri, 4 Jul 2025 18:24:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The fix for [JDK-8359493](https://bugs.openjdk.org/browse/JDK-8359493) added the ability to associate `DiagnosticFlag`'s to specific warnings at the point of definition in `compiler.properties`. In cases where the flag is an inherent property of the warning itself, `compiler.properties` is a more appropriate place to declare it, instead of having to add it at all the points in the codebase where that particular warning is used.
> 
> In particular, the Log API methods `mandatoryWarning()` and `mandatoryNote()` can be removed, as they serve only to add the `MANDATORY` flag to warnings and notes for which "mandatoryness" is inherent. Doing so should help decomplexify the code a bit.

The change looks great -- but I don't buy the changes in `AbstractLog` -- don't we need methods that take a varargs of flags (instead of just one) ? It's ok if we want to special case for the common case where there's just one, but restricting the API to only take one seems limiting (when in fact we already use multiple flags in compiler properties)

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

PR Review: https://git.openjdk.org/jdk/pull/26138#pullrequestreview-3030571629

From acobbs at openjdk.org  Thu Jul 17 18:36:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 17 Jul 2025 18:36:52 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <WIc3bBSww_Y7TSaVue8ukOjB2L_i7S9VgaUwOVvnyek=.a73cea9a-902d-4455-b501-fe22d59e0732@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
 <WIc3bBSww_Y7TSaVue8ukOjB2L_i7S9VgaUwOVvnyek=.a73cea9a-902d-4455-b501-fe22d59e0732@github.com>
Message-ID: <YdC7ut3lnILyl2lwb-jdL6aolHmy0mDAsi9asqQgueY=.3cdb4832-1180-4bbd-a7a9-7c5229d3bb62@github.com>

On Thu, 17 Jul 2025 18:24:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The change looks great -- but I don't buy the changes in `AbstractLog` -- don't we need methods that take a varargs of flags (instead of just one) ? It's ok if we want to special case for the common case where there's just one, but restricting the API to only take one seems limiting (when in fact we already use multiple flags in compiler properties)

I agree with you in principle; the "only one flag" design choice was [already in place](https://github.com/openjdk/jdk/blob/347084bfbdbf048cd50c0e13e43ae53f6da77e6e/src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java#L124), so this was just trying to stay consistent with the existing code.

Assuming you think this is an appropriate opportunity to correct that minor design deficiency, I can work on updating the patch accordingly.

Thanks for taking a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/26138#issuecomment-3085047936

From acobbs at openjdk.org  Thu Jul 17 18:42:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 17 Jul 2025 18:42:36 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v2]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <4fsbORe6HMABvncq0SCmCH2if4qdoonHeR7Ny3CODWY=.fe7838da-e648-44ff-a4ca-18617d48fec3@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 87 commits:

 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Merge branch 'master' into MandatoryWarningCleanup
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - ... and 77 more: https://git.openjdk.org/jdk/compare/a65d9532...9432be0d

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

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=01
  Stats: 2000 lines in 57 files changed: 1064 ins; 587 del; 349 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From liach at openjdk.org  Thu Jul 17 19:07:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 19:07:32 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v7]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <V4ikyLrr4JkS2tuE46GnTSsmI2g_dRR6b73da_4i13Q=.4c0677da-afb3-4be5-b1b2-97223069655e@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

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

 - Fix sourceversion test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512
 - ... and 2 more: https://git.openjdk.org/jdk/compare/bd55d7a4...0f9c501c

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=06
  Stats: 1279 lines in 6 files changed: 1137 ins; 83 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From liach at openjdk.org  Thu Jul 17 19:13:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 19:13:12 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v8]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <uAQ8Ruh85CVDpj_pUznOWUA0H4FvKxjonlPGdWJgjW8=.a6d8d624-3143-4058-8871-72cba950540a@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/0f9c501c..b39504fc

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

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

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

From mcimadamore at openjdk.org  Thu Jul 17 21:45:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Jul 2025 21:45:48 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
Message-ID: <3i5l197juwsP0yqKfvuE6RJKLXXwj3TzaAG_n4MfPrg=.97a44a36-a312-4057-abb2-634b767c057a@github.com>

On Fri, 4 Jul 2025 18:24:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The fix for [JDK-8359493](https://bugs.openjdk.org/browse/JDK-8359493) added the ability to associate `DiagnosticFlag`'s to specific warnings at the point of definition in `compiler.properties`. In cases where the flag is an inherent property of the warning itself, `compiler.properties` is a more appropriate place to declare it, instead of having to add it at all the points in the codebase where that particular warning is used.
> 
> In particular, the Log API methods `mandatoryWarning()` and `mandatoryNote()` can be removed, as they serve only to add the `MANDATORY` flag to warnings and notes for which "mandatoryness" is inherent. Doing so should help decomplexify the code a bit.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26138#pullrequestreview-3031120708

From mcimadamore at openjdk.org  Thu Jul 17 21:45:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Jul 2025 21:45:49 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <YdC7ut3lnILyl2lwb-jdL6aolHmy0mDAsi9asqQgueY=.3cdb4832-1180-4bbd-a7a9-7c5229d3bb62@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
 <WIc3bBSww_Y7TSaVue8ukOjB2L_i7S9VgaUwOVvnyek=.a73cea9a-902d-4455-b501-fe22d59e0732@github.com>
 <YdC7ut3lnILyl2lwb-jdL6aolHmy0mDAsi9asqQgueY=.3cdb4832-1180-4bbd-a7a9-7c5229d3bb62@github.com>
Message-ID: <tmVl4wQVCELUGxjOMcwdtj4gwzpiEnwTVha15x9bZq0=.9ca4d6ae-44e5-47a2-b43c-fa72dfed3d28@github.com>

On Thu, 17 Jul 2025 18:34:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I agree with you in principle; the "only one flag" design choice was [already in place](https://github.com/openjdk/jdk/blob/347084bfbdbf048cd50c0e13e43ae53f6da77e6e/src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java#L124)

You are actually correct, I made confusion with the duplicated factories under DiagnosticFactory, some of those do take an enumset of flags.

So, if I'm correct, this patch only adds some missing factories to warning/note, right? If so, good. We can revisit the number of factories as a separate cleanup (I'm not too proud also of the duplication in DiagnosticFactory, which predate the whole `DiagnosticInfo` stuff. But a problem for another day.

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

PR Comment: https://git.openjdk.org/jdk/pull/26138#issuecomment-3085612912

From acobbs at openjdk.org  Fri Jul 18 01:46:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 18 Jul 2025 01:46:52 GMT
Subject: RFR: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <tmVl4wQVCELUGxjOMcwdtj4gwzpiEnwTVha15x9bZq0=.9ca4d6ae-44e5-47a2-b43c-fa72dfed3d28@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
 <WIc3bBSww_Y7TSaVue8ukOjB2L_i7S9VgaUwOVvnyek=.a73cea9a-902d-4455-b501-fe22d59e0732@github.com>
 <YdC7ut3lnILyl2lwb-jdL6aolHmy0mDAsi9asqQgueY=.3cdb4832-1180-4bbd-a7a9-7c5229d3bb62@github.com>
 <tmVl4wQVCELUGxjOMcwdtj4gwzpiEnwTVha15x9bZq0=.9ca4d6ae-44e5-47a2-b43c-fa72dfed3d28@github.com>
Message-ID: <_bLIg1rgYr8g_aVFuofuwhBeqMRu78RzaYWB8zYmVE0=.9b5f083e-523f-4d06-ace7-f2a61140d91b@github.com>

On Thu, 17 Jul 2025 21:43:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, if I'm correct, this patch only adds some missing factories to warning/note, right?

Correct - while most of the `MANDATORY` flags can be moved to `compiler.resources`, not all can, and that means that we now need new overrides for `warning()` and `note()` that allow the caller to pass that flag.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26138#issuecomment-3086360318

From acobbs at openjdk.org  Fri Jul 18 01:46:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 18 Jul 2025 01:46:53 GMT
Subject: Integrated: 8361424: Eliminate Log methods mandatoryWarning() and
 mandatoryNote()
In-Reply-To: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
References: <5HlUy0a2vwfA7MGR6wKgTAzzytze8MsuVOtdfE4hlxU=.862ee2df-f3bd-4918-9d08-561b2816764b@github.com>
Message-ID: <dIGYLboqNBKuURW3lx6JYJDyFldWZ1ijS87RHH4vPMo=.c7455b7a-7a62-4fb7-8709-222fce8ef26a@github.com>

On Fri, 4 Jul 2025 18:24:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The fix for [JDK-8359493](https://bugs.openjdk.org/browse/JDK-8359493) added the ability to associate `DiagnosticFlag`'s to specific warnings at the point of definition in `compiler.properties`. In cases where the flag is an inherent property of the warning itself, `compiler.properties` is a more appropriate place to declare it, instead of having to add it at all the points in the codebase where that particular warning is used.
> 
> In particular, the Log API methods `mandatoryWarning()` and `mandatoryNote()` can be removed, as they serve only to add the `MANDATORY` flag to warnings and notes for which "mandatoryness" is inherent. Doing so should help decomplexify the code a bit.

This pull request has now been integrated.

Changeset: cab51596
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cab515962b6940b50b975b12c8f5e99d0430f694
Stats:     103 lines in 9 files changed: 8 ins; 48 del; 47 mod

8361424: Eliminate Log methods mandatoryWarning() and mandatoryNote()

Reviewed-by: mcimadamore

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

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

From nlisker at gmail.com  Sat Jul 19 16:28:43 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 19 Jul 2025 19:28:43 +0300
Subject: Possible bug with multiple generic bounds
Message-ID: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>

Hello,

Initially reported in the Eclipse compiler since ECJ accepts code that
javac does not: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4226.
The current assessment is that the fault is with javac.

Copying the example from there:

```
interface Culprit {}

class EntityInfo<E extends NumberGenerator<?> & Culprit> {}

class NumberGenerator<N extends Number> implements NumberSupplier<N> {

@Override
    public N getNumber() {
        return null;
    }
}

interface NumberSupplier<N extends Number>  {

    N getNumber();
}
```

javac fails with:
```
error: getNumber() in NumberGenerator cannot implement getNumber() in
NumberSupplier
class EntityInfo<E extends NumberGenerator<?> & Culprit> {}
                 ^
  return type CAP#1 is not compatible with CAP#2
  where N#1,N#2 are type-variables:
    N#1 extends Number declared in class NumberGenerator
    N#2 extends Number declared in interface NumberSupplier
  where CAP#1,CAP#2 are fresh type-variables:
    CAP#1 extends Number from capture of ?
    CAP#2 extends Number from capture of ?
1 error
```

Removing the Culprit bound:
class EntityInfo<E extends NumberGenerator<?>> {}

satisfies javac.

Also noted that combining the supertypes explicitly is accepted:
```
class X<T extends Number> extends NumberGenerator<T> implements Culprit {
}

class EI2<E extends X<?>> {}
```

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250719/088daef8/attachment.htm>

From acobbs at openjdk.org  Sun Jul 20 20:39:07 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 20 Jul 2025 20:39:07 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:

 - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Merge branch 'master' into MandatoryWarningCleanup
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - ... and 79 more: https://git.openjdk.org/jdk/compare/cab51596...91202f7b

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

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=02
  Stats: 1997 lines in 56 files changed: 1052 ins; 586 del; 359 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From jlahoda at openjdk.org  Wed Jul 23 15:01:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Jul 2025 15:01:08 GMT
Subject: RFR: 8359497: IllegalArgumentException thrown by
 SourceCodeAnalysisImpl.highlights()
Message-ID: <FGgeVak7OLd0F3KE_n6y8nSdb0oIXIX5LW7yhPC18k4=.485d5b87-6269-4a29-a5e3-5c2b24928a77@github.com>

When JShell computes highlights, it uses the javac' lexer to detect keywords. But, if there's a lexical error in the input, the lexer will try to report an error, but that will with an exception, as there's no input file set. This PR:
- sets a source to `Log` so that the attempt to report the error will not fail
- sets a `DiagnosticListener` so that the error is ignored (as the error is not important, this lexer is only used to detect keyword).

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

Commit messages:
 - Cleanup.
 - 8359497: IllegalArgumentException thrown by SourceCodeAnalysisImpl.highlights()

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

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

From jlahoda at openjdk.org  Thu Jul 24 07:28:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Jul 2025 07:28:59 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong to a
 specific Symbol type only
Message-ID: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>

This PR proposes to improve handling of javac's `Flags` in two ways:
- for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
- the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`

This is inspired by:
https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662

There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.

As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.

(I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

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

Commit messages:
 - Fixing tests.
 - 8362885: A more formal way to mark javac's Flags that belong to a specific Symbol type only

Changes: https://git.openjdk.org/jdk/pull/26452/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362885
  Stats: 454 lines in 8 files changed: 327 ins; 81 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/26452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26452/head:pull/26452

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

From duke at openjdk.org  Thu Jul 24 14:59:31 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 24 Jul 2025 14:59:31 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
Message-ID: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>

Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.


if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
    throw new Exception("exceeding length");
}


Is a CSR required to this change?

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

Commit messages:
 - Remove trailing spaces
 - 8364007: Add overload without arguments to codePointCount in String etc.

Changes: https://git.openjdk.org/jdk/pull/26461/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364007
  Stats: 112 lines in 13 files changed: 95 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461

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

From rriggs at openjdk.org  Thu Jul 24 15:15:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 15:15:01 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.
Putting the effort into a PR before there is some agreement on the value is premature.
And yes, every change to the spec needs a CSR.

To keep the proposal focused on the APIs, please drop the changes to modules other than java.base.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3113849427
PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3113856629

From acobbs at openjdk.org  Thu Jul 24 15:27:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 24 Jul 2025 15:27:54 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <E8K1r-dCvSlcTTBL0mVATdutXETlI9on-ulUUqzzSZ0=.e2786e37-0665-4de2-abb5-24a7e17ff4d6@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

This looks like a really nice improvement for maintainability.

**?** Would it make more sense (and/or be simpler?) to move the conflict-checking logic into `FlagsGenerator`?

It somehow seems odd to have a tool which can knowingly generate an invalid `FlagsEnum.java` file... and then defer the check for that until later, maybe, in a unit test... when we could just make the build fail instead.

**?** Is it worth adding some simple runtime check for correct `FlagTarget` usage?

For example (just brainstorming):
* For each `FlagTarget` have `FlagsGenerator` output e.g. `public static final long METHOD_FLAGS = 0x0301930420520017L;`
* At appropriate location(s) in the code, add `Assert.check(this.flags_field & ~METHOD_FLAGS) == 0);`

(Of course even better would be to check this at compile time using stronger typing (e.g., by replacing `long flags_field` with some `EnumSet`, etc.) but that's probably way beyond this first step.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3113908635

From liach at openjdk.org  Thu Jul 24 16:24:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 16:24:55 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Also, do we need `codePointCount` on `CharSequence`?

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 545:

> 543:         byte[] value = this.value;
> 544:         if (isLatin1(coder)) {
> 545:             return value.length;

Suggestion:

            return count;

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

PR Review: https://git.openjdk.org/jdk/pull/26461#pullrequestreview-3052346769
PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2228974436

From liach at openjdk.org  Thu Jul 24 18:19:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 18:19:54 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <2ak5PqNYshNSI8EZa9Jzonz1HoQ5QCmkySyLgB8KsuM=.67713d85-ebe7-49ad-91c1-c3bf31a87e80@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 85:

> 83:             try (PrintWriter out = new PrintWriter(Files.newBufferedWriter(Paths.get(args[1])))) {
> 84:                 out.println("""
> 85:                             package com.sun.tools.javac.code;

Do we need a license header for generated sources?

test/langtools/tools/javac/flags/FlagsTest.java line 102:

> 100:     private static void printFreeFlags(String comment, long freeFlags) {
> 101:             System.err.print("free flags for " + comment + ": ");
> 102:             for (int bit = 16; bit < 64; bit++) { //lowest 16 bits are used in classfiles, never suggest adding anything there

Replace 16 with Character.SIZE and 64 with Long.SIZE?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2229222407
PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2229216762

From duke at openjdk.org  Thu Jul 24 18:48:59 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 24 Jul 2025 18:48:59 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <bmNLkztYTmrgcA-381q72DuKEGooSED04KBK_2HZncs=.6f0496a4-a501-435f-9818-647f5af97c66@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

test/langtools/tools/javac/flags/FlagsTest.java line 53:

> 51: 
> 52:     private static void verifyFlagsNonOverlapping() throws Throwable {
> 53:         Map<FlagTarget, Map<Long, List<Field>>> target2Flag2Fields = computeTarget2Flag2Fields();

You could calculate this once in main and pass to `verifyFlagNonOverlapping` and `findFreeFlags`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2229291335

From myankelevich at openjdk.org  Thu Jul 24 21:53:54 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Jul 2025 21:53:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Could you please add a bug number under `@bug`?

test/jdk/java/lang/StringBuilder/Supplementary.java line 216:

> 214:         testAppendCodePoint(Character.MAX_CODE_POINT+1, IllegalArgumentException.class);
> 215:     }
> 216: 

nit, as the other copyrights are updated: 

* Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.

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

PR Review: https://git.openjdk.org/jdk/pull/26461#pullrequestreview-3053452383
PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2229652045

From myankelevich at openjdk.org  Thu Jul 24 22:09:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Jul 2025 22:09:56 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

src/java.base/share/classes/java/lang/Character.java line 9969:

> 9967:         int n = length;
> 9968:         for (int i = 0; i < length; ) {
> 9969:             if (isHighSurrogate(seq.charAt(i++)) && i < length &&

Imo this is quite hard to read, especially with `i++` inside of the if statement. What do you think about changing it to this? 
```java 
for (int i = 0; i < length; i++) {
    if (isHighSurrogate(seq.charAt(i)) && 
         i+1 < length && 
         isLowSurrogate(seq.charAt(i+1))) {

         n--;
         i++;
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2229676944

From achung at openjdk.org  Fri Jul 25 00:29:13 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 25 Jul 2025 00:29:13 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
Message-ID: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

Commit messages:
 - update l10n

Changes: https://git.openjdk.org/jdk/pull/26467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364089
  Stats: 90 lines in 14 files changed: 71 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26467/head:pull/26467

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

From mcimadamore at openjdk.org  Fri Jul 25 09:22:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Jul 2025 09:22:58 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <bt_1FDv0NvXUl5pxnKZqGSbHHu95dvlRUSAjW65EUZI=.5ef85765-fd6b-4795-b9cf-6af47a29df35@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 127:

> 125:     // for example.
> 126:     @NotFlag
> 127:     public static final int ACC_SUPER    = 0x0020;

Why didn't we add annotation on these ACC ones? After all, they _also_ overlap with previous flags -- e.g. ACC_SUPER overlaps with SYNCHRONIZED, and it works because the former goes on types and the latter on methods. So, isn't this the same trick we're pulling?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2230609597

From jlahoda at openjdk.org  Fri Jul 25 13:38:38 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Jul 2025 13:38:38 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Fixing toString value for flags that have ACC_ overloaded flags.
 - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
 - Reflecting review feedback:
   - when conflict is detected, the generator fails
   - adding runtime checks
   - using constants for number of bits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/0ab2ba48..e00209f0

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

  Stats: 199 lines in 5 files changed: 112 ins; 18 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/26452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26452/head:pull/26452

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

From jlahoda at openjdk.org  Fri Jul 25 13:45:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Jul 2025 13:45:59 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <2ak5PqNYshNSI8EZa9Jzonz1HoQ5QCmkySyLgB8KsuM=.67713d85-ebe7-49ad-91c1-c3bf31a87e80@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <2ak5PqNYshNSI8EZa9Jzonz1HoQ5QCmkySyLgB8KsuM=.67713d85-ebe7-49ad-91c1-c3bf31a87e80@github.com>
Message-ID: <jAn1fJ2hd1P7eUhP5G6nVWmI8AAvoSZCkPMaD0QAfw8=.a5c1ed41-3775-4497-82ba-31f29f8e366a@github.com>

On Thu, 24 Jul 2025 18:15:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> make/langtools/tools/flagsgenerator/FlagsGenerator.java line 85:
> 
>> 83:             try (PrintWriter out = new PrintWriter(Files.newBufferedWriter(Paths.get(args[1])))) {
>> 84:                 out.println("""
>> 85:                             package com.sun.tools.javac.code;
> 
> Do we need a license header for generated sources?

`CompilerProperties` and other files that are generated using similar means don't have license headers, so I assume we don't need that.

> test/langtools/tools/javac/flags/FlagsTest.java line 102:
> 
>> 100:     private static void printFreeFlags(String comment, long freeFlags) {
>> 101:             System.err.print("free flags for " + comment + ": ");
>> 102:             for (int bit = 16; bit < 64; bit++) { //lowest 16 bits are used in classfiles, never suggest adding anything there
> 
> Replace 16 with Character.SIZE and 64 with Long.SIZE?

I don't think `Character.SIZE` is really appropriate, but I've declared `U2_SIZE` for `16`, and used `Long.SIZE` for `64`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231113665
PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231112402

From mcimadamore at openjdk.org  Fri Jul 25 13:46:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Jul 2025 13:46:00 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
Message-ID: <YPDp6eVSnqhGjto9M3YJyOK2FeDIV13H5hDAcVrmSvY=.344a3ebb-be26-4e45-bd69-09e03a7e6740@github.com>

On Fri, 25 Jul 2025 13:38:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fixing toString value for flags that have ACC_ overloaded flags.
>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>  - Reflecting review feedback:
>    - when conflict is detected, the generator fails
>    - adding runtime checks
>    - using constants for number of bits

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 169:

> 167:     }
> 168: 
> 169:     public enum FlagTarget {

Just flyby comment: symbol kind is an enum, so in _principle_ we could use constants such as MTH, VAR, TYP as targets, if we wanted to connect the decls more with the actual code. But I like your approach as well (as symbol kind has also a lot of other more dubious stuff/noise)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231123094

From jlahoda at openjdk.org  Fri Jul 25 13:46:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Jul 2025 13:46:02 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <bt_1FDv0NvXUl5pxnKZqGSbHHu95dvlRUSAjW65EUZI=.5ef85765-fd6b-4795-b9cf-6af47a29df35@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bt_1FDv0NvXUl5pxnKZqGSbHHu95dvlRUSAjW65EUZI=.5ef85765-fd6b-4795-b9cf-6af47a29df35@github.com>
Message-ID: <cdC0RDePnYH-WrowbSQM8j7Q3GHc04x2hZ1HterKln4=.2fddf1ae-0ab4-4af5-bbb1-383c9d79a8ba@github.com>

On Fri, 25 Jul 2025 09:20:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 127:
> 
>> 125:     // for example.
>> 126:     @NotFlag
>> 127:     public static final int ACC_SUPER    = 0x0020;
> 
> Why didn't we add annotation on these ACC ones? After all, they _also_ overlap with previous flags -- e.g. ACC_SUPER overlaps with SYNCHRONIZED, and it works because the former goes on types and the latter on methods. So, isn't this the same trick we're pulling?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231121152

From jlahoda at openjdk.org  Fri Jul 25 13:46:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Jul 2025 13:46:03 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <bmNLkztYTmrgcA-381q72DuKEGooSED04KBK_2HZncs=.6f0496a4-a501-435f-9818-647f5af97c66@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bmNLkztYTmrgcA-381q72DuKEGooSED04KBK_2HZncs=.6f0496a4-a501-435f-9818-647f5af97c66@github.com>
Message-ID: <vSc2N3w2XjA-oMgkP3jii0oWvudVQTjJUNUJPJiCwdg=.1b7ba9a7-c981-4ffa-bbb2-045e76a4a49f@github.com>

On Thu, 24 Jul 2025 18:45:55 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> test/langtools/tools/javac/flags/FlagsTest.java line 53:
> 
>> 51: 
>> 52:     private static void verifyFlagsNonOverlapping() throws Throwable {
>> 53:         Map<FlagTarget, Map<Long, List<Field>>> target2Flag2Fields = computeTarget2Flag2Fields();
> 
> You could calculate this once in main and pass to `verifyFlagNonOverlapping` and `findFreeFlags`

Given this is a test, I would prefer to keep the test cases separate. This is a bit moot now, as the test is no doing the verification anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231115685

From jlahoda at openjdk.org  Fri Jul 25 13:51:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Jul 2025 13:51:55 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only
In-Reply-To: <E8K1r-dCvSlcTTBL0mVATdutXETlI9on-ulUUqzzSZ0=.e2786e37-0665-4de2-abb5-24a7e17ff4d6@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <E8K1r-dCvSlcTTBL0mVATdutXETlI9on-ulUUqzzSZ0=.e2786e37-0665-4de2-abb5-24a7e17ff4d6@github.com>
Message-ID: <519I1doiu2I8eT9FpwUm2tk3ylb4kEfNG4tPV-yTc6w=.086eaaf4-2a58-474f-be5d-de01563f9670@github.com>

On Thu, 24 Jul 2025 15:25:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This looks like a really nice improvement for maintainability.
> 
> **?** Would it make more sense (and/or be simpler?) to move the conflict-checking logic into `FlagsGenerator`?
> 
> It somehow seems odd to have a tool which can knowingly generate an invalid `FlagsEnum.java` file... and then defer the check for that until later, maybe, in a unit test... when we could just make the build fail instead.
> 

Done.

> **?** Is it worth adding some simple runtime check for correct `FlagTarget` usage?
> 
> For example (just brainstorming):
> 
>     * For each `FlagTarget` have `FlagsGenerator` output e.g. `public static final long METHOD_FLAGS = 0x0301930420520017L;`
> 
>     * At appropriate location(s) in the code, add `Assert.check(this.flags_field & ~METHOD_FLAGS) == 0);`

I've added the checks. It may be useful, but it is somewhat limited, as it cannot detect the most dangerous case where the flag with overloaded meaning is set incorrectly.

> 
> 
> (Of course even better would be to check this at compile time using stronger typing (e.g., by replacing `long flags_field` with some `EnumSet`, etc.) but that's probably way beyond this first step.)

There were several experiments, in the past and currently ongoing, but it is difficult to do something that is safer and does not cost too much on performance/memory consumption. Value classes may or may not help.

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3117882238

From mcimadamore at openjdk.org  Fri Jul 25 13:51:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Jul 2025 13:51:57 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
Message-ID: <4lhZSr1C4R-fSlJOSEnVWYDzJqftlYv6nRbX_9-GhvU=.dc644bca-b9cd-4ae6-9473-8f749c4f46bd@github.com>

On Fri, 25 Jul 2025 13:38:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fixing toString value for flags that have ACC_ overloaded flags.
>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>  - Reflecting review feedback:
>    - when conflict is detected, the generator fails
>    - adding runtime checks
>    - using constants for number of bits

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2130:

> 2128: 
> 2129:     public void visitModuleDef(JCModuleDecl tree) {
> 2130:         FlagsEnum.assertNoUnexpectedFlags(tree.sym.flags_field,

Not super sure about rolling this into Lower... but a separate visitor will also look a bit "too much"...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231135323

From mcimadamore at openjdk.org  Fri Jul 25 13:51:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Jul 2025 13:51:57 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <4lhZSr1C4R-fSlJOSEnVWYDzJqftlYv6nRbX_9-GhvU=.dc644bca-b9cd-4ae6-9473-8f749c4f46bd@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
 <4lhZSr1C4R-fSlJOSEnVWYDzJqftlYv6nRbX_9-GhvU=.dc644bca-b9cd-4ae6-9473-8f749c4f46bd@github.com>
Message-ID: <X4Hc5--FLe1fjafgW1OqL60lzy9YUz0lEf5dQ-i6VMU=.08c07e54-c9d8-41b9-b1df-d7f15e848929@github.com>

On Fri, 25 Jul 2025 13:48:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2130:
> 
>> 2128: 
>> 2129:     public void visitModuleDef(JCModuleDecl tree) {
>> 2130:         FlagsEnum.assertNoUnexpectedFlags(tree.sym.flags_field,
> 
> Not super sure about rolling this into Lower... but a separate visitor will also look a bit "too much"...

For instance, for type variables there's no way to check them at this point?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2231136436

From mcimadamore at openjdk.org  Fri Jul 25 14:41:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Jul 2025 14:41:00 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
Message-ID: <kRmQfEMYYRS3APBZOFrDji7ybQp4BMtc6PRf5xhL_6E=.7642f5e4-bc8f-4292-8ea0-5c8918d9d919@github.com>

On Fri, 25 Jul 2025 13:38:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fixing toString value for flags that have ACC_ overloaded flags.
>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>  - Reflecting review feedback:
>    - when conflict is detected, the generator fails
>    - adding runtime checks
>    - using constants for number of bits

There's a lot to like in this patch. Now flags cannot erroneously overlap, which will give us all javac developers more confidence that we're not stepping into each other toes. Also, by making the mechanism more formally correct, it's easier to see which "holes" we have available (and there's probably quite a lot left).

The only thing I'm unsure of, as pointed out in the review, is the dynamic checks. I believe that, as far as this PR is concerned, this feels like "scope creep". I think it would be cleaner if this PR only concerned about introducing the machinery. Then maybe we can brainstorm separately on what would be the best way to add some of these checks (but I'm skeptical that we can find anything that doesn't feel like a compromise).

For instance, another way to do this could be to do another combo test like the tree test, where we compile all the existing tests, and check the validity of all the flags on all the symbols. That's an offline way to make sure that what we do in javac is "sort of" correct, but one that doesn't leak into the code.

The real fix for this, as we know (and as @archiecobbs commented) is to move away from longs, but that's not what this PR is about.

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3118166298

From jlu at openjdk.org  Fri Jul 25 16:34:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 25 Jul 2025 16:34:58 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Looks good. The JBS issue will need to be set as a P2 to be eligible for backport to 25.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103:

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

As we discussed, even though we used this suggestion last drop, the translation team rejected the translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:

> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren

Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056110784
PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2231568635
PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2231553322

From naoto at openjdk.org  Fri Jul 25 17:26:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Jul 2025 17:26:55 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <DAVpxfrk7RSbrseRryOh8LMEyykStSy5tLnPN4kqiUk=.d31ae25d-b093-4ad7-85e7-673191b7dba1@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056268896

From dnguyen at openjdk.org  Fri Jul 25 18:10:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 25 Jul 2025 18:10:54 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <6mNG6Cl0KiLoDgm1jq8nS_YaE_r2mp_dI2LmYuf1Dg8=.c050b5ea-f590-4dbb-80a8-1b7628d7db92@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056385560

From duke at openjdk.org  Sat Jul 26 07:30:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 07:30:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>
Message-ID: <sQ6kbF1jG3RynZSbeJ0zMsRnXJhD3M2T8W1ebHqyJ6k=.c51b11a3-b41b-46b5-83e9-831d71e1f265@github.com>

On Thu, 24 Jul 2025 22:07:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> src/java.base/share/classes/java/lang/Character.java line 9969:
> 
>> 9967:         int n = length;
>> 9968:         for (int i = 0; i < length; ) {
>> 9969:             if (isHighSurrogate(seq.charAt(i++)) && i < length &&
> 
> Imo this is quite hard to read, especially with `i++` inside of the if statement. What do you think about changing it to this? 
> ```java 
> for (int i = 1; i < length-1; i++) {
>     if (isHighSurrogate(seq.charAt(i)) &&
>         isLowSurrogate(seq.charAt(i + 1))) {
>         n--;
>         i++;
>     }
> }
> ``` 
> 
> edit: fixed a typo in my example

In the first place it yields an _incorrect_ result for sequences whose first character is a supplementary character.


jshell> int len(CharSequence seq) {
   ...>     final int length = seq.length();
   ...>     int n = length;
   ...>     for (int i = 1; i < length-1; i++) {
   ...>             if (isHighSurrogate(seq.charAt(i)) &&
   ...>                 isLowSurrogate(seq.charAt(i + 1))) {
   ...>                     n--;
   ...>                     i++;
   ...>             }
   ...>     }
   ...>     return n;
   ...> }
|  ????????: ???? len(CharSequence)????? method isHighSurrogate(char), and method isLowSurrogate(char)????????????????

jshell> boolean isHighSurrogate(char ch) {
   ...>     return 0xd800 <= ch && ch <= 0xdbff;
   ...> }
|  ????????: ???? isHighSurrogate(char)

jshell> boolean isLowSurrogate(char ch) {
   ...>     return 0xdc00 <= ch && ch <= 0xdfff;
   ...> }
|  ????????: ???? isLowSurrogate(char)

jshell> len("?");
$5 ==> 2

jshell> len("OK?");
$6 ==> 3

jshell> len("??");
$7 ==> 3


I will not change it alone unless the existing overload `int codePointCount(CharSequence seq, int beginIndex, int endIndex)` is also planned to be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232751973

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <BAgjxwbEh8sYWfD2tJf7nSU_Pb5rdw9jBewrGCy8O8o=.d8325f59-50bd-4f4a-8fe1-3de2102a69aa@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:

 - Discard changes out of than java.base
 - Fix copyright year
   
   Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
 - Fix how to get code point count in StringBuilder
   
   Co-authored-By: Chen Liang <liach at openjdk.org>
 - Fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/6f2e1d2b..63eb4a7d

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

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

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

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>
Message-ID: <AApM1SQJDnYua8EgKFE6MHAEcfQmQKjsMgualBjyN5w=.439c07a4-fdbe-4121-9456-277822927077@github.com>

On Thu, 24 Jul 2025 16:18:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Discard changes out of than java.base
>>  - Fix copyright year
>>    
>>    Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
>>  - Fix how to get code point count in StringBuilder
>>    
>>    Co-authored-By: Chen Liang <liach at openjdk.org>
>>  - Fix test
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 545:
> 
>> 543:         byte[] value = this.value;
>> 544:         if (isLatin1(coder)) {
>> 545:             return value.length;
> 
> Suggestion:
> 
>             return count;

I see, I fixed the argument passed to `StringUTF16.codePointCount` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232795947

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>
Message-ID: <PspvQ2kci2XBVM0rUFweY_IAgTTNJ90nVJdfoO1kgbY=.4fa23aee-ff6c-43c6-a829-49f839445680@github.com>

On Thu, 24 Jul 2025 21:49:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Discard changes out of than java.base
>>  - Fix copyright year
>>    
>>    Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
>>  - Fix how to get code point count in StringBuilder
>>    
>>    Co-authored-By: Chen Liang <liach at openjdk.org>
>>  - Fix test
>
> test/jdk/java/lang/StringBuilder/Supplementary.java line 216:
> 
>> 214:         testAppendCodePoint(Character.MAX_CODE_POINT+1, IllegalArgumentException.class);
>> 215:     }
>> 216: 
> 
> nit, as the other copyrights are updated: 
> 
> * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.

My fault, I renewed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232795594

From duke at openjdk.org  Sat Jul 26 08:50:55 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:50:55 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>
Message-ID: <zVRJSzj-TVoH1tbtPukFJGMtmyKWESLUZumA0LGa4O8=.002484e9-6b57-45f1-9a7f-817a83fa6cc2@github.com>

On Thu, 24 Jul 2025 15:10:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.

I glanced over https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/thread.html and those for some past months, but I did not get how to send one.

According to https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149338.html and sub messages, the content in this PR seems to be transferred to the mailing list.

> Also, do we need codePointCount on CharSequence?

I did not add it because it does not have an existing overload and has a simple (but not efficient) workaround (`codePoints().count()`), but it would be nice if it exists.

> Could you please add a bug number under @bug?

Which doc comments shall I add it?

> And yes, every change to the spec needs a CSR.

I got it, but do you know how non-Authors like me create ones?

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121518177

From duke at openjdk.org  Sat Jul 26 10:10:40 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 10:10:40 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:

 - Update `@bug` in correct file
 - Add default implementation on codePointCount in CharSequence
 - Update `@bug` entries in test class doc comments
 - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/63eb4a7d..0e55e35c

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

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

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

From duke at openjdk.org  Sat Jul 26 10:22:53 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 10:22:53 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

How and where can I add tests for default implementing methods in `CharSequence`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121593297

From jpai at openjdk.org  Sat Jul 26 14:24:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Jul 2025 14:24:00 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
Message-ID: <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>

On Sat, 26 Jul 2025 10:20:20 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update `@bug` in correct file
>>  - Add default implementation on codePointCount in CharSequence
>>  - Update `@bug` entries in test class doc comments
>>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`
>
> How and where can I add tests for default implementing methods in `CharSequence`?

Hello @tats-u,

> > The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.
> 
> I glanced over https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/thread.html and those for some past months, but I did not get how to send one.
> 
The OpenJDK contribution guide has the necessary details on how to contribute to the project. Specifically this section https://openjdk.org/guide/#socialize-your-change is of relevance. In order to send a mail to the core-libs-dev mailing list, please first subscribe to that mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev and initiate a discussion explaining the need and motivation for this new API. After there's some agreement about this proposal, the implementation changes in this PR can be pursued further.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121977983

From alanb at openjdk.org  Sat Jul 26 14:29:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Jul 2025 14:29:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <uLmMkM1XRQjEEitj1ErhvawNNE7ZvcHhHh6YweejsxE=.f48897bd-4f73-4d75-982d-ca4b3f6ebb36@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121986320

From nlisker at gmail.com  Sat Jul 26 20:11:04 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 26 Jul 2025 23:11:04 +0300
Subject: Possible bug with multiple generic bounds
In-Reply-To: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>
References: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>
Message-ID: <CA+0ynh9pO_S7Kn0z_KQ2HzSG1xoki2Ge4nbAzaBAiXrM0-W=fQ@mail.gmail.com>

Created https://bugs.openjdk.org/browse/JDK-8364144.

On Sat, Jul 19, 2025 at 7:28?PM Nir Lisker <nlisker at gmail.com> wrote:

> Hello,
>
> Initially reported in the Eclipse compiler since ECJ accepts code that
> javac does not:
> https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4226. The current
> assessment is that the fault is with javac.
>
> Copying the example from there:
>
> ```
> interface Culprit {}
>
> class EntityInfo<E extends NumberGenerator<?> & Culprit> {}
>
> class NumberGenerator<N extends Number> implements NumberSupplier<N> {
>
> @Override
>     public N getNumber() {
>         return null;
>     }
> }
>
> interface NumberSupplier<N extends Number>  {
>
>     N getNumber();
> }
> ```
>
> javac fails with:
> ```
> error: getNumber() in NumberGenerator cannot implement getNumber() in
> NumberSupplier
> class EntityInfo<E extends NumberGenerator<?> & Culprit> {}
>                  ^
>   return type CAP#1 is not compatible with CAP#2
>   where N#1,N#2 are type-variables:
>     N#1 extends Number declared in class NumberGenerator
>     N#2 extends Number declared in interface NumberSupplier
>   where CAP#1,CAP#2 are fresh type-variables:
>     CAP#1 extends Number from capture of ?
>     CAP#2 extends Number from capture of ?
> 1 error
> ```
>
> Removing the Culprit bound:
> class EntityInfo<E extends NumberGenerator<?>> {}
>
> satisfies javac.
>
> Also noted that combining the supertypes explicitly is accepted:
> ```
> class X<T extends Number> extends NumberGenerator<T> implements Culprit {
> }
>
> class EI2<E extends X<?>> {}
> ```
>
> Thanks,
> Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250726/0096635e/attachment-0001.htm>

From duke at openjdk.org  Sun Jul 27 10:25:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Jul 2025 10:25:54 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
Message-ID: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>

On Sat, 26 Jul 2025 14:21:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> please first subscribe to that mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev

Does this mailing list system require us to subscribe the list to post a new mail to the list? I would like to leave it at least after this PR is merged because I would not like my mailbox to be messed up by emails not related to this change.

> The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

The title of the JBS issue seems to be changed by you but it looks like the default method for `CharSequence` should be stripped for this time according to your concerns. No `codePointCount` methods have been added to `CharSequence` so it may be too early for us to add one to `CharSequence`. Do you think that you should replace `CharSequence` in the title with another class name?

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124289446

From alanb at openjdk.org  Sun Jul 27 15:21:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Jul 2025 15:21:55 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
Message-ID: <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>

On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> No `codePointCount` methods have been added to `CharSequence` so it may be too early for us to add one to `CharSequence`. Do you think that you should replace `CharSequence` in the title with another class name?

Can you clarify what you mean? Right now your PR is proposing to add a default method named codePointCount to CharSequence.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124488657

From acobbs at openjdk.org  Sun Jul 27 23:02:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 27 Jul 2025 23:02:34 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v7]
In-Reply-To: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
Message-ID: <dBNMCyOpN2BlgOSHCj9BSy7uewL5jbNeO8wekS3hWnI=.619d8d57-37f3-40e6-bb96-782702420b4d@github.com>

> This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred.
> 
> A few notes:
> * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur.
> * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect.
> * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented.
> * A few minor cleanups are included
> 
> This PR includes the following PR as a dependency/prerequisite:
> * #25840

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
 - Ensure that "-Xlint:none" still works for the affected warnings.
   
   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
   which allowed the affected warnings to get away with skipping that check.
 - Minor naming and Javadoc tweaks.
 - Merge branch 'JDK-8359596' into JDK-8349847
 - No need for /nodynamiccopyright/ with this test.
 - Restore behavior when both -Xlint:options and -Xlint:-options are given.
 - Merge branch 'master' into JDK-8349847
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4189fcba...e858bea1

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

Changes: https://git.openjdk.org/jdk/pull/23622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23622&range=06
  Stats: 228 lines in 15 files changed: 152 ins; 35 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/23622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23622/head:pull/23622

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

From duke at openjdk.org  Sun Jul 27 23:07:57 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Jul 2025 23:07:57 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
Message-ID: <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>

On Sun, 27 Jul 2025 15:19:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Right now your PR is proposing to add a default method named codePointCount to CharSequence.

If it should be excluded for this time, I will push an additional commit to _remove_ it from the content in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124780267

From jlahoda at openjdk.org  Mon Jul 28 06:50:47 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Jul 2025 06:50:47 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

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

  Reverting runtime checks, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/e00209f0..f1d6def8

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

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

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

From alanb at openjdk.org  Mon Jul 28 09:19:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 09:19:05 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
 <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
Message-ID: <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>

On Sun, 27 Jul 2025 23:05:25 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> > Right now your PR is proposing to add a default method named codePointCount to CharSequence.
> 
> If it should be excluded for this time, I will push an additional commit to _remove_ it from the content in this PR.

I think we should mull over the addition of CharSequence::codePointCount. On the surface it looks like it fits but we can't rush it (CharSequence is widely implemented and additions to this interface have a history of disruption in the eco system).

What is the reason for proposing Character.codePointCount(CharSequence) aswell?

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3126308040

From duke at openjdk.org  Mon Jul 28 10:07:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 10:07:44 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v5]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <Jv35jzib2L2z6wXTEBMhmrFZqt-Tv0S0iby_kZQfdeo=.53f7b9e6-36ae-4dc0-9a86-16f8c271e568@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont 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 updates from master
 - Reverted test (not caused by this PR).
 - Some (not all) feedback addressed. Still open questions.
 - Applying read-only configuration for Javac internal use of ZIP/JAR file systems.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/ab5e98da..217cdda6

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

  Stats: 54127 lines in 1365 files changed: 34963 ins; 12776 del; 6388 mod
  Patch: https://git.openjdk.org/jdk/pull/25639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25639/head:pull/25639

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

From duke at openjdk.org  Mon Jul 28 10:07:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 10:07:44 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v5]
In-Reply-To: <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
Message-ID: <4GkaAhIXL6DHZSt_NqmdYTg3mAo-DW9nBBOWUDaEqwo=.b50533d8-7846-4eb6-ac67-cd3c37e8fa98@github.com>

On Wed, 11 Jun 2025 05:43:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 183:
>> 
>>> 181:      *                       {@code null} to ignore release versioning).
>>> 182:      */
>>> 183:     public static Map<String, ?> readOnlyJarFSEnv(String releaseVersion) {
>> 
>> I named this after the getJarFSProvider() method above, since they are used in close proximity, but would be happy to consider other names.
>
> I am a bit uneasy about having the method static, as this class's API is normally instance methods. I think that an instance of FSInfo (`fsInfo`) is available in both `JavacFileManager` and `Locations`, so it would be better to simply have an instance method. (The static field is OK, that's not an API.)

@lahodaj thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2235678530

From duke at openjdk.org  Mon Jul 28 10:12:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 10:12:39 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v6]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <dAQSHDuNS_3g3jtNsOiye2o-vj0pyfyVEjRj96E5D5E=.410dcfb4-6fb5-4e7a-8b2e-367bdc4b650e@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Updating to latest local changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/217cdda6..3850932c

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

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

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

From mcimadamore at openjdk.org  Mon Jul 28 10:46:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Jul 2025 10:46:58 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <EIWVd7lMW08JOU4X0uuhcq9R2cANWtupux7Ivo6YwbM=.460304e7-cfbd-454c-84c3-fba53a7841c6@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3061888050

From duke at openjdk.org  Mon Jul 28 12:30:56 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 28 Jul 2025 12:30:56 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
 <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
 <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>
Message-ID: <LC7g_xU2q5VgdpdmZJkc4HWRKnn-G0HkRNsSGiBzdf8=.9b040b8a-3853-41b1-8d9c-aeb4af983521@github.com>

On Mon, 28 Jul 2025 09:16:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should mull over the addition of CharSequence::codePointCount. On the surface it looks like it fits but we can't rush it (CharSequence is widely implemented and additions to this interface have a history of disruption in the eco system).

We might as well defer it until another JBS issue if it is too difficult to decide whether it should be included in this PR.

> What is the reason for proposing Character.codePointCount(CharSequence) aswell?

1. It already has an overload with the start and end indices unlike `CharSequence` like `String` and `AbstractStringBuilder`
2. Less harmful than `CharSequence::codePointCount` because it is just a static method.
3. There are already the `(CharSequence, int, int)` and `(char[], int, int)` overloads and the `(char[], int, int)` overload is used for the test for `String::codePointCount(int, int)`. We should add the `(char[])` overload for test and also add the `(CharSequence)` for consistency.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3126999990

From myankelevich at openjdk.org  Mon Jul 28 13:28:57 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 28 Jul 2025 13:28:57 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v6]
In-Reply-To: <dAQSHDuNS_3g3jtNsOiye2o-vj0pyfyVEjRj96E5D5E=.410dcfb4-6fb5-4e7a-8b2e-367bdc4b650e@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <dAQSHDuNS_3g3jtNsOiye2o-vj0pyfyVEjRj96E5D5E=.410dcfb4-6fb5-4e7a-8b2e-367bdc4b650e@github.com>
Message-ID: <OgcvMsvmOVRtmwk74hUv439sgdPnhqnJh7zxeOuMDqE=.78e06e07-ad9c-4908-aecd-c0dcdcc2628b@github.com>

On Mon, 28 Jul 2025 10:12:39 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating to latest local changes.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 25:

> 23:  * questions.
> 24:  */
> 25: 

Nit: could you please update copyright dates in all files

test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 27:

> 25:  * @test
> 26:  * @bug 8331027
> 27:  * @summary Verify classfile inside ct.sym

Could you please add the bug id to the `@bug`, as this is a src change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2236454628
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2236462531

From jlahoda at openjdk.org  Mon Jul 28 15:42:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Jul 2025 15:42:54 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <kRmQfEMYYRS3APBZOFrDji7ybQp4BMtc6PRf5xhL_6E=.7642f5e4-bc8f-4292-8ea0-5c8918d9d919@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
 <kRmQfEMYYRS3APBZOFrDji7ybQp4BMtc6PRf5xhL_6E=.7642f5e4-bc8f-4292-8ea0-5c8918d9d919@github.com>
Message-ID: <A7IkPe5TC0xAT5PLZKnLuU1QpzIMRxQtdR5-_SDU6k8=.d2a79517-aa1a-44ff-b235-e0a69d13b91e@github.com>

On Fri, 25 Jul 2025 14:38:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> There's a lot to like in this patch. Now flags cannot erroneously overlap, which will give us all javac developers more confidence that we're not stepping into each other toes. Also, by making the mechanism more formally correct, it's easier to see which "holes" we have available (and there's probably quite a lot left).
> 
> The only thing I'm unsure of, as pointed out in the review, is the dynamic checks. I believe that, as far as this PR is concerned, this feels like "scope creep". I think it would be cleaner if this PR only concerned about introducing the machinery. Then maybe we can brainstorm separately on what would be the best way to add some of these checks (but I'm skeptical that we can find anything that doesn't feel like a compromise).
> 
> For instance, another way to do this could be to do another combo test like the tree test, where we compile all the existing tests, and check the validity of all the flags on all the symbols. That's an offline way to make sure that what we do in javac is "sort of" correct, but one that doesn't leak into the code.
> 
> The real fix for this, as we know (and as @archiecobbs commented) is to move away from longs, but that's not what this PR is about.

Thanks @mcimadamore for the review.

I think the build changes are now ready to be reviewed. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3127824873

From naoto at openjdk.org  Mon Jul 28 16:11:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Jul 2025 16:11:56 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
Message-ID: <SIiclFMHb56wXYyhj7jaQS29MoivHhUXfKCnS6d1OOg=.80f35ddb-bcd0-417a-83ac-38accf8c70b3@github.com>

On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

Looking at the original JSR 204 issue: https://bugs.openjdk.org/browse/JDK-4985217, it is interesting that the problem description included `CharSequence` but not in the proposed API. Tried to find the reason behind, but could not find any relevant information so far.
As to the general comment, I am not so sure adding the no-arg overrides, as they would simply be convenience methods to `codePointCount(0, length())` which to me adding not a significant benefit. My $0.02

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3127954858

From asemenyuk at openjdk.org  Mon Jul 28 16:21:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 28 Jul 2025 16:21:57 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <ht1okQrxkWG6QOaDhqlq_YxoxfM3E_fIZiog19cdumU=.931ade81-50b9-4dc2-b691-ac7685cbdbd6@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

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

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3063629934
PR Comment: https://git.openjdk.org/jdk/pull/26467#issuecomment-3128009012

From asemenyuk at openjdk.org  Mon Jul 28 16:21:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 28 Jul 2025 16:21:58 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
 <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
Message-ID: <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>

On Fri, 25 Jul 2025 16:23:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:
> 
>> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
>> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
>> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren
> 
> Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.

@justin-curtis-lu the issue has been filed and resolved already - [JDK-8361697](https://bugs.openjdk.org/browse/JDK-8361697)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2237149723

From jlu at openjdk.org  Mon Jul 28 16:33:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Jul 2025 16:33:00 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
 <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
 <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>
Message-ID: <y8EEf37XTMCbv3ex17Kf6nXXNHTAFOCU9wEHqnygXkY=.bbf01a07-a6ac-4a09-a914-4e6cbb0a6d58@github.com>

On Mon, 28 Jul 2025 16:19:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:
>> 
>>> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
>>> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
>>> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren
>> 
>> Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.
>
> @justin-curtis-lu the issue has been filed and resolved already - [JDK-8361697](https://bugs.openjdk.org/browse/JDK-8361697)

Thanks, I missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2237188811

From duke at openjdk.org  Mon Jul 28 16:40:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 16:40:35 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v7]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <iNGPq6zQzcQoQchHaBGyYxKsOEKMgPqRwzrpMjYn7lM=.37c27baf-8f08-41f4-8586-14c2d3c2bb3d@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/3850932c..b2ef380c

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

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

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

From duke at openjdk.org  Mon Jul 28 16:40:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 16:40:36 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v6]
In-Reply-To: <OgcvMsvmOVRtmwk74hUv439sgdPnhqnJh7zxeOuMDqE=.78e06e07-ad9c-4908-aecd-c0dcdcc2628b@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <dAQSHDuNS_3g3jtNsOiye2o-vj0pyfyVEjRj96E5D5E=.410dcfb4-6fb5-4e7a-8b2e-367bdc4b650e@github.com>
 <OgcvMsvmOVRtmwk74hUv439sgdPnhqnJh7zxeOuMDqE=.78e06e07-ad9c-4908-aecd-c0dcdcc2628b@github.com>
Message-ID: <70amNXR95zbThfbGeTG_xLWo83H5kwjkqFycNAO3HT4=.16c46f03-8371-415d-aa1f-3484a322b1c5@github.com>

On Mon, 28 Jul 2025 13:23:52 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating to latest local changes.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 25:
> 
>> 23:  * questions.
>> 24:  */
>> 25: 
> 
> Nit: could you please update copyright dates in all files

Done. I could have sworn I'd done these. Thanks for spotting.

> test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8331027
>> 27:  * @summary Verify classfile inside ct.sym
> 
> Could you please add the bug id to the `@bug`, as this is a src change

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2237213561
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2237213676

From duke at openjdk.org  Mon Jul 28 16:43:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 28 Jul 2025 16:43:15 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v8]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <pQvR9umT34eTXtZIVKzlSWjW9pjKL-prkSlgGfRJaY8=.eae6cd16-4439-4390-b74e-b8e9d20178e1@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/b2ef380c..770aa086

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

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

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

From mcimadamore at openjdk.org  Mon Jul 28 16:58:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Jul 2025 16:58:08 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
Message-ID: <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>

On Sun, 20 Jul 2025 20:39:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:
> 
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>  - Address review suggestions.
>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>  - Merge branch 'master' into MandatoryWarningCleanup
>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>  - ... and 79 more: https://git.openjdk.org/jdk/compare/cab51596...91202f7b

Overall, this is a great piece of work! The simplifications are evident throughout the entire codebase. I'm not sure `LintMapper` has reached its simplest possible form yet -- I've left some comments for you to consider -- I wonder if there's something we can do to capture the state transitions a little more explicitly there.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 484:

> 482:      * @param warning key for the localized warning message
> 483:      */
> 484:     public void logIfEnabled(LintWarning warning) {

I like it a lot that now there's "just warnings". It took a while to see this more clearly, but once you see it you can't unsee it :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 55:

> 53:  *
> 54:  * <p>
> 55:  * Because {@code @SuppressWarnings} is a Java symbol, in general this mapping can't be be

Suggestion:

 * Because {@code @SuppressWarnings} is a Java symbol, in general this mapping can't be

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 178:

> 176:      * Instances evolve through three states:
> 177:      * <ul>
> 178:      *  <li>Before the file has been completely parsed, {@link #topSpans} is null.

Maybe we can capture all these interesting state transitions with a sealed hierarchy? E.g. at different stages it seems like we might need different info attached to this "info" note -- which might suggest using different subclasses?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 283:

> 281:      * nodes representing the top-level declarations in the file, and so on.
> 282:      */
> 283:     private static class DeclNode extends Span {

This also seems to suggest that some of the spans computed after parsing are later "promoted" to decl nodes. But the code doesn't work like this, instead it tracks spans and decls separately into the same FileInfo data structure, which I find a bit odd.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java line 1079:

> 1077:         private final Symbol sym;
> 1078: 
> 1079:         public TypeAnnotate(Env<AttrContext> env, Symbol sym) {

All these changes are truly great, as they are sign that you were able to remove a lot of coupling from the way things were implemented. E.g. the goal of this PR is not to "make annotation processing simpler", but turns out that, by centralizing the lint mapping logic in one place, other parts of the compiler also got simpler!

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1:

> 1: /*

Now that `Attr` no longer depends on `Check::lint` (yayyy!) can we make that field private?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 227:

> 225:     void warnDeprecated(DiagnosticPosition pos, Symbol sym) {
> 226:         Assert.check(!importSuppression);
> 227:         LintWarning warningKey = sym.isDeprecatedForRemoval() ?

Another big win is the absence of all "is enabled?" checks in the new code. Meaning less potential for mistakes.

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

> 1: /*

Another big win here -- code is much flatter!

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 265:

> 263: 
> 264:         // Short circuit if this calculation is unnecessary
> 265:         if (!lintMapper.lintAt(env.toplevel.sourcefile, env.tree.pos()).get().isEnabled(THIS_ESCAPE))

Question -- this code does the shortcircuiting using `lintMapper` -- but I saw code in `Check` that does shortcircuiting using `lint` (e.g. `Check::checkPotentiallyAmbiguousOverloads`). If such short-circuit operation are somewhat frequent (to avoid expensive computation logic) perhaps we should have a "blessed" (and less verbose) way to do it?

(Unfortunately, I'm aware that `checkPotentiallyAmbiguousOverloads` is called when `lintMapper` yet doesn't know whether lint warnings are suppressed or not -- this seems a problem?)

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 174:

> 172:                   category.annotationSuppression ?                      // else emit if the category is not suppressed, where
> 173:                     !lint.isSuppressed(category) :                      // ...suppression happens via @SuppressWarnings
> 174:                     !options.isLintDisabled(category);                  // ...suppression happens via -Xlint:-category

Can this be rewritten as `!rootLint().isSuppressed(category)` ? E.g. how many different ways do we have to query the same thing?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 196:

> 194:          */
> 195:         public void flushLintWaiters() {
> 196:             lintWaitersMap.entrySet().removeIf(entry -> {

the use of `removeIf` seems to suggest that these not all warnings might be flushed at the same time? But this seems odd -- I'd expect that the `lintMapper` only gets new info in `Attr` -- after which if something doesn't have a `Lint`, well that shouldn't change?

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

PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3063577027
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237121469
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237230153
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237237978
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237264944
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237114296
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237142388
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237132978
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237149038
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237163998
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237209441
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237227213

From acobbs at openjdk.org  Mon Jul 28 17:53:18 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Jul 2025 17:53:18 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v4]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <V5qjwOHNKhG92xE-lfnLBA4jYRVtpJuXqQXMe_OhEx4=.38335f9d-d305-4141-8242-59c42c32f422@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 91 commits:

 - Address a couple of review comments.
 - Merge branch 'master' into JDK-8348611
 - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - ... and 81 more: https://git.openjdk.org/jdk/compare/4189fcba...d4322d92

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

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=03
  Stats: 1998 lines in 56 files changed: 1052 ins; 586 del; 360 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Mon Jul 28 17:53:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Jul 2025 17:53:19 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
Message-ID: <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>

On Mon, 28 Jul 2025 16:41:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:
>> 
>>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - Address review suggestions.
>>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - Merge branch 'master' into MandatoryWarningCleanup
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - ... and 79 more: https://git.openjdk.org/jdk/compare/cab51596...91202f7b
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 55:
> 
>> 53:  *
>> 54:  * <p>
>> 55:  * Because {@code @SuppressWarnings} is a Java symbol, in general this mapping can't be be
> 
> Suggestion:
> 
>  * Because {@code @SuppressWarnings} is a Java symbol, in general this mapping can't be

Oops, thanks. Fixed in d4322d92d1f.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 178:
> 
>> 176:      * Instances evolve through three states:
>> 177:      * <ul>
>> 178:      *  <li>Before the file has been completely parsed, {@link #topSpans} is null.
> 
> Maybe we can capture all these interesting state transitions with a sealed hierarchy? E.g. at different stages it seems like we might need different info attached to this "info" note -- which might suggest using different subclasses?

Yes, this probably could take advantage of those newer language features. I'll take a look at this and your other comment about `FileInfo` and post an update soon.

Thanks very much for the detailed review and comments so far!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1:
> 
>> 1: /*
> 
> Now that `Attr` no longer depends on `Check::lint` (yayyy!) can we make that field private?

Indeed - good catch! Fixed in d4322d92d1f.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 265:
> 
>> 263: 
>> 264:         // Short circuit if this calculation is unnecessary
>> 265:         if (!lintMapper.lintAt(env.toplevel.sourcefile, env.tree.pos()).get().isEnabled(THIS_ESCAPE))
> 
> Question -- this code does the shortcircuiting using `lintMapper` -- but I saw code in `Check` that does shortcircuiting using `lint` (e.g. `Check::checkPotentiallyAmbiguousOverloads`). If such short-circuit operation are somewhat frequent (to avoid expensive computation logic) perhaps we should have a "blessed" (and less verbose) way to do it?
> 
> (Unfortunately, I'm aware that `checkPotentiallyAmbiguousOverloads` is called when `lintMapper` yet doesn't know whether lint warnings are suppressed or not -- this seems a problem?)

The subtle difference between `ThisEscapeAnalyzer` and `Check::checkPotentiallyAmbiguousOverloads` is that `ThisEscapeAnalyzer` runs during the compiler's `WARN` phase, whereas `checkPotentiallyAmbiguousOverloads` runs during the `ATTR` phase, and only during the `WARN` phase it is guaranteed that `LintMapper.lintAt()` will always be able to return a non-empty value.

Side note: as you may remember we had an earlier discussion about the idea of moving warnings from the `ATTR` phase to the `WARN` phase - the main "pro" being that there is no longer any concern about whether the applicable `Lint` instance has been mapped yet, so you don't need to track it manually (like `Check` does). I played with trying to do this but it was too heavy of a lift at the time (and probably still is) but it's a potential long term idea. The downside however (as you pointed out) is that during `ATTR` you have all the information you need to compute the warnings already "in front of you", whereas if you deferred that warning calculation to the `WARN` you would have to find it again (but maybe most of it is available?). Anyway, for now this is all "for future study".

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 174:
> 
>> 172:                   category.annotationSuppression ?                      // else emit if the category is not suppressed, where
>> 173:                     !lint.isSuppressed(category) :                      // ...suppression happens via @SuppressWarnings
>> 174:                     !options.isLintDisabled(category);                  // ...suppression happens via -Xlint:-category
> 
> Can this be rewritten as `!rootLint().isSuppressed(category)` ? E.g. how many different ways do we have to query the same thing?

There is a quirk about that: `rootLint().isSuppressed()` always returns `false` no matter what (see the last line of `Lint.initializeRootIfNeeded()`).

In other words, the question that `isSuppressed()` is answering is not "Is this category suppressed somehow?" but rather "Is this category suppressed by a `@SuppressWarnings` annotation?"

So in the case of a warning enabled by default:
* For the root `Lint` instance, "suppression" happens via `-Xlint:-foo`
* For non-root `Lint` instances, "suppression" happens via `@SuppressWarnings("foo")`

Could this be simplified somehow? Probably... but that would be an independent cleanup.

> the use of `removeIf` seems to suggest that these not all warnings might be flushed at the same time? 

Correct - "in theory" they might not all be flushed at the same time, because the entries in `lintWaitersMap` are organized on a per-source file basis, whereas lint mappings are discovered on a per-top level declaration basis. In practice they probably are.... but I didn't want to impose any implicit restrictions on when it was safe to invoke `Log.reportOutstandingWarnings()`. So, call this defensive coding :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237441525
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237441827
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237440503
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237440802
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237441054
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237441313

From jlahoda at openjdk.org  Mon Jul 28 18:30:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Jul 2025 18:30:57 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v8]
In-Reply-To: <pQvR9umT34eTXtZIVKzlSWjW9pjKL-prkSlgGfRJaY8=.eae6cd16-4439-4390-b74e-b8e9d20178e1@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <pQvR9umT34eTXtZIVKzlSWjW9pjKL-prkSlgGfRJaY8=.eae6cd16-4439-4390-b74e-b8e9d20178e1@github.com>
Message-ID: <RICSGDqOT11dy1vM3-Eu35PHNhI8adJOe-3UbImZeWw=.c963cf94-ad12-4420-bb5b-e1b6efd74753@github.com>

On Mon, 28 Jul 2025 16:43:15 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Overall looks good, two small suggestions for cleanup inline.

test/langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2025, Oracle and/or its affiliates. All rights reserved.

There's no change in this file, this year change can presumably be dropped.

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

PR Review: https://git.openjdk.org/jdk/pull/25639#pullrequestreview-3064139247
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2237521343

From jlahoda at openjdk.org  Mon Jul 28 18:30:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Jul 2025 18:30:58 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v6]
In-Reply-To: <70amNXR95zbThfbGeTG_xLWo83H5kwjkqFycNAO3HT4=.16c46f03-8371-415d-aa1f-3484a322b1c5@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <dAQSHDuNS_3g3jtNsOiye2o-vj0pyfyVEjRj96E5D5E=.410dcfb4-6fb5-4e7a-8b2e-367bdc4b650e@github.com>
 <OgcvMsvmOVRtmwk74hUv439sgdPnhqnJh7zxeOuMDqE=.78e06e07-ad9c-4908-aecd-c0dcdcc2628b@github.com>
 <70amNXR95zbThfbGeTG_xLWo83H5kwjkqFycNAO3HT4=.16c46f03-8371-415d-aa1f-3484a322b1c5@github.com>
Message-ID: <pgq8TCDQ4OuvXBx7xPTp8cQH37Z4uenCZbz71ZSQu3o=.9a2dfb3f-a350-4b7e-a2bb-292dd310f70e@github.com>

On Mon, 28 Jul 2025 16:37:17 GMT, David Beaumont <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8331027
>>> 27:  * @summary Verify classfile inside ct.sym
>> 
>> Could you please add the bug id to the `@bug`, as this is a src change
>
> Done.

I think we are using just `8331027 8356645`, without the comma.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2237522739

From duke at openjdk.org  Mon Jul 28 19:12:02 2025
From: duke at openjdk.org (duke)
Date: Mon, 28 Jul 2025 19:12:02 GMT
Subject: Withdrawn: 8355204: Consider simplifying type metadata stripping
In-Reply-To: <E66jK4Jc-fGFw6dbr4NHlpmiHNPWYar9sJxn71hE1Ag=.bc27a393-dabc-4035-a902-c425f2f52317@github.com>
References: <E66jK4Jc-fGFw6dbr4NHlpmiHNPWYar9sJxn71hE1Ag=.bc27a393-dabc-4035-a902-c425f2f52317@github.com>
Message-ID: <lAm9Kwtyx4oW__bS5-eo7RyhT8l0F1tkIDdALFTGkOo=.a3144789-b637-41c8-b416-c90faf5810de@github.com>

On Mon, 21 Apr 2025 16:41:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change removes support for `stripMetadataIfNeeded`. After [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) there are only two uses of the method:
> 
> * `Types#directSupertypes`, which is specified as preserving type annotations. This change means that type metadata will be preserved for supertypes that appear in source, as well as substituted types for transitive supertypes.
> * `Trees#getTypeMirror`, which doesn't specify whether or not type annotations are preserved.
> 
> `stripMetadataIfNeeded` was added for [JDK-8031744](https://bugs.openjdk.org/browse/JDK-8031744). The unconditional `stripMetadata` was added for [JDK-8144580](https://bugs.openjdk.org/browse/JDK-8144580). `stripMetadata` was substantially reworked to ensure it always stripped annotations in [JDK-8042981](https://bugs.openjdk.org/browse/JDK-8042981), which also updated the spec for Types' utility methods to clarify when type annotations were preserved, added a public API for removing annotations from types, and replaced some calls to `stripMetadataIfNeeded` with `stripMetadata` because the former didn't strip annotations in some cases where stripping was actually needed.
> 
> I think it's worth considering removing `stripMetadataIfNeeded`. The bookkeeping to keep track of whether or not metadata should be stripped is fragile, and the API use-case can be supported by either preserving metadata or unconditionally stripping it.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Mon Jul 28 21:16:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 21:16:55 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 64:

> 62:             TypeElement clazz = (TypeElement) trees.getElement(new TreePath(new TreePath(cut), cut.getTypeDecls().get(0)));
> 63:             Map<Integer, List<String>> flag2Names = new TreeMap<>();
> 64:             Map<FlagTarget, Map<Integer, List<String>>> target2FlagBit2Fields = new HashMap<>();

Suggestion:

            Map<FlagTarget, Map<Integer, List<String>>> target2FlagBit2Fields = new EnumMap<>(FlagTarget.class);

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 84:

> 82:                                            .forEach(target -> target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>())
> 83:                                                                                    .computeIfAbsent(flagBit, _ -> new ArrayList<>())
> 84:                                                                                    .add(flagName));

Instead of a dedicated loop to verify no overlaps, we can make the nested map `Map<Integer, String>` and fail fast whenever we detect a conflict, like:

var oldFlagName = target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>()).put(flagBit, flagName);
if (oldFlagName != null) {
    // Fail fast code
}

I personally don't see a reason to collect all conflicting fields for a flag if any of these conflicts already causes a failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2237874183
PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2237871781

From mcimadamore at openjdk.org  Mon Jul 28 21:25:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Jul 2025 21:25:57 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
 <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
Message-ID: <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>

On Mon, 28 Jul 2025 17:49:44 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 265:
>> 
>>> 263: 
>>> 264:         // Short circuit if this calculation is unnecessary
>>> 265:         if (!lintMapper.lintAt(env.toplevel.sourcefile, env.tree.pos()).get().isEnabled(THIS_ESCAPE))
>> 
>> Question -- this code does the shortcircuiting using `lintMapper` -- but I saw code in `Check` that does shortcircuiting using `lint` (e.g. `Check::checkPotentiallyAmbiguousOverloads`). If such short-circuit operation are somewhat frequent (to avoid expensive computation logic) perhaps we should have a "blessed" (and less verbose) way to do it?
>> 
>> (Unfortunately, I'm aware that `checkPotentiallyAmbiguousOverloads` is called when `lintMapper` yet doesn't know whether lint warnings are suppressed or not -- this seems a problem?)
>
> The subtle difference between `ThisEscapeAnalyzer` and `Check::checkPotentiallyAmbiguousOverloads` is that `ThisEscapeAnalyzer` runs during the compiler's `WARN` phase, whereas `checkPotentiallyAmbiguousOverloads` runs during the `ATTR` phase, and only during the `WARN` phase it is guaranteed that `LintMapper.lintAt()` will always be able to return a non-empty value.
> 
> Side note: as you may remember we had an earlier discussion about the idea of moving warnings from the `ATTR` phase to the `WARN` phase - the main "pro" being that there is no longer any concern about whether the applicable `Lint` instance has been mapped yet, so you don't need to track it manually (like `Check` does). I played with trying to do this but it was too heavy of a lift at the time (and probably still is) but it's a potential long term idea. The downside however (as you pointed out) is that during `ATTR` you have all the information you need to compute the warnings already "in front of you", whereas if you deferred that warning calculation to the `WARN` you would have to find it again (but maybe most of it is available?). Anyway, for now this is all "for future study".

One thing that might help would be to maybe use the name `rootLint` for all lint variables we use to shortcircuit -- to make it clear that these checks are not really... 100% correct. Another possibility would be to have a centralized check in LintMapper which, if the tree has been attributed does a check similar to what `ThisEscapeAnalyzer` does, otherwise we just look at the root lint (as a stop gap). At least all clients that need shortcircuiting would use same logic, and the impl could do the best it can to support that (and maybe in the future we can see if we can improve on that front).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237890423

From acobbs at openjdk.org  Mon Jul 28 22:05:44 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Jul 2025 22:05:44 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Refactor LintMapper to clean up internal type hierarchy per review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/d4322d92..f65e1950

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

  Stats: 121 lines in 1 file changed: 24 ins; 39 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Mon Jul 28 22:05:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Jul 2025 22:05:45 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
Message-ID: <etiUV-2604lrZ1Pi35vRsIsunXP9GGuhMGRnCtOoFvI=.ff0eb291-cd15-4b96-87ce-063f72deb5f2@github.com>

On Mon, 28 Jul 2025 16:53:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:
>> 
>>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - Address review suggestions.
>>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - Merge branch 'master' into MandatoryWarningCleanup
>>  - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
>>  - ... and 79 more: https://git.openjdk.org/jdk/compare/cab51596...91202f7b
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 283:
> 
>> 281:      * nodes representing the top-level declarations in the file, and so on.
>> 282:      */
>> 283:     private static class DeclNode extends Span {
> 
> This also seems to suggest that some of the spans computed after parsing are later "promoted" to decl nodes. But the code doesn't work like this, instead it tracks spans and decls separately into the same FileInfo data structure, which I find a bit odd.

Should be improved in f65e1950467. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237935618

From acobbs at openjdk.org  Mon Jul 28 22:05:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Jul 2025 22:05:45 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
 <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
 <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>
Message-ID: <UPLLocTtLf2pXwqlYa_HtmrhV1gCQlptlMvWrMSKe5s=.9b87f843-d2bb-4591-a2ac-2c97894796de@github.com>

On Mon, 28 Jul 2025 21:23:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> One thing that might help would be to maybe use the name `rootLint` for all lint variables we use to shortcircuit -- to make it clear that these checks are not really... 100% correct.

Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...

> Another possibility would be to have a centralized check in LintMapper which, if the tree has been attributed does a check similar to what `ThisEscapeAnalyzer` does, otherwise we just look at the root lint (as a stop gap).

Continuing the above comment, wouldn't that cause `checkPotentiallyAmbiguousOverloads()` to start ignoring any enclosing `@SuppressWarnings("overrides")` annotations?

> At least all clients that need shortcircuiting would use same logic, and the impl could do the best it can to support that (and maybe in the future we can see if we can improve on that front).

Other ideas:
* Add a method that basically says "Call me back when my `Lint` is ready". Echoes of `DeferredLintHandler` :)
* Get rid of as much short-circuiting as we possible (i.e., where the performance impact is negligible, we can simply not short-circuit)
* Move the short-circuited warnings to the `WARN` phase

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2237935426

From mcimadamore at openjdk.org  Tue Jul 29 09:12:11 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Jul 2025 09:12:11 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <UPLLocTtLf2pXwqlYa_HtmrhV1gCQlptlMvWrMSKe5s=.9b87f843-d2bb-4591-a2ac-2c97894796de@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
 <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
 <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>
 <UPLLocTtLf2pXwqlYa_HtmrhV1gCQlptlMvWrMSKe5s=.9b87f843-d2bb-4591-a2ac-2c97894796de@github.com>
Message-ID: <W4wIHQ2Z1fSjcV74AvJEfXCrZmUaLl1hseEWHVHeOks=.4b6fe041-2d8a-4894-8ea7-eb0262ffc84a@github.com>

On Mon, 28 Jul 2025 21:58:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...

At the start of `checkPotentiallyAmbiguousOverloads()`, we check:


if (!lint.isEnabled(LintCategory.OVERLOADS))
            return;


Now, I do not see any other code setting this lint. There are a couple of visitors elsewhere that do, but these operations seems rather local. To my eyes, this is check applied to the root lint. Then there's a more subtle check (that I missed) below:


// Allow site's own declared methods (only) to apply @SuppressWarnings("overloads")
        methodGroups.forEach(list -> list.removeIf(
            m -> m.owner == site.tsym && !lint.augment(m).isEnabled(LintCategory.OVERLOADS)));


This "augments" the lint with one of the symbols to check, and removes the symbol if it is annotated with `@SuppressWarnings("overloads")`.

This code seems convoluted, in the sense that you don't really need to augment anything here? The toplevel check looks for enablement, whereas this loop looks for suppression. To implement the latter all you need is to check is a certain category appears suppressed in the given symbol. Note though: if we have a `@SuppressWarnings` on the enclosing class I don't think that will be considered. I will need to test a bit more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2239087936

From mcimadamore at openjdk.org  Tue Jul 29 09:20:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Jul 2025 09:20:57 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <W4wIHQ2Z1fSjcV74AvJEfXCrZmUaLl1hseEWHVHeOks=.4b6fe041-2d8a-4894-8ea7-eb0262ffc84a@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
 <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
 <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>
 <UPLLocTtLf2pXwqlYa_HtmrhV1gCQlptlMvWrMSKe5s=.9b87f843-d2bb-4591-a2ac-2c97894796de@github.com>
 <W4wIHQ2Z1fSjcV74AvJEfXCrZmUaLl1hseEWHVHeOks=.4b6fe041-2d8a-4894-8ea7-eb0262ffc84a@github.com>
Message-ID: <YlbYD-FOoNlKUBNfcQggO6Chb2Ohzl35uIgfxYoDPIg=.0a27e288-fc8e-4359-a616-3da9067ba8c1@github.com>

On Tue, 29 Jul 2025 09:09:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> One thing that might help would be to maybe use the name `rootLint` for all lint variables we use to shortcircuit -- to make it clear that these checks are not really... 100% correct.
>> 
>> Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...
>> 
>>> Another possibility would be to have a centralized check in LintMapper which, if the tree has been attributed does a check similar to what `ThisEscapeAnalyzer` does, otherwise we just look at the root lint (as a stop gap).
>> 
>> Continuing the above comment, wouldn't that cause `checkPotentiallyAmbiguousOverloads()` to start ignoring any enclosing `@SuppressWarnings("overrides")` annotations?
>> 
>>> At least all clients that need shortcircuiting would use same logic, and the impl could do the best it can to support that (and maybe in the future we can see if we can improve on that front).
>> 
>> Other ideas:
>> * Add a method that basically says "Call me back when my `Lint` is ready". Echoes of `DeferredLintHandler` :)
>> * Get rid of as much short-circuiting as we possible (i.e., where the performance impact is negligible, we can simply not short-circuit)
>> * Move the short-circuited warnings to the `WARN` phase
>
>> Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...
> 
> At the start of `checkPotentiallyAmbiguousOverloads()`, we check:
> 
> 
> if (!lint.isEnabled(LintCategory.OVERLOADS))
>             return;
> 
> 
> Now, I do not see any other code setting this lint. There are a couple of visitors elsewhere that do, but these operations seems rather local. To my eyes, this is check applied to the root lint. Then there's a more subtle check (that I missed) below:
> 
> 
> // Allow site's own declared methods (only) to apply @SuppressWarnings("overloads")
>         methodGroups.forEach(list -> list.removeIf(
>             m -> m.owner == site.tsym && !lint.augment(m).isEnabled(LintCategory.OVERLOADS)));
> 
> 
> This "augments" the lint with one of the symbols to check, and removes the symbol if it is annotated with `@SuppressWarnings("overloads")`.
> 
> This code seems convoluted, in the sense that you don't really need to augment anything here? The toplevel check looks for enablement, whereas this loop looks for suppression. To implement the latter all you need is to check is a certain category appears suppressed in the given symbol. Note though: if we have a `@SuppressWarnings` on the enclosing class I don't think that will be considered. I will need to test a bit more.

> Move the short-circuited warnings to the `WARN` phase

This is probably the best, as I suspect that we only shortcircuit in a handful of cases.

Another approach would be to try an augment lint earlier -- e.g. during `memberEnter`. After all, by that point we have seen the class, and we have seen a method/field symbol, so in principle we might know what suppressions these symbols have. The only thing that would be left after that is stuff inside method bodies (mostly local var declaration, and anon/local inner classes -- but I believe both go through `memberEnter` again, so we should be covered). This would ensure that the mappings are setup as early as possible -- which would allow shortcircuiting logic in `Check` to occur more naturally.

That said, doing this might have some bootstrapping issues -- @lahodaj any ideas?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2239109725

From duke at openjdk.org  Tue Jul 29 13:37:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 29 Jul 2025 13:37:44 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v9]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Feedback tweaks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/770aa086..b5a428d6

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

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

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

From duke at openjdk.org  Tue Jul 29 13:37:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 29 Jul 2025 13:37:45 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v8]
In-Reply-To: <RICSGDqOT11dy1vM3-Eu35PHNhI8adJOe-3UbImZeWw=.c963cf94-ad12-4420-bb5b-e1b6efd74753@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <pQvR9umT34eTXtZIVKzlSWjW9pjKL-prkSlgGfRJaY8=.eae6cd16-4439-4390-b74e-b8e9d20178e1@github.com>
 <RICSGDqOT11dy1vM3-Eu35PHNhI8adJOe-3UbImZeWw=.c963cf94-ad12-4420-bb5b-e1b6efd74753@github.com>
Message-ID: <lPk1FgIvMsZ2HDgMBllW0dq7H1uuZ2iHMHgeYlJlM-U=.79ccffda-46e5-430e-bcd7-867ac3744527@github.com>

On Mon, 28 Jul 2025 18:27:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year.
>
> test/langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2014, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> There's no change in this file, this year change can presumably be dropped.

*doh* I used git diff to say which files had changed, but of course I revert that, but it still showed as being changed in the sequence of diffs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2239851856

From acobbs at openjdk.org  Tue Jul 29 14:05:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 29 Jul 2025 14:05:59 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v3]
In-Reply-To: <YlbYD-FOoNlKUBNfcQggO6Chb2Ohzl35uIgfxYoDPIg=.0a27e288-fc8e-4359-a616-3da9067ba8c1@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <EUSuVXSXSnHLJBQlT08JeSKS01lAIulSZ9-N0htugzU=.f69ad7a1-0619-4d42-b0bb-6bd8ffb75303@github.com>
 <kxDfUevhS-AStFMRlspH9WZbXWOKMZF7FsI4Xl_UdmA=.d0819de1-b7f5-48b4-ae9e-6ce9f5280722@github.com>
 <ODJOjp-ETyRVDjC6jqZWFDSv4Eu166SrylVNd_sE79o=.cf76789a-6239-4a3a-8cbc-04702070c514@github.com>
 <fZSzwec4qVxhHyxdoOT5-YPwRFceSV9GxEDhXnFY8NQ=.663c17c4-a380-468c-8aa6-574202f8418b@github.com>
 <UPLLocTtLf2pXwqlYa_HtmrhV1gCQlptlMvWrMSKe5s=.9b87f843-d2bb-4591-a2ac-2c97894796de@github.com>
 <W4wIHQ2Z1fSjcV74AvJEfXCrZmUaLl1hseEWHVHeOks=.4b6fe041-2d8a-4894-8ea7-eb0262ffc84a@github.com>
 <YlbYD-FOoNlKUBNfcQggO6Chb2Ohzl35uIgfxYoDPIg=.0a27e288-fc8e-4359-a616-3da9067ba8c1@github.com>
Message-ID: <AL788_Ovn1ZU2sl3beOo8-Tt9R59aYmZxkHKc5JgdeE=.298c4ec9-fb3e-4237-acbf-403c7b9b42f9@github.com>

On Tue, 29 Jul 2025 09:17:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...
>> 
>> At the start of `checkPotentiallyAmbiguousOverloads()`, we check:
>> 
>> 
>> if (!lint.isEnabled(LintCategory.OVERLOADS))
>>             return;
>> 
>> 
>> Now, I do not see any other code setting this lint. There are a couple of visitors elsewhere that do, but these operations seems rather local. To my eyes, this is check applied to the root lint. Then there's a more subtle check (that I missed) below:
>> 
>> 
>> // Allow site's own declared methods (only) to apply @SuppressWarnings("overloads")
>>         methodGroups.forEach(list -> list.removeIf(
>>             m -> m.owner == site.tsym && !lint.augment(m).isEnabled(LintCategory.OVERLOADS)));
>> 
>> 
>> This "augments" the lint with one of the symbols to check, and removes the symbol if it is annotated with `@SuppressWarnings("overloads")`.
>> 
>> This code seems convoluted, in the sense that you don't really need to augment anything here? The toplevel check looks for enablement, whereas this loop looks for suppression. To implement the latter all you need is to check is a certain category appears suppressed in the given symbol. Note though: if we have a `@SuppressWarnings` on the enclosing class I don't think that will be considered. I will need to test a bit more.
>
>> Move the short-circuited warnings to the `WARN` phase
> 
> This is probably the best, as I suspect that we only shortcircuit in a handful of cases.
> 
> Another approach would be to try an augment lint earlier -- e.g. during `memberEnter`. After all, by that point we have seen the class, and we have seen a method/field symbol, so in principle we might know what suppressions these symbols have. The only thing that would be left after that is stuff inside method bodies (mostly local var declaration, and anon/local inner classes -- but I believe both go through `memberEnter` again, so we should be covered). This would ensure that the mappings are setup as early as possible -- which would allow shortcircuiting logic in `Check` to occur more naturally.
> 
> That said, doing this might have some bootstrapping issues -- @lahodaj any ideas?

> > Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...
> 
> At the start of `checkPotentiallyAmbiguousOverloads()`, we check... Now, I do not see any other code setting this lint.

That method is invoked from `Attr.attribClassBody()`, which is invoked from `Attr.attribClass()`, which invokes `chk.setLint()`, etc. So it does appear to be using a "local" `Lint` instance, right?

But I was missing your larger point - even if we replaced this local `Lint` with `rootLint`, the short circuit check would still be correct, just less precise. In other words, once a Lint category is disabled, it's never possible for it be re-enabled by a nested declaration. So if code is short-circuiting via `if (!lint.isEnabled(FOO)) skip...` then switching from a local lint to `rootLint` is a conservative (safe) change (side note: this wouldn't work for `DEFAULT_ENABLED` warnings, but the few warnings that have that flag are not involved here).

> This code seems convoluted, in the sense that you don't really need to augment anything here? The toplevel check looks for enablement, whereas this loop looks for suppression. To implement the latter all you need is to check is a certain category appears suppressed in the given symbol. Note though: if we have a @SuppressWarnings on the enclosing class I don't think that will be considered. I will need to test a bit more.

This check (overloads) as well as the `"this-escape"` check do "tricky" stuff because they are both examples in which whether the warning is emitted depends on non-local suppression. For some warnings, this is just inherent in what the warning means, invalidating the assumption that a `@SuppressWarnings` annotation always fully "contains" the warnings it might apply to.

For example, a `"this-escape"` warning is suppressed for a _field_ if every primary _constructor_ has `@SuppressWarnings("this-escape")`. This is of course because fields are initiailized when `super()` happens, so control flow jumps around.

In the `"overloads"` case, there is logic to allow "either/or" of the methods to suppress the warning: in other words, the warning is referring to two different methods at the same time, so that brings the question, Which method's `@SuppressWarnings` annotation should apply? The code applies _both_ at the same time in a conservative fashion, meaning either method (or both) may suppress the warning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2239953767

From jlahoda at openjdk.org  Tue Jul 29 15:06:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Jul 2025 15:06:58 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v9]
In-Reply-To: <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
Message-ID: <C7nmXLkKFaOxAgdVP7d9Z7NMZlF0wTHeUECDwhBhiDU=.33946b91-35e4-4e26-936d-3ff378d69a2e@github.com>

On Tue, 29 Jul 2025 13:37:44 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback tweaks.

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25639#pullrequestreview-3068012948

From duke at openjdk.org  Tue Jul 29 17:46:01 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Jul 2025 17:46:01 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v9]
In-Reply-To: <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
Message-ID: <NfJ2-0R9AnQvJYZy6zhuNtSFrJMpD6Z8BTvOG1sG29A=.51743ceb-6f8d-4ef9-878b-262326097402@github.com>

On Tue, 29 Jul 2025 13:37:44 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback tweaks.

@david-beaumont 
Your change (at version b5a428d68b68eaeb9f5eaf8ecff5ba54dfb4fad0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25639#issuecomment-3133460367

From mcimadamore at openjdk.org  Tue Jul 29 17:53:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Jul 2025 17:53:15 GMT
Subject: RFR: 8355204: Consider simplifying type metadata stripping
In-Reply-To: <E66jK4Jc-fGFw6dbr4NHlpmiHNPWYar9sJxn71hE1Ag=.bc27a393-dabc-4035-a902-c425f2f52317@github.com>
References: <E66jK4Jc-fGFw6dbr4NHlpmiHNPWYar9sJxn71hE1Ag=.bc27a393-dabc-4035-a902-c425f2f52317@github.com>
Message-ID: <T2u2Da-trAP0qizRvTvz2FUM9QwtO6_Vz2dwS_06IH8=.b7546e8b-3c00-4305-a4a2-b3e1e55cc831@github.com>

On Mon, 21 Apr 2025 16:41:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change removes support for `stripMetadataIfNeeded`. After [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) there are only two uses of the method:
> 
> * `Types#directSupertypes`, which is specified as preserving type annotations. This change means that type metadata will be preserved for supertypes that appear in source, as well as substituted types for transitive supertypes.
> * `Trees#getTypeMirror`, which doesn't specify whether or not type annotations are preserved.
> 
> `stripMetadataIfNeeded` was added for [JDK-8031744](https://bugs.openjdk.org/browse/JDK-8031744). The unconditional `stripMetadata` was added for [JDK-8144580](https://bugs.openjdk.org/browse/JDK-8144580). `stripMetadata` was substantially reworked to ensure it always stripped annotations in [JDK-8042981](https://bugs.openjdk.org/browse/JDK-8042981), which also updated the spec for Types' utility methods to clarify when type annotations were preserved, added a public API for removing annotations from types, and replaced some calls to `stripMetadataIfNeeded` with `stripMetadata` because the former didn't strip annotations in some cases where stripping was actually needed.
> 
> I think it's worth considering removing `stripMetadataIfNeeded`. The bookkeeping to keep track of whether or not metadata should be stripped is fragile, and the API use-case can be supported by either preserving metadata or unconditionally stripping it.

The comment here:
https://github.com/openjdk/jdk/pull/8984#issuecomment-1166669173

Seems to indicate that a decision was made for `directSupertypes` to retain type annotations (presumably on the basis that such annotations are "declared"). I'm not too sure about that -- if we start from a `TypeElement` `E` and we want to know the `TypeMirror` corresponding to the direct supertype of the mirror associated with that `E`, then it seems ok for the mirror to contain type annotations: after all the mirror represents a type that was declared somewhere in the source code.

But if I want to compute the mirror that is the direct supertypes of `List<@NonNull String>` I'm not sure it's fair game for the supertype mirror to be `Collection<@NonNull String>`. The main point of `stripMetadataIfNeeded` was to strip type annotation whenever javac applied some transformation to a declared type. This was based on the principle that declared types should have their annotations reflected, whereas types _derived_ from declared types (e.g. via substitution) should not contain type annotations.

That said, the PR referenced above introduced new text to say that `Annotations on the direct supertypes are preserved.`. But then I see the code calling `stripMetadataIfNeeded`, so I'm not sure how to reconcile the implementation with the javadoc. @jddarcy can you please clarify what was the desired behavior for `Types::directSupertypes` ? The current implementation will _sometimes_ retain annotations, sometimes not, based on whether the supertype is a derived type or not (see above). If that is the intended behavior, then this PR that drops the conditional stripping will not be ok. But if the intention is for _all_ calls to `directSupertypes` to always retain type annotations, then this PR is ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/24775#issuecomment-3133482962

From mcimadamore at openjdk.org  Tue Jul 29 18:16:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Jul 2025 18:16:01 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
Message-ID: <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>

On Mon, 28 Jul 2025 22:05:44 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor LintMapper to clean up internal type hierarchy per review.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 183:

> 181:     private class FileInfo {
> 182: 
> 183:         final MappedDeclNode rootNode = new MappedDeclNode(rootLint);   // tree of this file's "interesting" declaration nodes

I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl? Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?

Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a `Lint` set. We'd probably still need a map from source files to compilation unit trees)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2240599648

From mcimadamore at openjdk.org  Tue Jul 29 18:16:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Jul 2025 18:16:01 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
Message-ID: <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>

On Tue, 29 Jul 2025 18:10:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor LintMapper to clean up internal type hierarchy per review.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 183:
> 
>> 181:     private class FileInfo {
>> 182: 
>> 183:         final MappedDeclNode rootNode = new MappedDeclNode(rootLint);   // tree of this file's "interesting" declaration nodes
> 
> I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl? Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?
> 
> Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a `Lint` set. We'd probably still need a map from source files to compilation unit trees)

What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2240604282

From acobbs at openjdk.org  Tue Jul 29 18:48:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 29 Jul 2025 18:48:02 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
 <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
Message-ID: <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>

On Tue, 29 Jul 2025 18:12:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?

Remember that the tree of nodes that `LintMapper` builds is sparse - nodes are only created for (a) top-level declarations and (b) nested declarations for which the effective `Lint` is different from the parent, i.e., nested declarations that actually have a material `@SuppressWarnings` annotation.

> I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl?

This is a side-effect of the fact that we need to always create `Decl` nodes for top-level declarations, but for nested declarations we only create them when/if needed, and when we do they are already `MappedDecl` nodes.

So the top-level declaration nodes just under root are "special". They are the only nodes that are ever `Decl` (not-yet-mapped) nodes before transitioning to `MappedDecl` nodes.

> Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?

Given the above, let me know what you think is most appropriate. There are basically three types of nodes: root, non-mapped (top-level only), and mapped. The second type converts from non-mapped to mapped when the declaration is attributed.

> Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a Lint set. We'd probably still need a map from source files to compilation unit trees)

The difficulty in the "finding" is the problem with that idea. Also you'd have to recurse through every node in the AST tree, instead of just the `@SuppressWarnings`-annotated declarations. Right now the "finding" is fast because the tree is sparse.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2240671907

From acobbs at openjdk.org  Tue Jul 29 21:39:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 29 Jul 2025 21:39:47 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v6]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <oR5S75WHcOzPvVWHB9maytX7NmbzTZGe9gHRvRIJmDc=.2321173f-226a-4d47-9732-ab57090990ad@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  More refactoring to simplify LintMapper per review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/f65e1950..147cb2dc

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

  Stats: 86 lines in 1 file changed: 15 ins; 28 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Tue Jul 29 21:39:48 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 29 Jul 2025 21:39:48 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
 <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
 <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>
Message-ID: <PgUagBUnbsM96BOURpVDWndbjZWOnPEUPWzK5lKI0Gs=.a8066485-a8d8-4d59-a213-725f66351c2c@github.com>

On Tue, 29 Jul 2025 18:45:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?
>
>> What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?
> 
> Remember that the tree of nodes that `LintMapper` builds is sparse - nodes are only created for (a) top-level declarations and (b) nested declarations for which the effective `Lint` is different from the parent, i.e., nested declarations that actually have a material `@SuppressWarnings` annotation.
> 
>> I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl?
> 
> This is a side-effect of the fact that we need to always create `Decl` nodes for top-level declarations, but for nested declarations we only create them when/if needed, and when we do they are already `MappedDecl` nodes.
> 
> So the top-level declaration nodes just under root are "special". They are the only nodes that are ever `Decl` (not-yet-mapped) nodes before transitioning to `MappedDecl` nodes.
> 
>> Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?
> 
> Given the above, let me know what you think is most appropriate. There are basically three types of nodes: root, non-mapped (top-level only), and mapped. The second type converts from non-mapped to mapped when the declaration is attributed.
> 
>> Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a Lint set. We'd probably still need a map from source files to compilation unit trees)
> 
> The difficulty in the "finding" is the problem with that idea. Also you'd have to recurse through every node in the AST tree, instead of just the `@SuppressWarnings`-annotated declarations. Right now the "finding" is fast because the tree is sparse.

By the way, I have to agree with you that the code in `LintMapper` is still more confusing than necessary.

I've done another pass to clean it up; please see if 147cb2dc30a looks better. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2241067770

From achung at openjdk.org  Wed Jul 30 01:59:10 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 01:59:10 GMT
Subject: Integrated: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <SikYgrKEa81qT9eL-M4o94o8JAkVv3CyZAuk2iHi9-Q=.da234125-164d-4bbb-992a-73182fa5a8e9@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

This pull request has now been integrated.

Changeset: c671089d
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc
Stats:     90 lines in 14 files changed: 71 ins; 9 del; 10 mod

8364089: JDK 25 RDP2 L10n resource files update

Reviewed-by: jlu, naoto, dnguyen, asemenyuk

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

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

From achung at openjdk.org  Wed Jul 30 02:19:34 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 02:19:34 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update
Message-ID: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>

8364089: JDK 25 RDP2 L10n resource files update

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

Commit messages:
 - Backport c671089d6e9aa147ffd056a83c84abf6aff444dc

Changes: https://git.openjdk.org/jdk/pull/26543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364089
  Stats: 90 lines in 14 files changed: 71 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26543/head:pull/26543

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

From haosun at openjdk.org  Wed Jul 30 06:04:55 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 30 Jul 2025 06:04:55 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <4Mxnjj-pjt-LP4gFxL8HMA5805Nam6TbotfFsuC5Oj8=.65109ba8-508a-4674-9d32-82ec1b2fd80f@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

### some details

JDK source: master
jtreg version: `8+2` version
JDK build: `fastdebug`
OS: `ubuntu 24.04`
two jtreg test cases

test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java

how to reproduce:

make test TEST="test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java"
make test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java


### the snippet of error log for case `TestSPISigned.java` on AArch64


STDERR:                                                                                                                                                                                                                                                      
java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-calendar-provider/TestSPISigned.d/../provider/.                   
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)                                   
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:57)
        at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:161)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.base/java.nio.file.Files.readAttributes(Files.java:1702)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:216)                                                                                                                                                                     
        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:268)   
        at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:306)                                                                                                                                                                              
        at java.base/java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:69)                                          
        at java.base/java.nio.file.Files.find(Files.java:3649)                                                                
        at jdk.test.lib.util.JarUtils.findAllRegularFiles(JarUtils.java:425)                                                                                                                                                                                 
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:75)                                                         
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:106)                                                        
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:115)                                                        
        at TestSPISigned.main(TestSPISigned.java:84)                                                                                                                                                                                                         
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)              
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)                                                         
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)                                                                                                                                                            at java.base/java.lang.Thread.run(Thread.java:1474)
                                                                                                                                                                                                                                                             
JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException                                                     
JavaTest Message: shutting down test                 
                                                               
                                                                                                                                                                                                                                                             
TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-cal
endar-provider/TestSPISigned.d/../provider/.
--------------------------------------------------
Test results: failed: 1

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3134956713

From mcimadamore at openjdk.org  Wed Jul 30 11:59:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 11:59:57 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <PgUagBUnbsM96BOURpVDWndbjZWOnPEUPWzK5lKI0Gs=.a8066485-a8d8-4d59-a213-725f66351c2c@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
 <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
 <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>
 <PgUagBUnbsM96BOURpVDWndbjZWOnPEUPWzK5lKI0Gs=.a8066485-a8d8-4d59-a213-725f66351c2c@github.com>
Message-ID: <ZD5j7z-t25c6Ki7SAQ6GuOgoXSM996Hdfv-SF07Ummw=.fca285fd-b2d0-4a40-b494-9c759c521a6e@github.com>

On Tue, 29 Jul 2025 21:36:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?
>> 
>> Remember that the tree of nodes that `LintMapper` builds is sparse - nodes are only created for (a) top-level declarations and (b) nested declarations for which the effective `Lint` is different from the parent, i.e., nested declarations that actually have a material `@SuppressWarnings` annotation.
>> 
>>> I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl?
>> 
>> This is a side-effect of the fact that we need to always create `Decl` nodes for top-level declarations, but for nested declarations we only create them when/if needed, and when we do they are already `MappedDecl` nodes.
>> 
>> So the top-level declaration nodes just under root are "special". They are the only nodes that are ever `Decl` (not-yet-mapped) nodes before transitioning to `MappedDecl` nodes.
>> 
>>> Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?
>> 
>> Given the above, let me know what you think is most appropriate. There are basically three types of nodes: root, non-mapped (top-level only), and mapped. The second type converts from non-mapped to mapped when the declaration is attributed.
>> 
>>> Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a Lint set. We'd probably still need a map from source files to compilation unit trees)
>> 
>> The difficulty in the "finding" is the problem with that idea. Also you'd have to recurse through every node in the AST tree, instead of just the `@SuppressWarnings`-annotated declarations. Right now the "finding" is fast because the tree is sparse.
>
> By the way, I have to agree with you that the code in `LintMapper` is still more confusing than necessary.
> 
> I've done another pass to clean it up; please see if 147cb2dc30a looks better. Thanks.

Thanks for the comments -- mapped declarations are indeed sparse as you point out, and this might simplify the "position matching" process. However, the unmapped declarations are not sparse. It is true that, after Attr, we will go through the list of unmapped decls and remove them as we map them. But, after parsing the list of unmapped declaration does seem a copy of an AST.

Say you kept _mapped_ declaration as they are now. Can the list of _unmapped_ declaration just be replaced by the compilation unit tree? Or, maybe, a "list of declaration trees" to analyze? It is unclear to me what added value the unmapped data structure has compared to just an AST node. The only thing it adds are the "contains" methods -- which could be implemented as static methods in TreeInfo perhaps?

Also, I don't get the subclassing between `Decl` and `MappedDecl`. They seem to serve quite different purposes -- the former is essentially a *flat* "todo list", whereas the latter is a proper tree-based representation, with parent/child edges. I'm not even sure any client can call methods on a `Decl` when in reality the object could be a `MappedDecl` ?

My concrete suggestion here would be to:

* either just remove `Decl` and use `JCTree`s instead (and put `contains` methods in `TreeInfo`, as they might be useful), or create a small record around `JCTree` (and define `contains` methods in that record).
* when we create a `FileInfo`, we already know, from the start, what the list of "todo" trees/decls are
* then we have mapped declarations; here you have a node that can have many children nodes, using some kind of "delta encoding" (e.g. a child is there only if its lint is different and interesting, otherwise we just use the parent). I think the current class you have (`MappedDecl`) + the builder/scanner you have works well here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2242389055

From mcimadamore at openjdk.org  Wed Jul 30 11:59:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 11:59:58 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v6]
In-Reply-To: <oR5S75WHcOzPvVWHB9maytX7NmbzTZGe9gHRvRIJmDc=.2321173f-226a-4d47-9732-ab57090990ad@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <oR5S75WHcOzPvVWHB9maytX7NmbzTZGe9gHRvRIJmDc=.2321173f-226a-4d47-9732-ab57090990ad@github.com>
Message-ID: <6B6ZvvizIU9sR8xOEJjSF_5U20vzeas9PbUtE7GPbK8=.c619d6c6-ab51-4128-87ce-f36385a1fd2f@github.com>

On Tue, 29 Jul 2025 21:39:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More refactoring to simplify LintMapper per review.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 356:

> 354: 
> 355:             // If this declaration is not "interesting", we don't need to create a MappedDecl for it
> 356:             if (lint == previousLint && parent.parent != null) {

Does this mean we create a mapped decl for all toplevel decls in a file (even if their `lint` is not interesting) ? Why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2242392260

From jlahoda at openjdk.org  Wed Jul 30 12:36:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Jul 2025 12:36:57 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v9]
In-Reply-To: <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <_xMIZzjR1-E0h1xufJRBGWM3rmRles9zE2W4UNT_i7E=.716fc3c3-ac94-46dc-aaad-e33a8fac8ec4@github.com>
Message-ID: <-cEKhfBi1UZQo_bL1OI7B9LUOeHtFioyXbq8USEVK9A=.90a08b4c-f2d7-4752-8e53-4bc001cd1c92@github.com>

On Tue, 29 Jul 2025 13:37:44 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback tweaks.

I am afraid this patch fails (for me, at least) when doing `make images`, as it cannot compile the JRTFS using the bootstrap JDK. We will probably need some more tweaks. Sorry for the noise.

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

Changes requested by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25639#pullrequestreview-3071262396

From acobbs at openjdk.org  Wed Jul 30 15:54:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 15:54:45 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v7]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  More simplification of LintMapper per review suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/147cb2dc..6a1289e9

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

  Stats: 114 lines in 2 files changed: 27 ins; 35 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Wed Jul 30 15:54:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 15:54:45 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <ZD5j7z-t25c6Ki7SAQ6GuOgoXSM996Hdfv-SF07Ummw=.fca285fd-b2d0-4a40-b494-9c759c521a6e@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
 <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
 <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>
 <PgUagBUnbsM96BOURpVDWndbjZWOnPEUPWzK5lKI0Gs=.a8066485-a8d8-4d59-a213-725f66351c2c@github.com>
 <ZD5j7z-t25c6Ki7SAQ6GuOgoXSM996Hdfv-SF07Ummw=.fca285fd-b2d0-4a40-b494-9c759c521a6e@github.com>
Message-ID: <Bx1Qx5OjDWpYIoRu69kdP-AXsH3vPcCJ8IPpG3l4GKw=.d8201e71-6995-4593-910a-c6de0ac88218@github.com>

On Wed, 30 Jul 2025 11:56:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Thanks for the comments -- mapped declarations are indeed sparse as you point out, and this might simplify the "position matching" process. However, the unmapped declarations are not sparse.

There number of unmapped declarations equals the number of top-level class, package, or module declarations. I'm describing this as "sparse" because it does not include any methods, variables or nested classes. But of course if you're considering only top-level declarations then it's not "sparse" with respect to just that set.

> It is true that, after Attr, we will go through the list of unmapped decls and remove them as we map them. But, after parsing the list of unmapped declaration does seem a copy of an AST.

It's only a copy of the AST to a depth of one... so really a list, not a tree... but regardless, I think you have a good point (see below)...

> Say you kept _mapped_ declaration as they are now. Can the list of _unmapped_ declaration just be replaced by the compilation unit tree? Or, maybe, a "list of declaration trees" to analyze?

To restate your question: What value does storing a list of `Decl`'s provide over just storing a list of the corresponding original `JCTree` objects? There are two reasons I did this:
1. If we just store the `JCTree`'s, then we also must retain a reference to every source file's `EndPosTable` (it's required by `MappedDeclBuilder`), which I was trying to avoid because, at least in some cases (depending on compiler configuration), those tables are (otherwise) discarded after parsing. So the new references to `EndPosTable` will increase compiler memory usage. But I may have been overreacting or misunderstanding that.
2. This is a minor detail, but the `JCTree` we see after parsing is not always the same `JCTree` we see after attribution (not sure why; it happens in test method `EdgeCases.testWrongPackageInExportedPackage()` for some reason). So even if we store the trees, we still have to compare them by position, not object equality, so in effect it's really the position we care about, not the tree...

> Does this mean we create a mapped decl for all toplevel decls in a file (even if their lint is not interesting) ? Why?

Yes, but! That special case is no longer required with the recent cleanups, so now we can fix this too :)

> My concrete suggestion here would be to...

Thanks, this makes things simpler and cleaner. Should all be done in 6a1289e9372.

Thanks again for your thoughtful review and comments!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2243146877

From jpai at openjdk.org  Wed Jul 30 16:29:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 16:29:54 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Hello Hao,

> Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3137036826

From jlu at openjdk.org  Wed Jul 30 16:40:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Jul 2025 16:40:55 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <xkhUaFN8y_xbnUnDkDFSqVxm7fODAoEdtDXUscBaC8M=.d2699526-2397-4477-889a-ebf18486b1b8@github.com>

On Wed, 30 Jul 2025 02:12:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8364089: JDK 25 RDP2 L10n resource files update

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties line 139:

> 137: doclet.Preview_Label=Vorschau
> 138: doclet.Preview_Mark=PREVIEW
> 139: doclet.Preview_Notes=Hinweise zur Vorschau-API

The changes in this group of localized files should not be making it into JDK25 as the associated change to the original file made it into 26 and was not backported to 25.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26543#discussion_r2243282750

From mcimadamore at openjdk.org  Wed Jul 30 17:01:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 17:01:57 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v5]
In-Reply-To: <Bx1Qx5OjDWpYIoRu69kdP-AXsH3vPcCJ8IPpG3l4GKw=.d8201e71-6995-4593-910a-c6de0ac88218@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <rvD5LYXr4-09Q0xUfjAiKQfdJqLsu_XW1JEE56tcWqk=.21178ec0-a292-4926-94d9-2b83109c0ead@github.com>
 <kpIjcQ13vdSGL-dK03RLdUsLSFrEa8sz1CKkIGXJCvY=.51b0cdbd-c10f-4602-8031-53e6c4d9e076@github.com>
 <Ml2IkbITIMyKtlmHHGobFH3Uvixz-sOkuJ2iPK6HB5k=.2dc8bed9-8db3-4e8a-9fdf-732cc36ee5cc@github.com>
 <ARJ2-4xTvJvLH_tMePz9qGASy1Lwe0lbXMC37-zsWo0=.ad737d8a-4a4f-4430-8a28-a1f12694b620@github.com>
 <PgUagBUnbsM96BOURpVDWndbjZWOnPEUPWzK5lKI0Gs=.a8066485-a8d8-4d59-a213-725f66351c2c@github.com>
 <ZD5j7z-t25c6Ki7SAQ6GuOgoXSM996Hdfv-SF07Ummw=.fca285fd-b2d0-4a40-b494-9c759c521a6e@github.com>
 <Bx1Qx5OjDWpYIoRu69kdP-AXsH3vPcCJ8IPpG3l4GKw=.d8201e71-6995-4593-910a-c6de0ac88218@github.com>
Message-ID: <TNcqwY4OqWprX9iJXJyPt-gJtYsl2bQW7xyKIU-xwGA=.3ee2344b-a8df-4dd4-91e3-1731a084f1f1@github.com>

On Wed, 30 Jul 2025 15:51:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Thanks for the comments -- mapped declarations are indeed sparse as you point out, and this might simplify the "position matching" process. However, the unmapped declarations are not sparse. It is true that, after Attr, we will go through the list of unmapped decls and remove them as we map them. But, after parsing the list of unmapped declaration does seem a copy of an AST.
>> 
>> Say you kept _mapped_ declaration as they are now. Can the list of _unmapped_ declaration just be replaced by the compilation unit tree? Or, maybe, a "list of declaration trees" to analyze? It is unclear to me what added value the unmapped data structure has compared to just an AST node. The only thing it adds are the "contains" methods -- which could be implemented as static methods in TreeInfo perhaps?
>> 
>> Also, I don't get the subclassing between `Decl` and `MappedDecl`. They seem to serve quite different purposes -- the former is essentially a *flat* "todo list", whereas the latter is a proper tree-based representation, with parent/child edges. I'm not even sure any client can call methods on a `Decl` when in reality the object could be a `MappedDecl` ?
>> 
>> My concrete suggestion here would be to:
>> 
>> * either just remove `Decl` and use `JCTree`s instead (and put `contains` methods in `TreeInfo`, as they might be useful), or create a small record around `JCTree` (and define `contains` methods in that record).
>> * when we create a `FileInfo`, we already know, from the start, what the list of "todo" trees/decls are
>> * then we have mapped declarations; here you have a node that can have many children nodes, using some kind of "delta encoding" (e.g. a child is there only if its lint is different and interesting, otherwise we just use the parent). I think the current class you have (`MappedDecl`) + the builder/scanner you have works well here.
>
>> Thanks for the comments -- mapped declarations are indeed sparse as you point out, and this might simplify the "position matching" process. However, the unmapped declarations are not sparse.
> 
> There number of unmapped declarations equals the number of top-level class, package, or module declarations. I'm describing this as "sparse" because it does not include any methods, variables or nested classes. But of course if you're considering only top-level declarations then it's not "sparse" with respect to just that set.
> 
>> It is true that, after Attr, we will go through the list of unmapped decls and remove them as we map them. But, after parsing the list of unmapped declaration does seem a copy of an AST.
> 
> It's only a copy of the AST to a depth of one... so really a list, not a tree... but regardless, I think you have a good point (see below)...
> 
>> Say you kept _mapped_ declaration as they are now. Can the list of _unmapped_ declaration just be replaced by the compilation unit tree? Or, maybe, a "list of declaration trees" to analyze?
> 
> To restate your question: What value does storing a list of `Decl`'s provide over just storing a list of the corresponding original `JCTree` objects? There are two reasons I did this:
> 1. If we just store the `JCTree`'s, then we also must retain a reference to every source file's `EndPosTable` (it's required by `MappedDeclBuilder`), which I was trying to avoid because, at least in some cases (depending on compiler configuration), those tables are (otherwise) discarded after parsing. So the new references to `EndPosTable` will increase compiler memory usage. But I may have been overreacting or misunderstanding that.
> 2. This is a minor detail, but the `JCTree` we see after parsing is not always the same `JCTree` we see after attribution (not sure why; it happens in test method `EdgeCases.testWrongPackageInExportedPackage()` for some reason). So even if we store the trees, we still have to compare them by position, not object equality, so in effect it's really the position we care about, not the tree...
> 
>> Does this mean we create a mapped decl for all toplevel decls in a file (even if their lint is not interesting) ? Why?
> 
> Yes, but! That special case is no longer required with the recent cleanups, so now we can fix this too :)
> 
>> My concrete suggestion here would be to...
> 
> Thanks, this makes things simpler and cleaner. Should all be done in 6a1289e9372.
> 
> Thanks again for your thoughtful review and comments!

The new code looks clearer to follow. What we really want is:
* first, capture only the "spans" of toplevel declarations
* then, after attr, organize all these spans into some kind of tree structure that optimizes the search

If you are worried about holding onto the end pos table too long (I don't have strong opinion on this), I'm ok with using some kind of "span" class to model... a span -- but that class should be completely disconnected from the `MappedDecl` class (which was really my main point).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2243339408

From mcimadamore at openjdk.org  Wed Jul 30 17:06:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 17:06:58 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v7]
In-Reply-To: <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>
Message-ID: <vzkfqDujW1X4o5g7z2gfL_2M_K2Ry6WLqKpL1YutTTQ=.245fcfc7-5f63-46c1-bf1b-da483c783869@github.com>

On Wed, 30 Jul 2025 15:54:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More simplification of LintMapper per review suggestions.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 242:

> 240:     private static class MappedDecl {
> 241: 
> 242:         final int startPos;                                     // declaration's lexical starting position

Better idea. Have a record class called `Span` which has start/end pos. Then, in `FileInfo` we keep track of a list of these `Span`s. And, after attr, we "add" each span to the MappedDecl structure. The MappedDecl class will have itself a little Span object inside which can be used for all the positional queries. E.g. use delegation/aggregation, instead of subtyping (as, after all, a `MappedDecl` is really not a span -- but has a span).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2243351077

From mcimadamore at openjdk.org  Wed Jul 30 17:13:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 17:13:03 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v7]
In-Reply-To: <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>
Message-ID: <TDm--3yrX677bq7ZpFMnp_J88g395xkEcLTnmURyz7M=.f4b9302e-7633-4a2f-ab03-dc64a3e2779b@github.com>

On Wed, 30 Jul 2025 15:54:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More simplification of LintMapper per review suggestions.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 299:

> 297:      * The tree is sparse: only declarations that differ from their parent are included.
> 298:      */
> 299:     private static class MappedDeclBuilder extends TreeScanner {

Another (maybe picky) comment: to my eyes, `MappedDeclBuilder` is really a mutable data structure. It has operations to find nodes, but it doesn't provide operation to _add_ new nodes. Instead the _add_ operation is delegated to this builder class.

Now, I totally understand that the process of adding a new entry to `MappedDecl` is complex, and you need to scan a tree to get there. That's all good. But I think you do want an `add(Span, JCTree)` to `MappedDecl` which can then be used inside `FileInfo::afterAttr`. The fact that the implementation of this `add` method is defined in terms of a tree scanner is an impl detail that doesn't need to be known outside the `add` method (and you can in fact turn the scanner into a local class, and then have the visitor create a new scanner, and process the provided tree with it. This should encapsulate the data structure modelled by `MappedDecl` even more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2243364077

From achung at openjdk.org  Wed Jul 30 19:34:17 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 19:34:17 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>

> 8364089: JDK 25 RDP2 L10n resource files update

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert files with changes that didn't get backported

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26543/files
  - new: https://git.openjdk.org/jdk/pull/26543/files/40ddea4d..b9c25798

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

  Stats: 12 lines in 3 files changed: 3 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26543/head:pull/26543

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

From acobbs at openjdk.org  Wed Jul 30 20:39:46 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 20:39:46 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v8]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <wnVbOF2kznBKmANeWqqazii4c6v28BQgkC3bqrsIOfM=.a05ca782-a8e6-4ef6-8ebc-740db5429801@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  More simplification of LintMapper per review suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/6a1289e9..d1adde49

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

  Stats: 177 lines in 2 files changed: 40 ins; 70 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Wed Jul 30 20:39:48 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 20:39:48 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v7]
In-Reply-To: <vzkfqDujW1X4o5g7z2gfL_2M_K2Ry6WLqKpL1YutTTQ=.245fcfc7-5f63-46c1-bf1b-da483c783869@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <Xy50sUjr3ol3esJL8F36wMs5urpY0fT3ENhy8HryMQY=.7a1331dc-1c32-41bd-b017-e18ecf79a3d7@github.com>
 <vzkfqDujW1X4o5g7z2gfL_2M_K2Ry6WLqKpL1YutTTQ=.245fcfc7-5f63-46c1-bf1b-da483c783869@github.com>
Message-ID: <8rEIxvjnKLeh1hdXLpOYsuOijDmHp_9gkXzoHQXPdXY=.47a1091b-4899-436e-b98f-3a948447f525@github.com>

On Wed, 30 Jul 2025 17:04:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Better idea. Have a record class called `Span` which has start/end pos. Then...

Yeah that's a little more correct in terms of the data model.

> Another (maybe picky) comment: to my eyes...

Sure, that's easy enough to do. Also allows us to eliminate a couple more fields.

Should be done in d1adde49247.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2243808019

From jlu at openjdk.org  Wed Jul 30 20:42:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Jul 2025 20:42:59 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
 <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
Message-ID: <wRuz7ThyKzfYGvsVEpePVOHrbwJfN7_xfIJhvAR3dDo=.b11192bf-411c-4986-ba1b-3d4faeddfb57@github.com>

On Wed, 30 Jul 2025 19:34:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
>> 
>> Thanks!
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert files with changes that didn't get backported

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26543#pullrequestreview-3073281940

From acobbs at openjdk.org  Wed Jul 30 21:03:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 21:03:45 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v9]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <NHxVbBp09SP86Um38KKLdrg2rWTMiB5q6WecFoS4KyM=.0e593561-8ad1-4207-9142-e02f9a6fbd37@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove an unnecessary field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/d1adde49..7fca4a05

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

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

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

From mcimadamore at openjdk.org  Wed Jul 30 21:18:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Jul 2025 21:18:00 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v9]
In-Reply-To: <NHxVbBp09SP86Um38KKLdrg2rWTMiB5q6WecFoS4KyM=.0e593561-8ad1-4207-9142-e02f9a6fbd37@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <NHxVbBp09SP86Um38KKLdrg2rWTMiB5q6WecFoS4KyM=.0e593561-8ad1-4207-9142-e02f9a6fbd37@github.com>
Message-ID: <1mzpiGo4BSwuqjOfUFTT6SiwHbXohMkOkUTIfT0gVIk=.23692b9c-3aa7-4870-b5b0-4c1c1d4424e2@github.com>

On Wed, 30 Jul 2025 21:03:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove an unnecessary field.

Thanks for addressing all my comments, I like the last version a lot. I consider this PR approved, but I'll bump the reviewer number to 2, so that others (@lahodaj ?) can take a look.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3073360528

From acobbs at openjdk.org  Wed Jul 30 21:21:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Jul 2025 21:21:58 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v9]
In-Reply-To: <NHxVbBp09SP86Um38KKLdrg2rWTMiB5q6WecFoS4KyM=.0e593561-8ad1-4207-9142-e02f9a6fbd37@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <NHxVbBp09SP86Um38KKLdrg2rWTMiB5q6WecFoS4KyM=.0e593561-8ad1-4207-9142-e02f9a6fbd37@github.com>
Message-ID: <jtinjR35yqW0w3rHDQ2Wdw9e3zb3svhtkEZ7HF1x3fQ=.c1788c9a-1429-4b0b-bc47-9357983bcde8@github.com>

On Wed, 30 Jul 2025 21:03:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove an unnecessary field.

Thanks for your review and all the help along the way :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3137850459

From naoto at openjdk.org  Wed Jul 30 21:57:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Jul 2025 21:57:57 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
 <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
Message-ID: <EsCNsZwCZSiVF06M0mhsDC0dovp2YHOo2W4MvT-M_m8=.0ba284f8-a0f3-46dc-9c31-1243ce6a0827@github.com>

On Wed, 30 Jul 2025 19:34:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
>> 
>> Thanks!
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert files with changes that didn't get backported

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26543#pullrequestreview-3073437019

From achung at openjdk.org  Wed Jul 30 22:55:02 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 22:55:02 GMT
Subject: [jdk25] Integrated: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <LGiHCy9E61ZKaey8M3fWSKAZGqtheCIZSsXvLVea8tQ=.e89ade9a-b054-4e01-8f45-970e9085e511@github.com>

On Wed, 30 Jul 2025 02:12:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bf31e507
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf31e507541a8e4a352da09d0a13a8356f78a1eb
Stats:     78 lines in 11 files changed: 68 ins; 6 del; 4 mod

8364089: JDK 25 RDP2 L10n resource files update

Reviewed-by: jlu, naoto
Backport-of: c671089d6e9aa147ffd056a83c84abf6aff444dc

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

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

From duke at openjdk.org  Thu Jul 31 09:09:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 31 Jul 2025 09:09:57 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v10]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <w1aIR8J8hyKGWhr1310DQyxe8iKl-bUT4jE2ecWaOuM=.bbfe3c01-f00b-49b5-a66e-0443ab3ff643@github.com>

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Disable assertion until JDK 25 is bootstrap JRE.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/b5a428d6..5d73c327

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

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

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

From egor.ushakov at jetbrains.com  Thu Jul 31 12:38:29 2025
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Thu, 31 Jul 2025 14:38:29 +0200
Subject: lambda method naming changes in jdk 24
In-Reply-To: <07750800-6bca-46c4-b480-f360dc06d650@oracle.com>
References: <71f259c7-a64e-4550-ae4d-b28b8ed0c792@jetbrains.com>
 <07750800-6bca-46c4-b480-f360dc06d650@oracle.com>
Message-ID: <c39657f5-c4e8-47cb-8847-0b5ddae52eaf@jetbrains.com>

Thanks for the details, we'll try to fix it on IDEA side.

Egor

On 7/14/2025 11:32 PM, Maurizio Cimadamore wrote:
>
> Hi Egor,
> I confirm that this change is deliberate. There were several changes 
> required to make JEP 513 (Flexible Constructor Bodies) work. Some of 
> these changes resulted in significant rewrites of the compiler backend 
> (to move lambda translation ahead of inner class translation). The 
> bulk of the work (and some history) is here:
>
> https://github.com/openjdk/jdk/pull/19836
>
> This change created some compatibility issues for serializable 
> lambdas, which were later addressed here:
>
> https://github.com/openjdk/jdk/pull/20349
>
> This latter change dropped a lot of accidental complexity from the 
> javac LambdaToInner pass, and that meant making the logic for 
> computing the names serializable and non-serializable lambdas more robust.
>
> This meant that, unfortunately, the (unspecified) name of some 
> non-serializable lambda changed. This compatibility issue is described 
> in the associated CSR:
>
> https://bugs.openjdk.org/browse/JDK-8337558
>
> The difference you see is caused by when the name of the translated 
> lambda method is generated -- it used to be computed _after_ the end 
> of the lambda body, now it is computed _before_.? This means that as 
> soon as we see the outermost lambda for `r3` we give it the first 
> number -- then the nested lambda for `r4` gets the second number.
>
> This allows us to avoid having to "patch" the names of the translated 
> symbols, which minimizes the amount of mutation in our code, making it 
> less brittle. So, unless there's a big reason as to why these names 
> should go back the way they were, we'd like to keep the code the way 
> it is :-)
>
> Cheers
> Maurizio
>
> On 11/07/2025 16:08, Egor Ushakov wrote:
>> Hi everyone!
>>
>> it looks like in jdk 24 compiler started naming lambda methods 
>> slightly differently,
>> consider the code:
>> public class Lambdas1 {
>>      public static void main(String[]args) {
>>          Runnable r3 = () -> {
>>              Runnable r4 = () ->System.out.println(new Exception().getStackTrace()[0]);
>>              r4.run();
>>              System.out.println(new Exception().getStackTrace()[0]);
>>          };
>>          r3.run();
>>      }
>> }
>>
>> with jdk 23 the output is:
>> Lambdas1.lambda$main$*0*(Lambdas1.java:7)
>> Lambdas1.lambda$main$*1*(Lambdas1.java:9)
>>
>> with jdk 24:
>> Lambdas1.lambda$main$*1*(Lambdas1.java:4)
>> Lambdas1.lambda$main$*0*(Lambdas1.java:6)
>>
>> I know that this is not specified anywhere, but Intellij IDEA relied 
>> on this and it caused issues with debugger features:
>> https://youtrack.jetbrains.com/issue/IDEA-375811
>>
>> Was this change really intended? Could anyone please point me to the 
>> fix that caused this?
>>
>> Thanks!
>> Egor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250731/fb8d675b/attachment.htm>

From acobbs at openjdk.org  Thu Jul 31 14:24:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 31 Jul 2025 14:24:35 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v8]
In-Reply-To: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
Message-ID: <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>

> This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred.
> 
> A few notes:
> * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur.
> * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect.
> * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented.
> * A few minor cleanups are included

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
 - Ensure that "-Xlint:none" still works for the affected warnings.
   
   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
   which allowed the affected warnings to get away with skipping that check.
 - Minor naming and Javadoc tweaks.
 - Merge branch 'JDK-8359596' into JDK-8349847
 - No need for /nodynamiccopyright/ with this test.
 - Restore behavior when both -Xlint:options and -Xlint:-options are given.
 - Merge branch 'master' into JDK-8349847
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5f357fa2...2bdc2ab0

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

Changes: https://git.openjdk.org/jdk/pull/23622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23622&range=07
  Stats: 228 lines in 15 files changed: 152 ins; 35 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/23622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23622/head:pull/23622

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