From mark.reinhold at oracle.com Wed Oct 1 17:03:55 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 1 Oct 2025 17:03:55 +0000 Subject: New candidate JEP: 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 Message-ID: <20250930171429.924CF81F974@eggemoggin.niobe.net> https://openjdk.org/jeps/527 Summary: Enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use the javax.net.ssl APIs will benefit from these improved algorithms by default, without change to existing code. - Mark From mark.reinhold at oracle.com Wed Oct 1 17:04:14 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 1 Oct 2025 17:04:14 +0000 Subject: Proposed schedule for JDK 26 Message-ID: <20251001170413.9AF3F81FA16@eggemoggin.niobe.net> Here is the proposed schedule for JDK 26: 2025/12/04 Rampdown Phase One 2026/01/15 Rampdown Phase Two 2026/02/05 Initial Release Candidate 2026/02/19 Final Release Candidate 2026/03/17 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Wednesday, 8 October, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 26. - Mark [1] https://openjdk.org/jeps/3 [2] https://openjdk.org/census#jdk [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From joe.darcy at oracle.com Thu Oct 2 15:09:43 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 2 Oct 2025 08:09:43 -0700 Subject: Reminder: file JDK 26 CSRs well ahead of rampdown 1 start Message-ID: <7edb8706-cfb6-4dcd-ba38-86939d4819a5@oracle.com> Hello, Per the expected JDK 26 schedule (https://mail.openjdk.org/pipermail/jdk-dev/2025-October/010505.html), the rampdown 1 of JDK 26 would start in early December 2025, nine weeks from today. An advanced reminder to factor in sufficient review time for any projects needing CSR review before getting pushed into JDK 26, which includes JEPs. Large projects, including JEPs, should often use the two-phase CSR process (https://wiki.openjdk.java.net/display/csr/Main) rather than the one-phase process. The nominal SLA for each CSR phase is one week. To accommodate the possibility of needing to respond to feedback from the CSR, I recommend a large project that has not already had CSR review budget at least six weeks of CSR review time ahead of an anticipated integration date. Particularly large or complex projects should factor in additional time. A JEP should have gone through the first phase of CSR review, getting to Provisional state, before being Proposed to Target for a release. Please plan accordingly. Cheers, -Joe CSR Lead From tobias.hartmann at oracle.com Wed Oct 8 05:42:29 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 8 Oct 2025 07:42:29 +0200 Subject: =?UTF-8?Q?CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= Message-ID: I hereby nominate Beno?t Maillard [1] to JDK Committer. Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June 2025, he contributed 13 changes in various compiler related areas to the JDK project [2]. Votes are due by October 22, 2025, 06:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#bmaillard [2] https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote From tobias.hartmann at oracle.com Wed Oct 8 05:43:32 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 8 Oct 2025 07:43:32 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <8446305b-ba75-4377-badb-d32e9bce6ee3@oracle.com> Vote: yes Best regards, Tobias On 10/8/25 07:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > > Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June 2025, he contributed 13 changes in various compiler related areas to the JDK project [2]. > > Votes are due by October 22, 2025, 06:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#bmaillard > [2] https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From vladimir.kozlov at oracle.com Wed Oct 8 05:44:10 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Oct 2025 22:44:10 -0700 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <0f160071-2960-49a6-886d-c51e8613640d@oracle.com> Vote: yes Vladimir K On 10/7/25 10:42 PM, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > > Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June > 2025, he contributed 13 changes in various compiler related areas to the > JDK project [2]. > > Votes are due by October 22, 2025, 06:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#bmaillard > [2] https://github.com/search? > q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From manuel.hassig at oracle.com Wed Oct 8 06:38:51 2025 From: manuel.hassig at oracle.com (=?UTF-8?Q?Manuel_H=C3=A4ssig?=) Date: Wed, 8 Oct 2025 08:38:51 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: Vote: Yes - Manuel H?ssig From joel.sikstrom at oracle.com Wed Oct 8 06:43:45 2025 From: joel.sikstrom at oracle.com (Joel Sikstrom) Date: Wed, 8 Oct 2025 06:43:45 +0000 Subject: =?iso-8859-1?Q?Re:_CFV:_New_JDK_Committer:_Beno=EEt_Maillard?= In-Reply-To: References: Message-ID: Vote: yes Joel Sikstr?m From: jdk-dev on behalf of Tobias Hartmann Date: Wednesday, 8 October 2025 at 07:42 To: jdk-dev at openjdk.org Cc: Benoit Maillard Subject: CFV: New JDK Committer: Beno?t Maillard I hereby nominate Beno?t Maillard [1] to JDK Committer. Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June 2025, he contributed 13 changes in various compiler related areas to the JDK project [2]. Votes are due by October 22, 2025, 06:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#bmaillard [2] https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote Confidential - Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevalier at oracle.com Wed Oct 8 07:37:27 2025 From: marc.chevalier at oracle.com (Marc Chevalier) Date: Wed, 8 Oct 2025 09:37:27 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <97bcccc9-034a-43fc-82e5-3d121ee56c89@oracle.com> Vote: yes Best, Marc On 10/8/25 07:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > > Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June > 2025, he contributed 13 changes in various compiler related areas to > the JDK project [2]. > > Votes are due by October 22, 2025, 06:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#bmaillard > [2] > https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Wed Oct 8 09:01:20 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Wed, 8 Oct 2025 09:01:20 +0000 Subject: =?iso-8859-1?Q?Re:_CFV:_New_JDK_Committer:_Beno=EEt_Maillard?= In-Reply-To: References: Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Wednesday, October 8, 2025 7:42 AM To: jdk-dev at openjdk.org Cc: Benoit Maillard Subject: CFV: New JDK Committer: Beno?t Maillard I hereby nominate Beno?t Maillard [1] to JDK Committer. Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June 2025, he contributed 13 changes in various compiler related areas to the JDK project [2]. Votes are due by October 22, 2025, 06:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#bmaillard [2] https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote From raffaello.giulietti at oracle.com Wed Oct 8 09:13:05 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 8 Oct 2025 11:13:05 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: Vote: yes On 2025-10-08 07:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > From daniel.lunden at oracle.com Wed Oct 8 12:06:54 2025 From: daniel.lunden at oracle.com (Daniel Lunden) Date: Wed, 8 Oct 2025 12:06:54 +0000 Subject: =?Windows-1252?Q?Re:_CFV:_New_JDK_Committer:_Beno=EEt_Maillard?= In-Reply-To: References: Message-ID: Vote: yes Cheers, Daniel Confidential ? Oracle Internal ________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Wednesday, 8 October 2025 07:42 To: jdk-dev at openjdk.org Cc: Benoit Maillard Subject: CFV: New JDK Committer: Beno?t Maillard I hereby nominate Beno?t Maillard [1] to JDK Committer. Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June 2025, he contributed 13 changes in various compiler related areas to the JDK project [2]. Votes are due by October 22, 2025, 06:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#bmaillard [2] https://github.com/search?q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Wed Oct 8 13:24:04 2025 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 8 Oct 2025 14:24:04 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <3ad1150a-2538-4e87-97b8-cdbd1b477540@redhat.com> Vote: yes On 08/10/2025 06:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > > Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June > 2025, he contributed 13 changes in various compiler related areas to the > JDK project [2]. > > Votes are due by October 22, 2025, 06:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#bmaillard > [2] https://github.com/search? > q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer He/Him/His IBM UK Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN From roger.riggs at oracle.com Wed Oct 8 13:32:34 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 8 Oct 2025 09:32:34 -0400 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: Vote: Yes On 10/8/25 1:42 AM, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. From christian.s.stein at oracle.com Wed Oct 8 14:49:07 2025 From: christian.s.stein at oracle.com (Christian Stein) Date: Wed, 8 Oct 2025 14:49:07 +0000 Subject: Coming soon: jtreg 8.1 Message-ID: JDK folk, This is a general heads-up that jtreg 8.1 is ready for use and that we should soon update JDK to use it. The most significant changes in jtreg 8.1 are improvements in the logging format and order with respect to agent-, action-, and test-related execution points. Find a listing of all noteworthy changes at [1]. Thanks to everyone who has helped thus far! [1] https://git.openjdk.org/jtreg/blob/master/CHANGELOG.md#8.1 From daniel.fuchs at oracle.com Wed Oct 8 16:06:51 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Oct 2025 17:06:51 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 08/10/2025 06:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. From christian.hagedorn at oracle.com Thu Oct 9 05:56:14 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 9 Oct 2025 07:56:14 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <277937c7-d750-42fa-bc8b-7e4c97ed12e4@oracle.com> Vote: yes Best regards, Christian On 10/8/25 07:42, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > > Beno?t is a member of the HotSpot Compiler Team at Oracle. Since June > 2025, he contributed 13 changes in various compiler related areas to the > JDK project [2]. > > Votes are due by October 22, 2025, 06:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#bmaillard > [2] https://github.com/search? > q=author%3Abenoitmaillard+repo%3Aopenjdk%2Fjdk&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Thu Oct 9 07:42:10 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 9 Oct 2025 07:42:10 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan Message-ID: I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Thu Oct 9 07:44:26 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 9 Oct 2025 07:44:26 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, October 9, 2025 9:42 AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote From adinn at redhat.com Thu Oct 9 07:56:14 2025 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 9 Oct 2025 08:56:14 +0100 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <546a86d5-c7cc-4cc2-9fea-7e213fc995f8@redhat.com> Vote: yes On 09/10/2025 08:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer He/Him/His IBM UK Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN From joel.sikstrom at oracle.com Thu Oct 9 08:11:15 2025 From: joel.sikstrom at oracle.com (Joel Sikstrom) Date: Thu, 9 Oct 2025 08:11:15 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes Joel Sikstr?m From: jdk-dev on behalf of Roberto Castaneda Lozano Date: Thursday, 9 October 2025 at 09:42 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From casper.norrbin at oracle.com Thu Oct 9 08:14:51 2025 From: casper.norrbin at oracle.com (Casper Norrbin) Date: Thu, 9 Oct 2025 08:14:51 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: Yes // Casper Norrbin From: jdk-dev on behalf of Roberto Castaneda Lozano Date: Thursday, 9 October 2025 at 09:42 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.korinth at oracle.com Thu Oct 9 08:20:08 2025 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 09 Oct 2025 10:20:08 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: (Roberto Castaneda Lozano's message of "Thu, 9 Oct 2025 07:42:10 +0000") References: Message-ID: <87ms60qyfb.fsf@oracle.com> Vote: yes -- Leo Roberto Castaneda Lozano writes: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is > located in Stockholm, Sweden. She holds a PhD in Information and > Communication Technology with specialization in Software and Computer > Systems from KTH Royal Institute of Technology (Sweden). Since she > joined Oracle, Saranya has worked in different HotSpot compiler areas, > including fixes for C2 issues, diagnostic enhancements (compiler > randomization and IGV support), and general maintainability > improvements. She has so far contributed 13 changes to HotSpot [2], of > which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From manuel.hassig at oracle.com Thu Oct 9 08:33:23 2025 From: manuel.hassig at oracle.com (=?UTF-8?Q?Manuel_H=C3=A4ssig?=) Date: Thu, 9 Oct 2025 10:33:23 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes - Manuel From jatinbha.cloud at gmail.com Thu Oct 9 09:11:58 2025 From: jatinbha.cloud at gmail.com (Jatin Bhateja) Date: Thu, 9 Oct 2025 14:41:58 +0530 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote : yes Best Regards On 10/9/2025 1:12 PM, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From johan.sjolen at oracle.com Thu Oct 9 09:19:26 2025 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Thu, 9 Oct 2025 09:19:26 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes / Johan ________________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, October 9, 2025 09:42 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote From Amit.Kumar220 at ibm.com Thu Oct 9 09:33:30 2025 From: Amit.Kumar220 at ibm.com (Amit Kumar) Date: Thu, 9 Oct 2025 09:33:30 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: Yes /Amit > On 09/10/2025, at 1:12?PM, Roberto Castaneda Lozano wrote: > > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From stefank at openjdk.org Thu Oct 9 10:08:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 9 Oct 2025 10:08:43 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 Message-ID: [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. I will run this through Oracle's tier1-tier8 testing. ------------- Commit messages: - 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 Changes: https://git.openjdk.org/jdk/pull/27721/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27721&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369491 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27721.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27721/head:pull/27721 PR: https://git.openjdk.org/jdk/pull/27721 From martin.doerr at sap.com Thu Oct 9 10:09:36 2025 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 9 Oct 2025 10:09:36 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Roberto Castaneda Lozano Datum: Donnerstag, 9. Oktober 2025 um 09:42 An: jdk-dev at openjdk.org Betreff: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fsaranya-natarajan-b31947212&data=05%7C02%7Cmartin.doerr%40sap.com%7C8bf4e9a8798249cc2c6e08de07076eb6%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638955925753851835%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d9XgYEZY9VCVsa5Vp1GM3DvDPyHW6V3VcwF%2BJX0sHcQ%3D&reserved=0 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkorinth at openjdk.org Thu Oct 9 10:26:19 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 9 Oct 2025 10:26:19 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Looks good to me. ------------- Marked as reviewed by lkorinth (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318245874 From cstein at openjdk.org Thu Oct 9 10:32:13 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 9 Oct 2025 10:32:13 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Marked as reviewed by cstein (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318280220 From jpai at openjdk.org Thu Oct 9 12:25:28 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 9 Oct 2025 12:25:28 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318710232 From raffaello.giulietti at oracle.com Thu Oct 9 12:41:38 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Thu, 9 Oct 2025 14:41:38 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes On 2025-10-09 09:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > From roger.riggs at oracle.com Thu Oct 9 14:07:21 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 9 Oct 2025 10:07:21 -0400 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <27c4231b-c56f-444e-8dba-eaf50681aec4@oracle.com> Vote: Yes On 10/9/25 3:42 AM, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. From syan at openjdk.org Thu Oct 9 14:26:58 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 9 Oct 2025 14:26:58 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Glad to see this proposed change. ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3319264878 From vladimir.kozlov at oracle.com Thu Oct 9 14:57:21 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Oct 2025 07:57:21 -0700 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes Vladimir K On 10/9/25 12:42 AM, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From jesper.wilhelmsson at oracle.com Thu Oct 9 15:26:37 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 9 Oct 2025 15:26:37 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <5CF8F936-ECC7-4775-9B5D-F3659EC8D719@oracle.com> Vote: Yes /Jesper > On 9 Oct 2025, at 09:42, Roberto Castaneda Lozano wrote: > > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From dean.long at oracle.com Thu Oct 9 20:10:25 2025 From: dean.long at oracle.com (Dean Long) Date: Thu, 9 Oct 2025 13:10:25 -0700 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: <30d26d70-6075-4504-a0bf-63c66250d457@oracle.com> Vote: yes From dean.long at oracle.com Thu Oct 9 20:15:49 2025 From: dean.long at oracle.com (Dean Long) Date: Thu, 9 Oct 2025 13:15:49 -0700 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes From serb at openjdk.org Fri Oct 10 03:18:03 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 10 Oct 2025 03:18:03 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3321214353 From prr at openjdk.org Fri Oct 10 05:00:06 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 10 Oct 2025 05:00:06 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Marked as reviewed by prr (Reviewer). I don't have much visibility into how this affected other areas but I was surprised that a test that for me runs in a couple of seconds was apparently timing out on some systems (not the Oracle CI but some external one). In the PR to resolve this I suggested (https://github.com/openjdk/jdk/pull/27397#discussion_r2383687871) that we may be using too high a concurrency as chosen by the build as tests could be more sensitive to this. But I also see that if you have a system with N CPUs it is a waste to only use (eg) N/2 because "some" test might time out. A compromise may be needed. ------------- PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3321344090 PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3388293960 From daniel.lunden at oracle.com Fri Oct 10 06:48:31 2025 From: daniel.lunden at oracle.com (Daniel Lunden) Date: Fri, 10 Oct 2025 06:48:31 +0000 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes Cheers, Daniel ________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, 9 October 2025 09:42 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Saranya Natarajan I hereby nominate Saranya Natarajan to JDK Committer. Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: https://github.com/openjdk/jdk/pull/27083 https://github.com/openjdk/jdk/pull/26640 https://github.com/openjdk/jdk/pull/26554 https://github.com/openjdk/jdk/pull/25933 https://github.com/openjdk/jdk/pull/25756 https://github.com/openjdk/jdk/pull/25682 https://github.com/openjdk/jdk/pull/24890 https://github.com/openjdk/jdk/pull/24410 https://github.com/openjdk/jdk/pull/23959 https://github.com/openjdk/jdk/pull/23928 Votes are due by Thursday, 23 October 2025 at 08:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best Regards, Roberto Casta?eda Lozano [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated [3] https://openjdk.org/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Oct 10 11:45:35 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Oct 2025 13:45:35 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <6ec55448-ef9d-4fa0-8c3a-8a97733df401@oracle.com> Vote: yes Best regards, Tobias On 10/9/25 09:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From marc.chevalier at oracle.com Mon Oct 13 09:01:42 2025 From: marc.chevalier at oracle.com (Marc Chevalier) Date: Mon, 13 Oct 2025 11:01:42 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <5bae2aca-5f3f-41fc-a246-fd4726aaf510@oracle.com> Vote: yes Best, Marc On 09/10/2025 09:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1]https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2]https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3]https://openjdk.org/census > [4]https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.hagedorn at oracle.com Mon Oct 13 10:29:13 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 13 Oct 2025 12:29:13 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: <0dda17b8-be91-487f-b7f7-8fc0c66395d9@oracle.com> Vote: Yes Best regards, Christian On 10/9/25 09:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#committer-vote From stefan.johansson at oracle.com Mon Oct 13 13:49:05 2025 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 13 Oct 2025 15:49:05 +0200 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes On 2025-10-09 09:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > > Saranya [1] is a member of the HotSpot Compiler Team at Oracle and is located in Stockholm, Sweden. She holds a PhD in Information and Communication Technology with specialization in Software and Computer Systems from KTH Royal Institute of Technology (Sweden). Since she joined Oracle, Saranya has worked in different HotSpot compiler areas, including fixes for C2 issues, diagnostic enhancements (compiler randomization and IGV support), and general maintainability improvements. She has so far contributed 13 changes to HotSpot [2], of which at least the following 10 are significant: > > https://github.com/openjdk/jdk/pull/27083 > https://github.com/openjdk/jdk/pull/26640 > https://github.com/openjdk/jdk/pull/26554 > https://github.com/openjdk/jdk/pull/25933 > https://github.com/openjdk/jdk/pull/25756 > https://github.com/openjdk/jdk/pull/25682 > https://github.com/openjdk/jdk/pull/24890 > https://github.com/openjdk/jdk/pull/24410 > https://github.com/openjdk/jdk/pull/23959 > https://github.com/openjdk/jdk/pull/23928 > > Votes are due by Thursday, 23 October 2025 at 08:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1]https://www.linkedin.com/in/saranya-natarajan-b31947212 > [2]https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Asarannat+label%3Aintegrated > [3]https://openjdk.org/census > [4]https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Mon Oct 13 18:36:18 2025 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 13 Oct 2025 11:36:18 -0700 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: Yes On 10/9/25 12:42 AM, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. > From brent.christian at oracle.com Mon Oct 13 18:43:06 2025 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 13 Oct 2025 11:43:06 -0700 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= In-Reply-To: References: Message-ID: Vote: Yes On 10/7/25 10:42 PM, Tobias Hartmann wrote: > I hereby nominate Beno?t Maillard [1] to JDK Committer. > From christian.s.stein at oracle.com Tue Oct 14 09:00:21 2025 From: christian.s.stein at oracle.com (Christian Stein) Date: Tue, 14 Oct 2025 09:00:21 +0000 Subject: Coming soon: jtreg 8.1 In-Reply-To: References: Message-ID: With commit [1], jtreg 8.1 is now default in JDK. Happy testing, Christian [1] https://github.com/openjdk/jdk/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db ________________________________________ From: jdk-dev on behalf of Christian Stein Sent: Wednesday, October 8, 2025 16:49 To: JDK Dev list Subject: Coming soon: jtreg 8.1 JDK folk, This is a general heads-up that jtreg 8.1 is ready for use and that we should soon update JDK to use it. The most significant changes in jtreg 8.1 are improvements in the logging format and order with respect to agent-, action-, and test-related execution points. Find a listing of all noteworthy changes at [1]. Thanks to everyone who has helped thus far! [1] https://git.openjdk.org/jtreg/blob/master/CHANGELOG.md#8.1 From daniel.fuchs at oracle.com Tue Oct 14 16:12:01 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2025 17:12:01 +0100 Subject: CFV: New JDK Committer: Saranya Natarajan In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 09/10/2025 08:42, Roberto Castaneda Lozano wrote: > I hereby nominate Saranya Natarajan to JDK Committer. From stefank at openjdk.org Wed Oct 15 20:32:50 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 15 Oct 2025 20:32:50 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Tier1-8 testing passed. My intention is to get this integrated tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3408163480 From stefank at openjdk.org Thu Oct 16 11:16:09 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 16 Oct 2025 11:16:09 GMT Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3410361774 From stefank at openjdk.org Thu Oct 16 11:19:26 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 16 Oct 2025 11:19:26 GMT Subject: Integrated: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 In-Reply-To: References: Message-ID: <1fWKegMvrCUndpvpe4L_LWftNVcHWKgZ_MLnVTnOr1k=.3f52ec81-3baa-4081-bbce-04932ee45ee2@github.com> On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson wrote: > [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs. > > The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. This pull request has now been integrated. Changeset: 5fc3904b Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/5fc3904bfe290625ed6cf9b41773b35b52bf72b7 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 Reviewed-by: lkorinth, cstein, jpai, syan, serb, prr ------------- PR: https://git.openjdk.org/jdk/pull/27721 From mark.reinhold at oracle.com Thu Oct 16 19:18:24 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 16 Oct 2025 19:18:24 +0000 Subject: New candidate JEP: 528: Post-Mortem Crash Analysis with jcmd Message-ID: <20251016191614.B1C5C806@naskeag.niobe.net> https://openjdk.org/jeps/528 Summary: The jcmd tool supports the monitoring and troubleshooting of a running HotSpot JVM. Extend jcmd so that it can also be used to diagnose a JVM that has crashed. This will establish a consistent experience in both live and post-mortem environments. - Mark From mark.reinhold at oracle.com Thu Oct 16 19:34:40 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 16 Oct 2025 19:34:40 +0000 Subject: New candidate JEP: 529: Vector API (Eleventh Incubator) Message-ID: <20251016193231.C88B1684@naskeag.niobe.net> https://openjdk.org/jeps/529 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations. - Mark From patrick at os.amperecomputing.com Sat Oct 18 03:15:51 2025 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Sat, 18 Oct 2025 03:15:51 +0000 Subject: jdk.java.net/archive/ webpage has a bug Message-ID: Hi JDK dev team, I find that https://jdk.java.net/archive/ has a bug that some hyperlinks point to wrong downloads. For example, 18 GA (build 18+36) Linux/AArch64 64-bit tar.gz (sha256) 177M The tar.gz points to a tarball for macos-aarch64 which should be corrected to linux-aarch64, while the sha256 points to a right link. Tar.gz: https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_macos-aarch64_bin.tar.gz Sha256: https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_linux-aarch64_bin.tar.gz.sha256 The two jdk-19 aarch64 links have similar issue. 19 GA (build 19+36) Linux/AArch64 64-bit tar.gz (sha256) 186M 19.0.1 (build 19.0.1+10) Linux/AArch64 64-bit tar.gz (sha256) 186M I encountered this issue while trying to use older packages as boot jdks for experiments but am unsure where to report it. Could anyone please help forward it to the appropriate mailing list or contacts? Thank you! Regards, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Mon Oct 20 17:01:24 2025 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 20 Oct 2025 17:01:24 +0000 Subject: jdk.java.net/archive/ webpage has a bug In-Reply-To: References: Message-ID: Hi, Patrick. Thanks for reporting this problem with the archive. The links should be fixed now. Best, Iris Confidential ? Oracle Internal ________________________________ From: jdk-dev on behalf of Patrick Zhang OS Sent: Friday, October 17, 2025 8:15 PM To: jdk-dev at openjdk.java.net Subject: jdk.java.net/archive/ webpage has a bug Hi JDK dev team, I find that https://jdk.java.net/archive/ has a bug that some hyperlinks point to wrong downloads. For example, 18 GA (build 18+36) Linux/AArch64 64-bit tar.gz (sha256) 177M The tar.gz points to a tarball for macos-aarch64 which should be corrected to linux-aarch64, while the sha256 points to a right link. Tar.gz: https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_macos-aarch64_bin.tar.gz Sha256: https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_linux-aarch64_bin.tar.gz.sha256 The two jdk-19 aarch64 links have similar issue. 19 GA (build 19+36) Linux/AArch64 64-bit tar.gz (sha256) 186M 19.0.1 (build 19.0.1+10) Linux/AArch64 64-bit tar.gz (sha256) 186M I encountered this issue while trying to use older packages as boot jdks for experiments but am unsure where to report it. Could anyone please help forward it to the appropriate mailing list or contacts? Thank you! Regards, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy at linux.ibm.com Tue Oct 21 14:26:10 2025 From: eddy at linux.ibm.com (Eduard Stefes) Date: Tue, 21 Oct 2025 16:26:10 +0200 Subject: state of openjdks zlib on s390x Message-ID: Hello, Disclaimer: This is email could cause cause discussions and work. # TLDR zlib (and zlib-ng) on s390x use hardware compression. This hardware?compression implementation has currently some problems when used by openjdk. # current situation - openjdk uses zlib(or zlib-ng) for most(all?) its data compression.? This includes also jar file creation. - s390x has deflate implemented on hardware level(called dfltcc). This? implementation is up to 10x faster(empirical value) compared to the standard software algorithm. - The dfltcc implementation has some drawbacks vs the software? implementation: - dfltcc will ALWAYS write to the output buffer, indifferent of the flushing parameter passed to deflate() - dfltcc does not generate reproducible output. This means that?it will always generate valid deflate data streams that uncompress(inflate) to the same input. But the compressed data may look different between two calls with? the?same input data, because the hardware compressor depends also on hardware variables that not visible to the external? api user. # the problem due to the differences of the hardware implementation, some tests in the openjdk JREG tests fail(tracked here[1][2]) - java/util/zip/CloseInflaterDeflaterTest.java fails due to dfltcc's flushing behaviour. The test should check if? the openjdk wrapper around the jni and native library will? successfully detect writes to closed output streams. This was? created because there?where bugs with and race conditions in the? write/close/flush. - tools/jlink/JLinkReproducibleTest.java: - tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java: This tests fail due to two calls to dfltcc will not generate the? same compressed data for the same input data. I want to? emphasize?that RFC 1950 and 1951 do not guarantee the same output? for two deflate/zlib data streams if feed the same input data. # proposed solutions ## flushing problem IMHO the CloseInflaterDeflaterTest.java test relays on zlib behavior where zlib explicitly has the freedom to change its behavior[3][1]. As a quick and dirty solution i would propose to backport the disablement[4] of this test to openjdk-17 21 and 24. I read and traced through the test, and for me it looks like the behavior of the openjdk and jni wrappers will be the same regardless of the underlying zlib. Therefor it seems ok to assume that: "If its okay on x86 it will be ok on s390x" However I think that this test might need a redesign. It relies on flushing behavior of zlib the the library explicitly stated can change. ## reproducible compression I don't know how much openjdk relies on reproducible data compression. I assume it is preferable if its possible to create the same .jar twice and get the same binary data. The zlib dfltcc implementation could be controlled via an env variable to disable the hardware compression[5]. Also usually dftcc will only be used for certain compression levels and this can also be changed via env variables[6]. Unfortunately this env variables are evaluated at library load and can not be adjusted during runtime. Moreover ubuntu setzt the default LEVEL_MASK to 0x7e[7]. This means that the compression level is also not a reliabl method in order to force zlib to use software instead of hardware compression. Also zlib-ng lacks this env variables. Here the use of dfltcc cannot be influenced at all. This all leads me to the conclusion that there has to be a decision if and how openjdk on s390x will be able to generate reproducible jars. For the time being I suppose to also disable this tests and backport the disablements down till openjdk-17. # Finally I hope i did not overwhelm you all with this email. As I don't have a bugs.openjdk.org account, I thought the mailing list is the best place to discuss this mater. If all are okay with disabling the tests I can create the PR in gh. cheers Eddy [1] https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2109016 [2] https://bugs.openjdk.org/browse/JDK-8339216 [3] https://github.com/madler/zlib/blob/develop/zlib.h#L286-L288 [4] https://github.com/openjdk/jdk/commit/537447f8816129dad9a1edd21bd30f3edf69ea60 [5] https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L705-L706 [6] https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L714-L715 [7] https://git.launchpad.net/ubuntu/+source/zlib/tree/debian/rules#n53 From alan.bateman at oracle.com Wed Oct 22 09:27:11 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 22 Oct 2025 10:27:11 +0100 Subject: state of openjdks zlib on s390x In-Reply-To: References: Message-ID: <5e5b1569-b67e-4f47-985b-2dabdd73b32b@oracle.com> On 21/10/2025 15:26, Eduard Stefes wrote: > Hello, > > Disclaimer: This is email could cause cause discussions and work. > > # TLDR > > zlib (and zlib-ng) on s390x use hardware compression. This > hardware?compression implementation has currently some problems when > used by openjdk. > It would be better to bring this discussion to core-libs-dev. Test descriptions can include constraints so they are only selected (or not selected) on specific platforms and/or in specific configurations. Also tests for the zip area also have some history with issues that only surface with specific zlib implementations. There is interest in reproducible builds in some quarters (including IBM folks building the JDK) but this is indeed problematic when using zlib compression. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Thu Oct 23 08:07:48 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 23 Oct 2025 08:07:48 +0000 Subject: Result: New JDK Committer: Saranya Natarajan Message-ID: Voting for Saranya Natarajan [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best Regards, Roberto Casta?eda Lozano [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-October/010521.html From tobias.hartmann at oracle.com Thu Oct 23 12:36:23 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2025 14:36:23 +0200 Subject: =?UTF-8?Q?Result=3A_New_JDK_Committer=3A_Beno=C3=AEt_Maillard?= Message-ID: <5a7ee86c-4c4d-4ac1-85da-cfff5335e36e@oracle.com> Voting [1] for Beno?t Maillard [2] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the bylaw's definition of Lazy Consensus [3], this is sufficient to approve the nomination. Thanks, Tobias [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-October/010507.html [2] https://openjdk.org/census#bmaillard [3] https://openjdk.org/bylaws#lazy-consensus From mark.reinhold at oracle.com Mon Oct 27 16:18:30 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 27 Oct 2025 16:18:30 +0000 Subject: New candidate JEP: 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview) Message-ID: <20251027161829.029E9D00@naskeag.niobe.net> https://openjdk.org/jeps/530 Summary: Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature. - Mark From joe.darcy at oracle.com Wed Oct 29 20:36:09 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 29 Oct 2025 13:36:09 -0700 Subject: Reminder: file JDK 26 CSRs well ahead of rampdown 1 start -- just over five weeks to go In-Reply-To: <7edb8706-cfb6-4dcd-ba38-86939d4819a5@oracle.com> References: <7edb8706-cfb6-4dcd-ba38-86939d4819a5@oracle.com> Message-ID: <2bb89d4f-34e6-4012-8fa3-60f5896ff919@oracle.com> PS Now just over five weeks until the Dec. 4, 2025 start of JDK 26 rampdown 1. Any JEPs intended for JDK 26 should already have started engaging with the CSR process. Cheers, -Joe On 10/2/2025 8:09 AM, Joseph D. Darcy wrote: > Hello, > > Per the expected JDK 26 schedule > (https://mail.openjdk.org/pipermail/jdk-dev/2025-October/010505.html), > the rampdown 1 of JDK 26 would start in early December 2025, nine > weeks from today. > > An advanced reminder to factor in sufficient review time for any > projects needing CSR review before getting pushed into JDK 26, which > includes JEPs. Large projects, including JEPs, should often use the > two-phase CSR process (https://wiki.openjdk.java.net/display/csr/Main) > rather than the one-phase process. The nominal SLA for each CSR phase > is one week. To accommodate the possibility of needing to respond to > feedback from the CSR, I recommend a large project that has not > already had CSR review budget at least six weeks of CSR review time > ahead of an anticipated integration date. > > Particularly large or complex projects should factor in additional time. > > A JEP should have gone through the first phase of CSR review, getting > to Provisional state, before being Proposed to Target for a release. > Please plan accordingly. > > Cheers, > > -Joe > CSR Lead > > From axh at dua3.com Thu Oct 30 17:22:46 2025 From: axh at dua3.com (axh) Date: Thu, 30 Oct 2025 18:22:46 +0100 Subject: Automatic dark mode detection (JDK-8235460) - POC Message-ID: <7169096B-808D-4103-B3A8-D56E8B58063D@dua3.com> Hi, I hope this is the right place to ask - I would comment in the bug tracker if getting a login there weren?t harder than entering Fort Knox. If this should be posted to another list, please let meknow. I have written a POC for dark mode detection that works on Windows, MacOS, and Linux. It is 100% Java, calling native code through FFM, so Java 25 is required. It can detect the current system setting, and also tracks system changes. I have released the POC under the GPL V2 with classpath exception to make it compatible with OpenJDK/JavaFX licensing. Needs Java 25 and JavaFX correctly set up on your system (JavaFX is only needed because of the JavaFX sample application). No external libraries are needed (in the POC, I changed logging to use the system logger). Legal thought - I have used web search to find out how to detect and listen to system changes. - I have also used AI to implement the necessary calls using FFM as I don?t yet have much experience with it. As everything is quite straight forward (follows established well documented practice for the platform) and the AI mainly helped me to put it into a FFM compatible form, I think there is no risk to inadvertently touch any third party copyright issues. I just want to mention that in case it is seen as a problem The POC is available on GitHub: https://github.com/xzel23/darkmodedetector Please let me know if this would be an acceptable contribution, and if so, how to proceed. Axel PS: Sorry to the mods, I accidentally used the wrong sender previously. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Thu Oct 30 17:32:58 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 30 Oct 2025 17:32:58 +0000 Subject: Automatic dark mode detection (JDK-8235460) - POC In-Reply-To: <7169096B-808D-4103-B3A8-D56E8B58063D@dua3.com> References: <7169096B-808D-4103-B3A8-D56E8B58063D@dua3.com> Message-ID: Here are the list of mailing lists: https://mail.openjdk.org/mailman/listinfo A better target list might be https://mail.openjdk.org/mailman/listinfo/openjfx-dev On Thu, Oct 30, 2025 at 5:23?PM axh wrote: > > Hi, > > I hope this is the right place to ask - I would comment in the bug tracker if getting a login there weren?t harder than entering Fort Knox. If this should be posted to another list, please let meknow. > > I have written a POC for dark mode detection that works on Windows, MacOS, and Linux. It is 100% Java, calling native code through FFM, so Java 25 is required. It can detect the current system setting, and also tracks system changes. > > I have released the POC under the GPL V2 with classpath exception to make it compatible with OpenJDK/JavaFX licensing. > > Needs Java 25 and JavaFX correctly set up on your system (JavaFX is only needed because of the JavaFX sample application). No external libraries are needed (in the POC, I changed logging to use the system logger). > > Legal thought > - I have used web search to find out how to detect and listen to system changes. > - I have also used AI to implement the necessary calls using FFM as I don?t yet have much experience with it. As everything is quite straight forward (follows established well documented practice for the platform) and the AI mainly helped me to put it into a FFM compatible form, I think there is no risk to inadvertently touch any third party copyright issues. I just want to mention that in case it is seen as a problem > > The POC is available on GitHub: https://github.com/xzel23/darkmodedetector > > Please let me know if this would be an acceptable contribution, and if so, how to proceed. > > Axel > > PS: Sorry to the mods, I accidentally used the wrong sender previously. > From mark.reinhold at oracle.com Thu Oct 30 18:22:58 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 30 Oct 2025 18:22:58 +0000 Subject: JEP proposed to target JDK 26: 516: Ahead-of-Time Object Caching with Any GC Message-ID: <20251030182257.8EB02906@naskeag.niobe.net> The following JEP is proposed to target JDK 26: 516: Ahead-of-Time Object Caching with Any GC https://openjdk.org/jeps/516 Summary: Enhance the ahead-of-time cache, which enables the HotSpot Java Virtual Machine to improve startup and warmup time, so that it can be used with any garbage collector, including the low-latency Z Garbage Collector (ZGC). Achieve this by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than map them directly into memory in a GC-specific format. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Thursday, 6 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 26. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Oct 30 18:23:12 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 30 Oct 2025 18:23:12 +0000 Subject: JEP proposed to target JDK 26: 529: Vector API (Eleventh Incubator) Message-ID: <20251030182312.322FB908@naskeag.niobe.net> The following JEP is proposed to target JDK 26: 529: Vector API (Eleventh Incubator) https://openjdk.org/jeps/529 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Thursday, 6 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 26. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Oct 30 18:35:45 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 30 Oct 2025 18:35:45 +0000 Subject: JEP proposed to target JDK 26: 500: Prepare to Make Final Mean Final Message-ID: <20251030183545.0E8EFA02@naskeag.niobe.net> The following JEP is proposed to target JDK 26: 500: Prepare to Make Final Mean Final https://openjdk.org/jeps/500 Summary: Issue warnings about uses of deep reflection to mutate final fields. These warnings aim to prepare developers for a future release that ensures integrity by default by restricting final field mutation, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Thursday, 6 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 26. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Fri Oct 31 18:10:09 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 31 Oct 2025 18:10:09 +0000 Subject: JEP proposed to target JDK 26: 525: Structured Concurrency (Sixth Preview) Message-ID: <20251031181008.3C6C3416@naskeag.niobe.net> The following JEP is proposed to target JDK 26: 525: Structured Concurrency (Sixth Preview) https://openjdk.org/jeps/525 Summary: Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Friday, 7 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 26. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html