From jlahoda at openjdk.org Mon Sep 1 05:57:51 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 1 Sep 2025 05:57:51 GMT Subject: Integrated: 8177650: JShell tool: packages in classpath don't appear in completions In-Reply-To: References: Message-ID: <5adI4-XiRbIbljX36NB6Hl5rQ9u7LcFGAyxsZVxvJpo=.2ba4eb7c-a545-46e0-b06e-ad37c940e753@github.com> On Fri, 4 Jul 2025 17:32:38 GMT, Jan Lahoda 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 This pull request has now been integrated. Changeset: 28942406 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/28942406020881be79b7543105b9eb2a0dda429e Stats: 373 lines in 5 files changed: 340 ins; 23 del; 10 mod 8177650: JShell tool: packages in classpath don't appear in completions Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/26137 From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth 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: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References:

Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References:

Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References:

Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From duke at openjdk.org Tue Sep 2 00:54:58 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Sep 2025 00:54:58 GMT Subject: Withdrawn: 8347291: Exhaustive switch over a generic sealed abstract class In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 01:08:56 GMT, Liam Miller-Cushon 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23286 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From jlahoda at openjdk.org Wed Sep 3 05:54:31 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 Sep 2025 05:54:31 GMT Subject: RFR: 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Message-ID: Consider a very broken declaration like this: void test(List<@AlphaChars <@StringLength(int value = 5)String> s){ after seeing `@AlphaChars`, javac will try to parse `<@StringLength(int value = 5)String>` as a type, and assign the annotation to the type. But, the text does not parse as a type well (partly due to the `int value = 5`), and the parsing will proceed in an expression mode. Then a search for target type is performed to attach the annotation, and that fails, as the expression tree is not expected to be part of the type. The main proposal here is to wrap the badly parsed type in an `Erroneous` tree. The overall error recovery then seems to handle the situation well. The situation produces quite a few error reports, but it is not clear if this situation (esp. the nested `int value = 5`) is common enough to stretch the parsing error recovery capabilities to accommodate this code. ------------- Commit messages: - Adding more tests and a comment. - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Changes: https://git.openjdk.org/jdk/pull/27065/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27065&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351260 Stats: 92 lines in 3 files changed: 90 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27065.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27065/head:pull/27065 PR: https://git.openjdk.org/jdk/pull/27065 From syan at openjdk.org Wed Sep 3 07:28:20 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 07:28:20 GMT Subject: RFR: 8366582: Problemlist jdk/jshell/ToolSimpleTest.java Message-ID: Hi all, Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. ------------- Commit messages: - 8366582: Problemlist jdk/jshell/ToolSimpleTest.java Changes: https://git.openjdk.org/jdk/pull/27066/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27066&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366582 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27066.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27066/head:pull/27066 PR: https://git.openjdk.org/jdk/pull/27066 From jlahoda at openjdk.org Wed Sep 3 09:00:42 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 Sep 2025 09:00:42 GMT Subject: RFR: 8366768: Problemlist jdk/jshell/ToolSimpleTest.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 07:23:01 GMT, SendaoYan wrote: > Hi all, > > Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. Looks good to me - thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27066#pullrequestreview-3179661866 From mcimadamore at openjdk.org Wed Sep 3 09:49:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 3 Sep 2025 09:49:47 GMT Subject: RFR: 8365676: javac incorrectly allows calling interface static method via type variable In-Reply-To: References: Message-ID: <55UyC_qFFghp_fxg7oVtMk6_R6zMICrikszIO0HtIJ0=.40ab454b-e658-4356-b06f-ab548af2a946@github.com> On Sat, 30 Aug 2025 00:37:44 GMT, Chen Liang wrote: > The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9: > >> The members of an intersection type are the members of the class or interface it induces. > > Combined with JLS 4.4: > >> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([?4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared > > Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8. > > The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator` be able to do so. > > In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4577: > 4575: // 1. Private members > 4576: // 2. Interface static methods > 4577: Symbol sym2 = sym.isPrivate() Code is good, but please break up the big conditional ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27015#discussion_r2318416548 From mcimadamore at openjdk.org Wed Sep 3 09:56:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 3 Sep 2025 09:56:42 GMT Subject: RFR: 8365676: javac incorrectly allows calling interface static method via type variable In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 00:37:44 GMT, Chen Liang wrote: > The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9: > >> The members of an intersection type are the members of the class or interface it induces. > > Combined with JLS 4.4: > >> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([?4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared > > Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8. > > The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator` be able to do so. > > In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test. The fix is correct, and mimics a fix that I made several years ago :-) https://hg.openjdk.org/jdk9/jdk9/langtools/rev/4d2d8b6459e1 I'd suggest to add a test with a type variable with intersection type bound, just for good measure, ------------- PR Review: https://git.openjdk.org/jdk/pull/27015#pullrequestreview-3179877224 From liach at openjdk.org Wed Sep 3 12:53:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 12:53:48 GMT Subject: RFR: 8365676: javac incorrectly allows calling interface static method via type variable In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 09:53:40 GMT, Maurizio Cimadamore wrote: > I'd suggest to add a test with a type variable with intersection type bound, just for good measure Sure. One with bound `T extends Object & Comparator` would definitely better showcase the JLS rules without the fix, as this is already correct. Do you think I need a CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27015#issuecomment-3249124415 From cstein at openjdk.org Wed Sep 3 13:12:37 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 3 Sep 2025 13:12:37 GMT Subject: RFR: 8366678: Use JUnit in test/langtools/tools/javac Message-ID: Please review this change to use JUnit in tests of `test/langtools/tools/javac`. ### Assess Status Quo A local `make test TEST=test/langtools/tools/javac` run before the conversion yields: Test results: passed: 3,938; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 Framework-based tests: 3043 = 2762 TestNG + 281 JUnit ### Perform Automatic Conversion - [junit-convert]( https://github.com/lahodaj/netbeans/tree/openjdk-testng-junit-fixes-and-hacks/java/java.openjdk.project/junit-convert) ### Perform Manual Adjustments Some of the following adjustments will be integrated into the `junit-convert` tool. #### Make argument source factory method `static` Method 'public java.lang.Object[][] org.openjdk.tests.javac.FDTest.caseGenerator()' must be static: local factory methods must be static unless the PER_CLASS @testinstance lifecycle mode is used; external factory methods must always be static. #### Make `@AfterAll`-annotated method `static` [ERROR] @afterall method 'public void org.openjdk.tests.vm.FDSeparateCompilationTest.cleanupCompilerCache()' must be static unless the test class is annotated with `@TestInstance(Lifecycle.PER_CLASS)`. #### Remove `static` modifier from `@Test`-annotated methods This configuration error should have been detected by JUnit Jupiter and reported via the Discovery Issues API: https://docs.junit.org/current/user-guide/#running-tests-discovery-issues #### Rename test property to `JUnit.dirs` package org.junit.jupiter.api does not exist #### Add custom test instance factory Class [FDTests] must declare a single constructor Class [MethodReferenceTestKinds] must declare a single constructor ### Results Re-run tests via `make test TEST=test/langtools/tools/javac` after the conversion; yielding: Test results: passed: 3,939; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 Framework-based tests: 3043 = 0 TestNG + 3043 JUnit ------------- Commit messages: - Remove `static` modifier from `@Test`-annotated methods - Manual adjustments - Initial automatic conversion Changes: https://git.openjdk.org/jdk/pull/27046/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366678 Stats: 628 lines in 39 files changed: 211 ins; 92 del; 325 mod Patch: https://git.openjdk.org/jdk/pull/27046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27046/head:pull/27046 PR: https://git.openjdk.org/jdk/pull/27046 From liach at openjdk.org Wed Sep 3 13:41:42 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 13:41:42 GMT Subject: RFR: 8366678: Use JUnit in test/langtools/tools/javac In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:30:08 GMT, Christian Stein wrote: > Please review this change to use JUnit in tests of `test/langtools/tools/javac`. > > ### Assess Status Quo > A local `make test TEST=test/langtools/tools/javac` run before the conversion yields: > > Test results: passed: 3,938; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 > Framework-based tests: 3043 = 2762 TestNG + 281 JUnit > > > ### Perform Automatic Conversion > - [junit-convert]( > https://github.com/lahodaj/netbeans/tree/openjdk-testng-junit-fixes-and-hacks/java/java.openjdk.project/junit-convert) > > ### Perform Manual Adjustments > > Some of the following adjustments will be integrated into the `junit-convert` tool. > > #### Make argument source factory method `static` > > Method 'public java.lang.Object[][] org.openjdk.tests.javac.FDTest.caseGenerator()' > must be static: local factory methods must be static > unless the PER_CLASS @testinstance lifecycle mode is used; > external factory methods must always be static. > > > #### Make `@AfterAll`-annotated method `static` > > [ERROR] @afterall method 'public void org.openjdk.tests.vm.FDSeparateCompilationTest.cleanupCompilerCache()' > must be static unless the test class > is annotated with `@TestInstance(Lifecycle.PER_CLASS)`. > > > #### Remove `static` modifier from `@Test`-annotated methods > This configuration error should have been detected by JUnit Jupiter and reported via the Discovery > Issues API: https://docs.junit.org/current/user-guide/#running-tests-discovery-issues > > #### Rename test property to `JUnit.dirs` > > package org.junit.jupiter.api does not exist > > > #### Add custom test instance factory > > Class [FDTests] must declare a single constructor > Class [MethodReferenceTestKinds] must declare a single constructor > > > ### Results > Re-run tests via `make test TEST=test/langtools/tools/javac` after the conversion; yielding: > > Test results: passed: 3,939; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 > Framework-based tests: 3043 = 0 TestNG + 3043 JUnit Please run `bash make/scripts/update_copyright_year.sh -b 31847149c1956b23c19a99309982660b4bbdd2d6` to update your copyright years. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27046#issuecomment-3249303386 From cstein at openjdk.org Wed Sep 3 13:52:33 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 3 Sep 2025 13:52:33 GMT Subject: RFR: 8366678: Use JUnit in test/langtools/tools/javac [v2] In-Reply-To: References: Message-ID: > Please review this change to use JUnit in tests of `test/langtools/tools/javac`. > > ### Assess Status Quo > A local `make test TEST=test/langtools/tools/javac` run before the conversion yields: > > Test results: passed: 3,938; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 > Framework-based tests: 3043 = 2762 TestNG + 281 JUnit > > > ### Perform Automatic Conversion > - [junit-convert]( > https://github.com/lahodaj/netbeans/tree/openjdk-testng-junit-fixes-and-hacks/java/java.openjdk.project/junit-convert) > > ### Perform Manual Adjustments > > Some of the following adjustments will be integrated into the `junit-convert` tool. > > #### Make argument source factory method `static` > > Method 'public java.lang.Object[][] org.openjdk.tests.javac.FDTest.caseGenerator()' > must be static: local factory methods must be static > unless the PER_CLASS @testinstance lifecycle mode is used; > external factory methods must always be static. > > > #### Make `@AfterAll`-annotated method `static` > > [ERROR] @afterall method 'public void org.openjdk.tests.vm.FDSeparateCompilationTest.cleanupCompilerCache()' > must be static unless the test class > is annotated with `@TestInstance(Lifecycle.PER_CLASS)`. > > > #### Remove `static` modifier from `@Test`-annotated methods > This configuration error should have been detected by JUnit Jupiter and reported via the Discovery > Issues API: https://docs.junit.org/current/user-guide/#running-tests-discovery-issues > > #### Rename test property to `JUnit.dirs` > > package org.junit.jupiter.api does not exist > > > #### Add custom test instance factory > > Class [FDTests] must declare a single constructor > Class [MethodReferenceTestKinds] must declare a single constructor > > > ### Results > Re-run tests via `make test TEST=test/langtools/tools/javac` after the conversion; yielding: > > Test results: passed: 3,939; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 > Framework-based tests: 3043 = 0 TestNG + 3043 JUnit Christian Stein 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/27046/files - new: https://git.openjdk.org/jdk/pull/27046/files/5c3baed1..4fa84ef8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27046&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27046&range=00-01 Stats: 37 lines in 37 files changed: 0 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/27046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27046/head:pull/27046 PR: https://git.openjdk.org/jdk/pull/27046 From syan at openjdk.org Wed Sep 3 14:10:41 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 14:10:41 GMT Subject: RFR: 8366768: Problemlist jdk/jshell/ToolSimpleTest.java In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 08:57:40 GMT, Jan Lahoda wrote: >> Hi all, >> >> Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. > > Looks good to me - thanks! Thanks for your review @lahodaj I think we should merge this PR quickly to avoid test noisy, because this is tier1 test ------------- PR Comment: https://git.openjdk.org/jdk/pull/27066#issuecomment-3249417277 From jlahoda at openjdk.org Wed Sep 3 14:20:51 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 Sep 2025 14:20:51 GMT Subject: RFR: 8366768: Problemlist jdk/jshell/ToolSimpleTest.java In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 08:57:40 GMT, Jan Lahoda wrote: >> Hi all, >> >> Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. > > Looks good to me - thanks! > Thanks for your review @lahodaj > > I think we should merge this PR quickly to avoid test noisy, because this is tier1 test Nothing against that - but that's up to you, you must issue the `/integrate` command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27066#issuecomment-3249460894 From liach at openjdk.org Wed Sep 3 14:32:45 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 14:32:45 GMT Subject: RFR: 8366678: Use JUnit in test/langtools/tools/javac [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 13:52:33 GMT, Christian Stein wrote: >> Please review this change to use JUnit in tests of `test/langtools/tools/javac`. >> >> ### Assess Status Quo >> A local `make test TEST=test/langtools/tools/javac` run before the conversion yields: >> >> Test results: passed: 3,938; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 >> Framework-based tests: 3043 = 2762 TestNG + 281 JUnit >> >> >> ### Perform Automatic Conversion >> - [junit-convert]( >> https://github.com/lahodaj/netbeans/tree/openjdk-testng-junit-fixes-and-hacks/java/java.openjdk.project/junit-convert) >> >> ### Perform Manual Adjustments >> >> Some of the following adjustments will be integrated into the `junit-convert` tool. >> >> #### Make argument source factory method `static` >> >> Method 'public java.lang.Object[][] org.openjdk.tests.javac.FDTest.caseGenerator()' >> must be static: local factory methods must be static >> unless the PER_CLASS @testinstance lifecycle mode is used; >> external factory methods must always be static. >> >> >> #### Make `@AfterAll`-annotated method `static` >> >> [ERROR] @afterall method 'public void org.openjdk.tests.vm.FDSeparateCompilationTest.cleanupCompilerCache()' >> must be static unless the test class >> is annotated with `@TestInstance(Lifecycle.PER_CLASS)`. >> >> >> #### Remove `static` modifier from `@Test`-annotated methods >> This configuration error should have been detected by JUnit Jupiter and reported via the Discovery >> Issues API: https://docs.junit.org/current/user-guide/#running-tests-discovery-issues >> >> #### Rename test property to `JUnit.dirs` >> >> package org.junit.jupiter.api does not exist >> >> >> #### Add custom test instance factory >> >> Class [FDTests] must declare a single constructor >> Class [MethodReferenceTestKinds] must declare a single constructor >> >> >> ### Results >> Re-run tests via `make test TEST=test/langtools/tools/javac` after the conversion; yielding: >> >> Test results: passed: 3,939; excluded: 4; did not match keywords: 2; did not meet platform requirements: 2 >> Framework-based tests: 3043 = 0 TestNG + 3043 JUnit > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java line 215: > 213: } > 214: > 215: public Object[][] createModes() { This one technically can be removed in favor of `@EnumSource` but since you are using a script and we can be more lenient. test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java line 185: > 183: } > 184: > 185: class LocalTestInstanceFactory implements TestInstanceFactory { Can't junit call the no-arg constructor naturally :thinking: test/langtools/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java line 210: > 208: } > 209: > 210: class LocalTestInstanceFactory implements TestInstanceFactory { Since we have this again, can we just make a no-arg-constructor calling test instance factory and leave it in like /test/lib? test/langtools/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java line 25: > 23: > 24: // this test has been disabled because of timeout issues. > 25: // see JDK-8006746 Should we convert this to a full jtreg header and use problem lists or `@ignore` directive instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27046#discussion_r2319026920 PR Review Comment: https://git.openjdk.org/jdk/pull/27046#discussion_r2319141375 PR Review Comment: https://git.openjdk.org/jdk/pull/27046#discussion_r2319162108 PR Review Comment: https://git.openjdk.org/jdk/pull/27046#discussion_r2319166549 From syan at openjdk.org Wed Sep 3 14:42:53 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 14:42:53 GMT Subject: Integrated: 8366768: Problemlist jdk/jshell/ToolSimpleTest.java In-Reply-To: References: Message-ID: <-cLI1JmEaYL3suG7X0Lj3SCDohxYM8OxWuZLAzF8IaE=.021f55fe-35db-447a-8ed9-219db6d32ff4@github.com> On Wed, 3 Sep 2025 07:23:01 GMT, SendaoYan wrote: > Hi all, > > Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. This pull request has now been integrated. Changeset: d5935af2 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/d5935af228d7129d75d6987767de50b019ec30c7 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8366768: Problemlist jdk/jshell/ToolSimpleTest.java Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/27066 From liach at openjdk.org Wed Sep 3 16:53:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 16:53:48 GMT Subject: RFR: 8366768: Problemlist jdk/jshell/ToolSimpleTest.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 07:23:01 GMT, SendaoYan wrote: > Hi all, > > Should we problemlist jdk/jshell/ToolSimpleTest.java and jdk/jshell/ToolLocalSimpleTest.java on windows platform before the root cause been fixed. This failure happened once on linux-aarch64 too. So probably not platform-specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27066#issuecomment-3250014488 From liach at openjdk.org Wed Sep 3 21:07:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 21:07:48 GMT Subject: RFR: 8365676: javac incorrectly allows calling interface static method via type variable [v2] In-Reply-To: References: Message-ID: > The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9: > >> The members of an intersection type are the members of the class or interface it induces. > > Combined with JLS 4.4: > >> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([?4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared > > Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8. > > The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator` be able to do so. > > In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Break up long conditional, add intersection bounded test case - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typevar-inherit-interface-static - 8365676: javac incorrectly allows calling interface static method via type variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27015/files - new: https://git.openjdk.org/jdk/pull/27015/files/266dc4c3..c3abc487 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27015&range=00-01 Stats: 7304 lines in 671 files changed: 4112 ins; 1396 del; 1796 mod Patch: https://git.openjdk.org/jdk/pull/27015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27015/head:pull/27015 PR: https://git.openjdk.org/jdk/pull/27015 From liach at openjdk.org Wed Sep 3 21:11:43 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 21:11:43 GMT Subject: RFR: 8365676: javac incorrectly allows calling interface static method via type variable [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 21:07:48 GMT, Chen Liang wrote: >> The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9: >> >>> The members of an intersection type are the members of the class or interface it induces. >> >> Combined with JLS 4.4: >> >>> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([?4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared >> >> Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8. >> >> The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator` be able to do so. >> >> In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Break up long conditional, add intersection bounded test case > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typevar-inherit-interface-static > - 8365676: javac incorrectly allows calling interface static method via type variable Interesting thing surfaces - the one with `extends Object & Comparator