From mark.reinhold at oracle.com Tue Oct 1 13:33:13 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 1 Oct 2024 13:33:13 +0000 Subject: JEP proposed to target JDK 24: 484: Class-File API Message-ID: <20241001133311.9454A77CC58@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 484: Class-File API https://openjdk.org/jeps/484 Summary: Provide a standard API for parsing, generating, and transforming Java class files. 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 16:00 UTC on Tuesday, 8 October, 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 24. - 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 Wed Oct 2 12:44:52 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 2 Oct 2024 12:44:52 +0000 Subject: JEP proposed to target JDK 24: 489: Vector API (Ninth Incubator) Message-ID: <20241002124450.24B0F77CE25@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 489: Vector API (Ninth Incubator) https://openjdk.org/jeps/489 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, 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 16:00 UTC on Wednesday, 9 October, 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 24. - 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 Wed Oct 2 13:04:34 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 2 Oct 2024 13:04:34 +0000 Subject: New candidate JEP: 491: Synchronize Virtual Threads without Pinning Message-ID: <20241002130433.7264977CE2F@eggemoggin.niobe.net> https://openjdk.org/jeps/491 Summary: Improve the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform threads for use by other virtual threads. This will eliminate nearly all cases of virtual threads being pinnedjep444-pinning to platform threads, which severely restricts the number of virtual threads available to handle an application's workload. - Mark From mark.reinhold at oracle.com Wed Oct 2 13:14:32 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 2 Oct 2024 13:14:32 +0000 Subject: New candidate JEP: 492: Flexible Constructor Bodies (Third Preview) Message-ID: <20241002131430.EBCC577CE34@eggemoggin.niobe.net> https://openjdk.org/jeps/492 Summary: In constructors in the Java programming language, allow statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This is a preview language feature. - Mark From jesper.wilhelmsson at oracle.com Wed Oct 2 15:40:31 2024 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 2 Oct 2024 15:40:31 +0000 Subject: Upcoming update of a large number of issues in JBS Message-ID: <39E5F57D-8424-4977-A4AE-1DDF55410A4B@oracle.com> Hi OpenJDK Developers, There are a large number of issues in JBS (14,600+) that are currently in a state that violates the OpenJDK process for how issues should be closed. We intend to clean this up by performing a bulk update of these issues. No emails will be sent out from JBS as is usually the case when an issue is updated but you may still notice this update if you look at when the issues was most recently updated. If you run tools that monitor JBS activity or rely on the last updated date in issues, please be aware that this will happen over the next week. In short what this is all about is that issues that are closed with resolutions Duplicate, Won't Fix, Cannot Reproduce, Not an Issue, External, Migrated, and Withdrawn should always go directly to Closed - they should never be Resolved. But since JBS allows it of course it will happen every now and then. We are currently investigating if we can make it so that these resolutions can't be moved to Resolved. There is no change in the process involved here, just a cleanup to make existing issues follow the already existing process. The process is described here: https://openjdk.org/guide/#resolving-or-closing-an-issue As this is needed due to the lack of tooling to help us follow the process, I want to take this opportunity to remind everyone about the OpenJDK Developers' Guide (https://openjdk.org/guide). The Guide is a collection of guidelines for how to work in the OpenJDK project. It is assumed that every OpenJDK Developer has read through this document and understands how to work with our various tools and processes. Since the guide is continuously updated and has grown significantly over the last couple of years, this might be a good time to go back and look at what has changed since you looked at it the last time. Best regards, /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Wed Oct 2 17:16:45 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 2 Oct 2024 17:16:45 +0000 Subject: JEP proposed to target JDK 24: 475: Late Barrier Expansion for G1 In-Reply-To: <20240925132724.D2FBE77BBA3@eggemoggin.niobe.net> References: <20240925132724.D2FBE77BBA3@eggemoggin.niobe.net> Message-ID: <20241002131642.977043355@eggemoggin.niobe.net> 2024/9/25 9:27:26 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 24: > > 475: Late Barrier Expansion for G1 > https://openjdk.org/jeps/475 > > Summary: Simplify the implementation of the G1 garbage collector's > barriers, which record information about application memory accesses, > by shifting their expansion from early in the C2 JIT's compilation > pipeline to later. > > 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 16:00 UTC on Wednesday, 2 October, 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 24. Hearing no objection, I?ve targeted this JEP to JDK 24. - Mark From alex.buckley at oracle.com Thu Oct 3 21:08:08 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 3 Oct 2024 14:08:08 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development Message-ID: Everyone on jdk-dev is familiar with the six-month cadence of JDK feature releases (21, 22, 23 ...) and the three-month cadence of JDK update releases (21.0.1, 21.0.2, 21.0.3 ...). This two-pronged release model delivers major innovation as soon as it's ready, such as virtual threads in JDK 21 and the Foreign Function & Memory API in JDK 22, while providing a conservative stream of updates for users who prefer to stay on older releases. In recent years we've taken to calling this the "tip & tail" release model. The tip (the latest feature release) appeals to users building new systems, as well as users who want the largest possible set of bug fixes and performance improvements. The tails (various update releases) appeal to users maintaining long-lived systems, by backporting only select bug fixes and improvements and smartly avoiding the code churn associated with backporting new features. Minimizing backports from tip to tail means that more tails can be maintained, for longer. If you're interested in tip & tail, please see the informational JEP that we've just published: https://openjdk.org/jeps/14 If you'd prefer to watch a video, the JVM Language Summit keynote on "Java in 2024" is all about tip & tail: https://www.youtube.com/watch?v=NV4v7KXKQ-c We hope all library maintainers in the Java ecosystem will consider adopting the tip & tail release model. Users who want the latest and greatest would take the tip releases of libraries, which use tip releases of dependencies, all the way down to the tip JDK. Users who prefer stability would take the tail releases of libraries, which use tail releases of dependencies, all the way down to a tail JDK. It's a better experience for application developers, and surprisingly easy for library developers ("backport as little as possible"). The entire Java ecosystem stands to gain. Alex From johan.sjolen at oracle.com Fri Oct 4 07:12:55 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Fri, 4 Oct 2024 07:12:55 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski Message-ID: I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. Votes are due by October 18, 2024. Only current JDK Reviewers [1] 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 [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From thomas.schatzl at oracle.com Fri Oct 4 07:14:03 2024 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 4 Oct 2024 09:14:03 +0200 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <2be8e6cd-d887-4f8a-abe1-283312dd6649@oracle.com> Vote: yes From johan.sjolen at oracle.com Fri Oct 4 07:14:14 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Fri, 4 Oct 2024 07:14:14 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes Johan Sj?l?n ________________________________________ From: jdk-dev on behalf of Johan Sjolen Sent: Friday, October 4, 2024 09:12 To: jdk-dev at openjdk.org Subject: CFV: New JDK Reviewer: Gerard Ziemski I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. Votes are due by October 18, 2024. Only current JDK Reviewers [1] 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 [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From coleen.phillimore at oracle.com Fri Oct 4 12:31:41 2024 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Oct 2024 08:31:41 -0400 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes On 10/4/24 3:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From hohensee at amazon.com Fri Oct 4 13:37:27 2024 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Oct 2024 13:37:27 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski Message-ID: Vote: yes ?On 10/4/24, 12:13 AM, "jdk-dev on behalf of Johan Sjolen" on behalf of johan.sjolen at oracle.com > wrote: I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. Votes are due by October 18, 2024. Only current JDK Reviewers [1] 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 [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From claes.redestad at oracle.com Fri Oct 4 13:44:38 2024 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Oct 2024 13:44:38 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <690ACF88-583D-4FD0-AB6B-95B6422E7E73@oracle.com> Vote: yes /Claes > 4 okt. 2024 kl. 09:12 skrev Johan Sjolen : > > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From brian.burkhalter at oracle.com Fri Oct 4 15:48:44 2024 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 4 Oct 2024 15:48:44 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <9972DA1B-BE61-4381-8FC9-E23547423B69@oracle.com> Vote: yes From daniel.fuchs at oracle.com Fri Oct 4 15:52:10 2024 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Oct 2024 16:52:10 +0100 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 04/10/2024 08:12, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. From rehn at rivosinc.com Fri Oct 4 16:47:03 2024 From: rehn at rivosinc.com (Robbin Ehn) Date: Fri, 4 Oct 2024 18:47:03 +0200 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes /Robbin On Fri, Oct 4, 2024 at 9:13?AM Johan Sjolen wrote: > > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From philip.race at oracle.com Fri Oct 4 17:13:35 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 4 Oct 2024 10:13:35 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <915a981e-c779-4a5a-8c14-9f78a059aa35@oracle.com> Vote: yes -phil. From vladimir.kozlov at oracle.com Fri Oct 4 17:22:33 2024 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Oct 2024 10:22:33 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <25315087-0d7c-467a-b9f6-e036388dba9f@oracle.com> vote: yes Thanks, Vladimir K On 10/4/24 12:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From cay.horstmann at gmail.com Fri Oct 4 17:58:44 2024 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Fri, 4 Oct 2024 19:58:44 +0200 Subject: New candidate JEP: 485: Stream Gatherers In-Reply-To: <20240902175543.44781778E42@eggemoggin.niobe.net> References: <20240902175543.44781778E42@eggemoggin.niobe.net> Message-ID: <70dd1271-09b2-424c-ac40-6228756a8c86@gmail.com> Hi, I have some belated questions about the design choices in this API that I could not find addressed in the JEP. 1. Why aren't characteristics used to express "greediness/short-circuiting" or "sequentialness/parallelizability"? I understand that for the former I use ofGreedy/of, or implement Gatherers.Integrator.Greedy/Gatherers.Integrator. And for the latter, I use ofSequential/of, or, if I implement the Gatherer interface, have the combiner return defaultCombiner() or not. But it seems a bit complex and less familiar than the characteristics mechanism that exists for spliterators, streams, and collectors. The original design document (https://cr.openjdk.org/~vklang/Gatherers.html) used characteristics, so I wonder what motivated the change. 2. Why wasn't the combiner() designed to allow pushing of elements to the end of the first range's sink? Then distinctBy could be parallelized without buffering the elements. More generally, with some state fiddling one can then handle the elements around range splits. As it is, I don't see how to parallelize such computations other than to buffer all elements. I looked at the project at https://github.com/jhspetersson/packrat that implements a number of gatherers. Only one uses a combiner, to join buffers until their contents can be pushed in the finisher. Cheers, Cay On 02/09/2024 19:55, Mark Reinhold wrote: > https://openjdk.org/jeps/485 > > Summary: Enhance the Stream API to support custom intermediate > operations. This will allow stream pipelines to transform data in ways > that are not easily achievable with the existing built-in intermediate > operations. > > - Mark -- Cay S. Horstmann | https://horstmann.com From martin.doerr at sap.com Fri Oct 4 18:03:58 2024 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 4 Oct 2024 18:03:58 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Johan Sjolen Datum: Freitag, 4. Oktober 2024 um 09:13 An: jdk-dev at openjdk.org Betreff: CFV: New JDK Reviewer: Gerard Ziemski I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. Votes are due by October 18, 2024. Only current JDK Reviewers [1] 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 [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From patricio.chilano.mateo at oracle.com Fri Oct 4 18:41:12 2024 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Fri, 4 Oct 2024 14:41:12 -0400 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <6410483e-2df6-896c-c97c-99d8b31df81d@oracle.com> Vote: yes On 10/4/24 3:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From daniel.daugherty at oracle.com Fri Oct 4 23:16:42 2024 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 4 Oct 2024 17:16:42 -0600 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes Dan On 10/4/24 1:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From chris.plummer at oracle.com Sat Oct 5 03:53:35 2024 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 4 Oct 2024 20:53:35 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <95374deb-44ae-40bc-9bc7-5d411052f308@oracle.com> Vote: yes On 10/4/24 11:03 AM, Doerr, Martin wrote: > > Vote: yes > > Best regards, > > Martin > > *Von: *jdk-dev im Auftrag von Johan Sjolen > > *Datum: *Freitag, 4. Oktober 2024 um 09:13 > *An: *jdk-dev at openjdk.org > *Betreff: *CFV: New JDK Reviewer: Gerard Ziemski > > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has > contributed to many areas of the VM, often having a focus on OS X > enhancements. He is currently working on enhancements to Native Memory > Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot > JVM over the past 9 years, and reviewed over 100 changes in the > runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org > From karsten.silz at gmail.com Sat Oct 5 10:15:56 2024 From: karsten.silz at gmail.com (Karsten Silz) Date: Sat, 5 Oct 2024 12:15:56 +0200 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development Message-ID: <88D55A90-2B50-4BDB-827C-40B1205E5317@gmail.com> I have two questions regarding https://openjdk.org/jeps/14: How do you define success? And how do you measure it? Regards, Karsten Silz -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Mon Oct 7 07:51:26 2024 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 7 Oct 2024 13:21:26 +0530 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <7f369b64-55e4-4e30-8d9d-b24386ef01d3@gmail.com> vote: yes -Jaikiran On 04/10/24 12:42 pm, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From adinn at redhat.com Mon Oct 7 09:15:47 2024 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 7 Oct 2024 10:15:47 +0100 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <381ea347-e07c-494e-a14a-55c7492dce0d@redhat.com> Vote: yes On 04/10/2024 08:12, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From magnus.ihse.bursie at oracle.com Mon Oct 7 14:03:24 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Oct 2024 16:03:24 +0200 Subject: JDK mainline build fails on macosx with XCode 16 In-Reply-To: References: Message-ID: <2ae09717-9c84-4dc0-ae18-5a2849c7d509@oracle.com> On 2024-09-20 06:44, Jaikiran Pai wrote: > At this point, there is a workaround (also noted in the JDK-8340341 > issue and the workaround patch attached to that issue), but my > personal recommendation would be to stay with older versions of Xcode > that work, because even with the workaround it's unknown whether this > compiler issue has wider implications in other places of the JDK. This would also be a good time to remind everyone about the build instructions[1] regarding macOS. They state: > When updating Xcode, it is advisable to keep an older version for > building the JDK. To use a specific version of Xcode you have multiple > options: > > * Use |xcode-select -s| before running |configure|, e.g. > |xcode-select -s /Applications/Xcode13.1.app|. The drawback is > that the setting is system wide and you may have to revert it > after a JDK build. > * Use configure option |--with-xcode-path|, e.g. |configure > --with-xcode-path=/Applications/Xcode13.1.app| This allows using a > specific Xcode version for a JDK build, independently of the > active Xcode version by |xcode-select|. > That means, you should basically always keep your old version of Xcode before upgrading, by e.g. renaming it to /Applications/Xcode, or moving it out of /Applications. This is not the first time an Xcode upgrade broken the JDK build, it it is likely not the last time either. /Magnus [1] https://openjdk.org/groups/build/doc/building.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.cheung at oracle.com Mon Oct 7 16:03:06 2024 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 7 Oct 2024 09:03:06 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <56ad7280-a067-456d-ac1e-c3a1a93b0473@oracle.com> Vote: yes On 10/4/24 12:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From Bjoern at kautler.net Mon Oct 7 14:45:16 2024 From: Bjoern at kautler.net (=?UTF-8?Q?Bj=C3=B6rn_Kautler?=) Date: Mon, 7 Oct 2024 16:45:16 +0200 Subject: Specification of handling of absent annotations at runtime Message-ID: Hi Is there somewhere some definition how a JRE has to handle absent annotation classes at runtime? All JREs I know just skip annotations if their class is not present at runtime. But as far as I have seen neither the JLS nor the JVMS define how the situation has to be handled. Can anyone tell me, whether there is some specification or JCK rule or similar that definitely defines that this is the way how absent annotation classes have to be handled? Cheers Bj?rn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Oct 7 17:49:58 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 7 Oct 2024 17:49:58 +0000 Subject: New candidate JEP: 490: ZGC: Remove the Non-Generational Mode Message-ID: <20241007174955.B40B777D540@eggemoggin.niobe.net> https://openjdk.org/jeps/490 Summary: Remove the non-generational mode of the Z Garbage Collector (ZGC). - Mark From brent.christian at oracle.com Mon Oct 7 18:52:16 2024 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 7 Oct 2024 11:52:16 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <4d8b77c1-f9ee-4cb9-b730-197a516b7e08@oracle.com> Vote: Yes On 10/4/24 12:12 AM, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > From dean.long at oracle.com Mon Oct 7 18:54:21 2024 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 7 Oct 2024 11:54:21 -0700 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes From chen.l.liang at oracle.com Mon Oct 7 19:22:27 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 7 Oct 2024 19:22:27 +0000 Subject: Specification of handling of absent annotations at runtime In-Reply-To: References: Message-ID: Hello Bjorn, In JVMS 4.7, there's a minor provision right above this table https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7-300: > An implementation of the Java Virtual Machine may use the information that these attributes contain, or otherwise must silently ignore these attributes. This means that if an annotation class is absent, the JVM will never fail. (In fact, a missing annotation interface means that the attribute itself is still conformant.) Otherwise, the JVM doesn't care about the annotations. The annotation parsing is handled by core libraries, specifically, core reflection. The specification for parsing is available at https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/reflect/AnnotatedElement.html It appears that this specification does not mention what happens when the annotation interface of an annotation in the class file attribute cannot be found. The reference implementation omits such annotations: https://github.com/openjdk/jdk/blob/fc7244da96a9423146c4a46bcc3bbfc205900c3b/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java#L185 and is verified by a MissingTest.java For history, per https://bugs.openjdk.org/browse/JDK-6322301 it seems that ignoring is the correct way; but people seem to just have forgotten to add it to the specification of AnnotatedElement. So, in conclusion, skipping is the right way and enforced by tests. We probably should make it to the core reflection specification. Please send future discussion to the core-libs-dev list, as this problem now becomes specific to core reflection. Regards, Chen ________________________________ From: jdk-dev on behalf of Bj?rn Kautler Sent: Monday, October 7, 2024 9:45 AM To: jdk-dev at openjdk.org Subject: Specification of handling of absent annotations at runtime Hi Is there somewhere some definition how a JRE has to handle absent annotation classes at runtime? All JREs I know just skip annotations if their class is not present at runtime. But as far as I have seen neither the JLS nor the JVMS define how the situation has to be handled. Can anyone tell me, whether there is some specification or JCK rule or similar that definitely defines that this is the way how absent annotation classes have to be handled? Cheers Bj?rn -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Oct 8 11:08:58 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 8 Oct 2024 13:08:58 +0200 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <734a9cd8-e599-4eda-9e90-2a3c27bac10b@oracle.com> Vote: yes /Magnus On 2024-10-04 09:12, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From mark.reinhold at oracle.com Tue Oct 8 20:02:40 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 8 Oct 2024 20:02:40 +0000 Subject: JEP proposed to target JDK 24: 484: Class-File API In-Reply-To: <20241001133311.9454A77CC58@eggemoggin.niobe.net> References: <20241001133311.9454A77CC58@eggemoggin.niobe.net> Message-ID: <20241008160239.24024202@eggemoggin.niobe.net> 2024/10/1 9:33:13 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 24: > > 484: Class-File API > https://openjdk.org/jeps/484 > > Summary: Provide a standard API for parsing, generating, and > transforming Java class files. > > 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 16:00 UTC on Tuesday, 8 October, 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 24. Hearing no objections, I?ve targeted this JEP to JDK 24. - Mark From sandhya.viswanathan at intel.com Tue Oct 8 22:09:15 2024 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 8 Oct 2024 22:09:15 +0000 Subject: CFV: New JDK Committer: Smita Kamath Message-ID: I hereby nominate Smita Kamath to JDK Committer. Smita has been a member of the Java team in Intel since 2016 focusing on JVM optimizations for Intel platforms and has contributed 15 patches to JDK [3]. Votes are due by October 22, 2024, 23.59 PDT. Only current JDK Committers [1] 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 [2]. Best regards, Sandhya [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author-name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Oct 8 22:24:08 2024 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 8 Oct 2024 15:24:08 -0700 Subject: CFV: New JDK Committer: Smita Kamath In-Reply-To: References: Message-ID: <55d57215-10ba-4860-95bd-6b0fbd14ffc6@oracle.com> Vote: yes Thanks, Vladimir K On 10/8/24 3:09 PM, Viswanathan, Sandhya wrote: > I hereby nominate Smita Kamath to JDK Committer. > > Smita has been a member of the Java team in Intel since 2016 focusing on JVM optimizations for Intel platforms and has > contributed 15 patches to JDK [3]. > > Votes are due by October 22, 2024, 23.59 PDT. > > Only current JDK Committers [1] 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 [2]. > > Best regards, > > Sandhya > > [1] https://openjdk.org/census > > [2] https://openjdk.org/projects/#committer-vote > > [3] > https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author-name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc > > > > From anthony.scarpino at oracle.com Tue Oct 8 22:47:14 2024 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 8 Oct 2024 15:47:14 -0700 Subject: CFV: New JDK Committer: Smita Kamath In-Reply-To: References: Message-ID: <15af082b-fa5b-43be-b693-e97153d5f040@oracle.com> Vote: yes Tony On 10/8/24 3:09 PM, Viswanathan, Sandhya wrote: > I hereby nominate Smita Kamath to JDK Committer. > > Smita has been a member of the Java team in Intel since 2016 focusing on JVM > optimizations for Intel platforms and has contributed 15 patches to JDK [3]. > > Votes are due by October 22, 2024, 23.59 PDT. > > Only current JDK Committers [1] 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 [2]. > > Best regards, > > Sandhya > > [1] https://openjdk.org/census > > [2] https://openjdk.org/projects/#committer-vote projects/#committer-vote> > > [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author- > name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc github.com/search?q=repo%3Aopenjdk%2Fjdk+author- > name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc> > > name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc%E2%80%9D> > From tobias.hartmann at oracle.com Wed Oct 9 07:19:17 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 9 Oct 2024 09:19:17 +0200 Subject: CFV: New JDK Committer: Smita Kamath In-Reply-To: References: Message-ID: <69fecc0d-4eaa-4102-9538-6bb6fdc3debb@oracle.com> Vote: yes Best regards, Tobias On 10/9/24 00:09, Viswanathan, Sandhya wrote: > I hereby nominate Smita Kamath to JDK Committer. > > Smita has been a member of the Java team in Intel since 2016 focusing on JVM optimizations for Intel platforms and has contributed 15 patches to JDK [3]. > > Votes are due by October 22, 2024, 23.59 PDT. > > Only current JDK Committers [1] 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 [2]. > > Best regards, > > Sandhya > > [1] https://openjdk.org/census > > [2] https://openjdk.org/projects/#committer-vote > > [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author-name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc > > > From stefan.karlsson at oracle.com Wed Oct 9 13:09:51 2024 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 9 Oct 2024 15:09:51 +0200 Subject: =?UTF-8?Q?Result=3A_New_JDK_Committer=3A_Joel_Sikstr=C3=B6m?= Message-ID: <0cc5b160-fb71-4bbb-a552-1ea7e37e155c@oracle.com> Voting for Joel Sikstr?m [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Stefan Karlsson [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-September/009402.html From sandhya.viswanathan at intel.com Wed Oct 9 16:23:19 2024 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 9 Oct 2024 16:23:19 +0000 Subject: CFV: New JDK Committer: Smita Kamath In-Reply-To: References: Message-ID: Vote: Yes Best Regards, Sandhya From: jdk-dev On Behalf Of Viswanathan, Sandhya Sent: Tuesday, October 08, 2024 3:09 PM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Smita Kamath I hereby nominate Smita Kamath to JDK Committer. Smita has been a member of the Java team in Intel since 2016 focusing on JVM optimizations for Intel platforms and has contributed 15 patches to JDK [3]. Votes are due by October 22, 2024, 23.59 PDT. Only current JDK Committers [1] 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 [2]. Best regards, Sandhya [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author-name%3A%22Smita+Kamath%22&type=commits&s=committer-date&o=desc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Wed Oct 9 23:47:42 2024 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Wed, 9 Oct 2024 23:47:42 +0000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: Vote: yes From: jdk-dev on behalf of Johan Sjolen Date: Friday, October 4, 2024 at 12:13?AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Reviewer: Gerard Ziemski I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. Votes are due by October 18, 2024. Only current JDK Reviewers [1] 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 [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbien42 at gmail.com Thu Oct 10 06:57:13 2024 From: mbien42 at gmail.com (Michael Bien) Date: Thu, 10 Oct 2024 08:57:13 +0200 Subject: Logging JVM exit (in context of JEP 486) Message-ID: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> Hello, Calls to System.exit() can be currently tracked by setting the "java.lang.Runtime" logger to DEBUG (it even dumps the stack trace which is nice). However, I couldn't find an equivalent for Runtime.getRuntime().halt(). Are there plans to add more logging to debug common JVM exit events? (if this was already discussed elsewhere - super sorry wasn't able to find anything) best regards, michael From alan.bateman at oracle.com Thu Oct 10 09:16:24 2024 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 10 Oct 2024 11:16:24 +0200 Subject: Logging JVM exit (in context of JEP 486) In-Reply-To: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> References: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> Message-ID: <56eee9ce-9c61-435a-8131-88a622491237@oracle.com> On 10/10/2024 08:57, Michael Bien wrote: > Hello, > > Calls to System.exit() can be currently tracked by setting the > "java.lang.Runtime" logger to DEBUG (it even dumps the stack trace > which is nice). However, I couldn't find an equivalent for > Runtime.getRuntime().halt(). Are there plans to add more logging to > debug common JVM exit events? > > (if this was already discussed elsewhere - super sorry wasn't able to > find anything) Logging involves executing arbitrary Java so not for halt time. It's come up a few times, I think the most recent on core-libs-dev was Aug and/or Sept 2023, you'll need to search through the archives to find it. -Alan From mark.reinhold at oracle.com Thu Oct 10 12:52:57 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 10 Oct 2024 12:52:57 +0000 Subject: JEP proposed to target JDK 24: 489: Vector API (Ninth Incubator) In-Reply-To: <20241002124450.24B0F77CE25@eggemoggin.niobe.net> References: <20241002124450.24B0F77CE25@eggemoggin.niobe.net> Message-ID: <20241010085255.42849335@eggemoggin.niobe.net> 2024/10/2 8:44:52 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 24: > > 489: Vector API (Ninth Incubator) > https://openjdk.org/jeps/489 > > Summary: Introduce an API to express vector computations that reliably > compile at runtime to optimal vector instructions on supported CPU > architectures, 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 16:00 UTC on Wednesday, 9 October, 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 24. Hearing no objections, I?ve targeted this JEP to JDK 24. - Mark From loikeseke at gmail.com Fri Oct 11 10:52:39 2024 From: loikeseke at gmail.com (=?UTF-8?Q?Lo=C3=AFc_MATHIEU?=) Date: Fri, 11 Oct 2024 12:52:39 +0200 Subject: New candidate JEP: 486: Permanently Disable the Security Manager In-Reply-To: <20240926075534.874144001@eggemoggin.niobe.net> References: <20240926075534.874144001@eggemoggin.niobe.net> Message-ID: Hi, I work for Kestra, a data orchestrator: https://www.kestra.io. Kestra handles workflows made of tasks and triggers, both of which are plugins. We provide more than 500 plugins, but users can also bring their own plugins in the form of JARs they put in a specific directory. Our plugin mechanism includes security features using the Security Manager, this is important as administrators need to be sure that plugins behave securely; our security checks are: - A plugin cannot start new threads - A plugin cannot start new processes - A plugin cannot exit the VM - A plugin cannot read files out of its working directory This feature can be configured with allowed plugins / forbidden plugins to be able to cherry-pick which plugin is allowed to perform those actions or not. As most plugins are written in Java and installed by administrators, we also have some plugins that allow running scripts (Nashorn, Jython, Groovy), which we cannot control by nature. We currently run in Java 21, but if the Security Manager is removed, it would be difficult for us to use Java 24+ as it would mean giving up some security features that our users rely on (including ourselves in our work-in-progress SaaS offering). I understand that the current implementation of the SecurityManager is not ideal, but I would love a replacement, at least for part of what it offers today. On top of my mind, but I know that if a replacement would be created, it would not be that one, something close to what we have with structured concurrency would be great: try (SecurityScope.allowNewThread(false).allowNewProcesses(false).canExitVM(false).allowFileAccess(fileName -> file.startWith(workingDir)) { // run the plugin code plugin.run(); } I know that other people already ask to restrict, for example, exiting the VM. Other tools also have a plugin system and a security manager (like Elasticsearch), so despite what is said in this JEP, the Security Manager is still used. Removing it without any replacement, at least for part of its mechanism, would lower the security of the Java platform for those using it. Regards, Lo?c PS: Sorry Mark Reinhold, I first only respond to you only so I resend to all Le jeu. 26 sept. 2024 ? 13:55, Mark Reinhold a ?crit : > // Correcting Sean?s e-mail address > > https://openjdk.org/jeps/486 > > Summary: The Security Manager has not been the primary means of > securing client-side Java code for many years, it has rarely been used > to secure server-side code, and it is costly to maintain. We therefore > deprecated it for removal in Java 17 via JEP 411 (2021). As the next > step toward removing the Security Manager, we will revise the Java > Platform specification so that developers cannot enable it and other > Platform classes do not refer to it. This change will have no impact > on the vast majority of applications, libraries, and tools. We will > remove the Security Manager API in a future release. > > - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbien42 at gmail.com Mon Oct 14 07:22:37 2024 From: mbien42 at gmail.com (Michael Bien) Date: Mon, 14 Oct 2024 09:22:37 +0200 Subject: Logging JVM exit (in context of JEP 486) In-Reply-To: <56eee9ce-9c61-435a-8131-88a622491237@oracle.com> References: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> <56eee9ce-9c61-435a-8131-88a622491237@oracle.com> Message-ID: <5532b1e4-2b51-4b02-85a5-0749995a6525@gmail.com> On 10.10.24 11:16, Alan Bateman wrote: > > > On 10/10/2024 08:57, Michael Bien wrote: >> Hello, >> >> Calls to System.exit() can be currently tracked by setting the >> "java.lang.Runtime" logger to DEBUG (it even dumps the stack trace >> which is nice). However, I couldn't find an equivalent for >> Runtime.getRuntime().halt(). Are there plans to add more logging to >> debug common JVM exit events? >> >> (if this was already discussed elsewhere - super sorry wasn't able to >> find anything) > > Logging involves executing arbitrary Java so not for halt time. It's > come up a few times, I think the most recent on core-libs-dev was Aug > and/or Sept 2023, you'll need to search through the archives to find it. Thanks! I found JDK-8301627 and JDK-8303198 and the discussion on the PRs also gave some context. + https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19309.html (I made the mistake to mainly search through security manager threads since I somehow expected that it would be discussed there too) The JVM would still be able to log something to console (in native beforeHalt() or halt0()) without the application/logging callback issue? -Xlog:safepoint+stats=info seems to log some kind of exit cause, it is the wrong way around though :) System.exit() / halt() will print: [0,419s][info][safepoint,stats] Exit?????? 1 regular process exit (no-non daemon threads remaining) prints: [0,454s][info][safepoint,stats] Halt????? 1 best regards, michael > > -Alan From nizar.benalla at oracle.com Mon Oct 14 08:04:08 2024 From: nizar.benalla at oracle.com (Nizar Benalla) Date: Mon, 14 Oct 2024 08:04:08 +0000 Subject: Introduction tests for `@since` Tags in OpenJDK In-Reply-To: References: Message-ID: Hello JDK folk, This is a follow-up to my previous email[1] regarding `@since` tests. These tests look at the ?`@since`? tag in the documentation comment, compare it to the release in which the element first appeared, and report an error if the values don't match. The releases used to determine the expected value of ?`@since`? are taken from the historical data built into javac. We process JDK 9-current (classfiles only) and build a map with a unique ID for each element and the versions in which it appeared. We then compare the values in the map to the ones in the source code. The spec for `@since` has been updated[2] There is an option to pass an exclude list, which can be used to work around any temporary issues that may occur. [1]: https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html [2]: https://download.java.net/java/early_access/jdk24/docs/specs/javadoc/doc-comment-spec.html#since ________________________________ From: Nizar Benalla Sent: Wednesday, June 26, 2024 9:42 AM To: jdk-dev at openjdk.org Subject: Introduction tests for `@since` Tags in OpenJDK Hello OpenJDK Developers, This note is to inform you about a new effort regarding `@since` tags in our codebase. Starting now, their values will be tested by a collection of Tier 3 tests. Tests: - A test will be implemented for each module. - To run all tests before a push, use: ``` make test TEST=jdk_since_checks ``` - To run a test for a specific module using jtreg, you can provide a directory path. For example, for the `java.base` module: ``` jtreg [OPTIONS] test/jdk/tools/sincechecker/modules/java_base/CheckSince_javaBase.java ``` 2. Performance: - Running the test for the `java.base` module only takes 20 seconds. - Running the test for other modules can take 10 seconds. - Running all of the tests can take up to 5 minutes. Context: The `@since` information is now of increased importance due to its role in the "new API in JDK$N" pages. The accuracy of this data is crucial for developers to track new features and changes. As a rule, every declaration should have an @since tag, except for members where it would be the same as for the enclosing class or interface. The rules for determining @since tags are detailed in this [CSR][2]. Additional Information: - Scope: The tests currently focus on code from JDK 9 onwards. - Preview Features: Handling of preview elements is as described in [JEP 12][3]. - Covariant Overrides: These are treated as new methods, requiring a new `@since` tag. We will be making a few fixes to add missing @since tags in the documentation. After these fixes, this process should prevent such mistakes from happening in the future. Thank you, Nizar [1]: https://docs.oracle.com/en/java/javase/22/docs/api/new-list.html [2]: https://bugs.openjdk.org/browse/JDK-8334325 [3]: https://openjdk.org/jeps/12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Oct 14 11:03:51 2024 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 14 Oct 2024 11:03:51 +0000 Subject: Logging JVM exit (in context of JEP 486) In-Reply-To: <5532b1e4-2b51-4b02-85a5-0749995a6525@gmail.com> References: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> <56eee9ce-9c61-435a-8131-88a622491237@oracle.com> <5532b1e4-2b51-4b02-85a5-0749995a6525@gmail.com> Message-ID: Maybe not exactly what you want, but there is also the JFR Shutdown event https://sap.github.io/SapMachine/jfrevents/21.html#shutdown . This is generated in JVM_BeforeHalt : https://github.com/openjdk/jdk/blob/037f11b864734734dd7fbce029b2e8b4bc17f3ab/src/hotspot/share/prims/jvm.cpp#L436 ( my colleague Johannes also mentioned the JVM shutdown hooks - might be also interesting for you https://www.baeldung.com/jvm-shutdown-hooks ) Best regards, Matthias >The JVM would still be able to log something to console (in native >beforeHalt() or halt0()) without the application/logging callback issue? > >-Xlog:safepoint+stats=info seems to log some kind of exit cause, it is >the wrong way around though :) > >System.exit() / halt() will print: >[0,419s][info][safepoint,stats] Exit 1 > >regular process exit (no-non daemon threads remaining) prints: > >[0,454s][info][safepoint,stats] Halt 1 From mbien42 at gmail.com Mon Oct 14 11:55:23 2024 From: mbien42 at gmail.com (Michael Bien) Date: Mon, 14 Oct 2024 13:55:23 +0200 Subject: Logging JVM exit (in context of JEP 486) In-Reply-To: References: <79aac469-7e79-4123-afa1-2dfdab73258f@gmail.com> <56eee9ce-9c61-435a-8131-88a622491237@oracle.com> <5532b1e4-2b51-4b02-85a5-0749995a6525@gmail.com> Message-ID: <2f544e09-b18e-4868-a00d-9ba5f837524e@gmail.com> Hi Matthias, for some reason I simply assumed that JFR would also only track exit but not halt, but it does! Works great - I sometimes forget to check the obvious options. (btw shutdown hooks don't run on halt, so this wouldn't work) thanks and best regards, michael On 14.10.24 13:03, Baesken, Matthias wrote: > Maybe not exactly what you want, but there is also the JFR Shutdown event https://sap.github.io/SapMachine/jfrevents/21.html#shutdown . > This is generated in JVM_BeforeHalt : > > https://github.com/openjdk/jdk/blob/037f11b864734734dd7fbce029b2e8b4bc17f3ab/src/hotspot/share/prims/jvm.cpp#L436 > > > ( my colleague Johannes also mentioned the JVM shutdown hooks - might be also interesting for you https://www.baeldung.com/jvm-shutdown-hooks ) > > Best regards, Matthias > > >> The JVM would still be able to log something to console (in native >> beforeHalt() or halt0()) without the application/logging callback issue? >> >> -Xlog:safepoint+stats=info seems to log some kind of exit cause, it is >> the wrong way around though :) >> >> System.exit() / halt() will print: >> [0,419s][info][safepoint,stats] Exit 1 >> >> regular process exit (no-non daemon threads remaining) prints: >> >> [0,454s][info][safepoint,stats] Halt 1 > From david.holmes at oracle.com Tue Oct 15 06:34:00 2024 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2024 16:34:00 +1000 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <0a45bff0-44b1-451a-90ab-4bcfae1ea119@oracle.com> Vote: yes David On 4/10/2024 5:12 pm, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From raffaello.giulietti at oracle.com Tue Oct 15 08:26:40 2024 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Tue, 15 Oct 2024 10:26:40 +0200 Subject: CFV: New JDK Reviewer: Gerard Ziemski In-Reply-To: References: Message-ID: <3e2df6cc-0a87-43cc-9d77-98943d9e3ece@oracle.com> Vote: yes On 2024-10-04 09:12, Johan Sjolen wrote: > I hereby nominate Gerard Ziemski (gziemski) to JDK Reviewer. > > Gerard is a member of the HotSpot runtime team at Oracle. He has contributed to many areas of the VM, often having a focus on OS X enhancements. He is currently working on enhancements to Native Memory Tracking (NMT). He has contributed over 100 changes [3] to the HotSpot JVM over the past 9 years, and reviewed over 100 changes in the runtime area since 2020. > > Votes are due by October 18, 2024. > > Only current JDK Reviewers [1] 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 [2]. > > Johan Sj?l?n > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=gerard-ziemski > https://github.com/openjdk/jdk/commits/master/?author=gziemski%40openjdk.org From anleonar at redhat.com Wed Oct 16 08:38:48 2024 From: anleonar at redhat.com (Andrew Leonard) Date: Wed, 16 Oct 2024 09:38:48 +0100 Subject: Is jdk-23.0.1-ga tag correct? No jdk-23.0.1+B build tags? Message-ID: Hi, I notice jdk-23.0.1-ga has been tagged: https://github.com/openjdk/jdk23u/releases/tag/jdk-23.0.1-ga but there are no "build" tags (jdk-23.0.1+B) is this correct?, has there been a change of behaviour with regards build tagging? Thanks Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Wed Oct 16 12:08:53 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 16 Oct 2024 12:08:53 +0000 Subject: JEP proposed to target JDK 24: 485: Stream Gatherers Message-ID: <20241016120850.E4CEE77E499@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 485: Stream Gatherers https://openjdk.org/jeps/485 Summary: Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. 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 16:00 UTC on Wednesday, 23 October, 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 24. - 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 Wed Oct 16 12:10:50 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 16 Oct 2024 12:10:50 +0000 Subject: Proposed schedule for JDK 24 In-Reply-To: <20240925093911.913421608@eggemoggin.niobe.net> References: <20240925093911.913421608@eggemoggin.niobe.net> Message-ID: <20241016081049.779928757@eggemoggin.niobe.net> 2024/9/25 9:39:13 -0400, mark.reinhold at oracle.com: > Here is the proposed schedule for JDK 24: > > 2024/12/05 Rampdown Phase One > 2025/01/16 Rampdown Phase Two > 2025/02/06 Initial Release Candidate > 2025/02/20 Final Release Candidate > 2025/03/18 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 16:00 UTC next Wednesday, 2 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 24. Hearing no objections, this is the schedule for JDK 24. - Mark From christian.s.stein at oracle.com Thu Oct 17 11:22:38 2024 From: christian.s.stein at oracle.com (Christian Stein) Date: Thu, 17 Oct 2024 11:22:38 +0000 Subject: Coming soon: jtreg 7.5 Message-ID: JDK folk, This is a general heads-up that jtreg 7.5 is ready for use and that we should soon update JDK to use it. The most significant changes in jtreg 7.5 are the restoration of the jtdiff tool and new support for a LIBRARY.properties file in the directory specified in the @library tag of tests. We also updated jtreg to include JUnit 5.11.0 Find a listing of all noteworthy changes at [1]. The plan is to make jtreg 7.5 the default version for JDK 24-ea starting November 2024. Thanks to everyone who has helped thus far! [1] https://github.com/openjdk/jtreg/blob/jtreg-7.5+1/CHANGELOG.md From alan.bateman at oracle.com Fri Oct 18 10:40:16 2024 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 18 Oct 2024 11:40:16 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang Message-ID: I hereby nominate Viktor Klang to jdk Reviewer. Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. Votes are due by 23.59 UTC on Friday, 1 November. Only current jdk Reviewers [4] 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 [5]. -Alan [1] https://openjdk.org/jeps/485 [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com [4] https://openjdk.org/census [5] https://openjdk.org/projects/#reviewer-vote From sgehwolf at redhat.com Fri Oct 18 10:45:12 2024 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Oct 2024 12:45:12 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes On Fri, 2024-10-18 at 11:40 +0100, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From shipilev at amazon.de Fri Oct 18 10:46:16 2024 From: shipilev at amazon.de (Aleksey Shipilev) Date: Fri, 18 Oct 2024 12:46:16 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <2f2aefe1-385b-4c61-b1ac-cafa5286b7e8@amazon.de> Vote: yes On 18.10.24 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From aph-open at littlepinkcloud.com Fri Oct 18 10:48:32 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 18 Oct 2024 11:48:32 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <8c810e5b-0cec-45b1-93d4-4ab426bc81d8@littlepinkcloud.com> Vote: yes. On 10/18/24 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jai.forums2013 at gmail.com Fri Oct 18 11:15:10 2024 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 18 Oct 2024 16:45:10 +0530 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: vote: yes -Jaikiran On 18/10/24 4:10 pm, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From jan.lahoda at oracle.com Fri Oct 18 11:15:18 2024 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Oct 2024 13:15:18 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: vote: yes On 18. 10. 24 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From rehn at rivosinc.com Fri Oct 18 11:16:36 2024 From: rehn at rivosinc.com (Robbin Ehn) Date: Fri, 18 Oct 2024 13:16:36 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes On Fri, Oct 18, 2024 at 12:40?PM Alan Bateman wrote: > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From stefan.karlsson at oracle.com Fri Oct 18 11:17:53 2024 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Oct 2024 13:17:53 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <6692b4b2-7119-4cda-8a84-689ccb2b72ca@oracle.com> Vote: yes StefanK On 2024-10-18 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From claes.redestad at oracle.com Fri Oct 18 11:26:39 2024 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Oct 2024 11:26:39 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <238E746B-F887-4B31-91C7-E579889B5C88@oracle.com> Vote: yes ? Claes > 18 okt. 2024 kl. 12:40 skrev Alan Bateman : > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From johan.sjolen at oracle.com Fri Oct 18 11:31:03 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Fri, 18 Oct 2024 11:31:03 +0000 Subject: Result: New JDK Reviewer: Gerard Ziemski Message-ID: Voting for Gerard Ziemski [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Johan Sj?l?n [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009434.html From chegar999 at gmail.com Fri Oct 18 11:34:53 2024 From: chegar999 at gmail.com (Chris Hegarty) Date: Fri, 18 Oct 2024 12:34:53 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: YES -Chris. On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From erik.osterlund at oracle.com Fri Oct 18 11:37:05 2024 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 18 Oct 2024 11:37:05 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes /Erik > On 18 Oct 2024, at 12:40, Alan Bateman wrote: > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From jesper.wilhelmsson at oracle.com Fri Oct 18 11:45:20 2024 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 18 Oct 2024 11:45:20 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: Yes /Jesper > On 18 Oct 2024, at 12:40, Alan Bateman wrote: > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From lance.andersen at oracle.com Fri Oct 18 12:05:13 2024 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Oct 2024 12:05:13 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <65D7832A-22D8-4A53-8A1A-CCF6AC698CCE@oracle.com> Vote: yes On Oct 18, 2024, at 6:40?AM, Alan Bateman wrote: I hereby nominate Viktor Klang to jdk Reviewer. Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. Votes are due by 23.59 UTC on Friday, 1 November. Only current jdk Reviewers [4] 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 [5]. -Alan [1] https://openjdk.org/jeps/485 [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com [4] https://openjdk.org/census [5] https://openjdk.org/projects/#reviewer-vote [oracle_sig_logo.gif] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From sean.coffey at oracle.com Fri Oct 18 12:29:23 2024 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=) Date: Fri, 18 Oct 2024 13:29:23 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes regards, Sean. On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From raffaello.giulietti at oracle.com Fri Oct 18 12:30:18 2024 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 18 Oct 2024 14:30:18 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes On 2024-10-18 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/? > author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/? > author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From vicente.romero at oracle.com Fri Oct 18 12:30:50 2024 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 Oct 2024 08:30:50 -0400 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: vote: yes On 10/18/24 06:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From daniel.fuchs at oracle.com Fri Oct 18 12:54:27 2024 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Oct 2024 13:54:27 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <468efcf2-3569-4d79-9f49-fe8a927b1ee8@oracle.com> Vote: yes best regards, -- daniel On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From roger.riggs at oracle.com Fri Oct 18 12:57:34 2024 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 18 Oct 2024 08:57:34 -0400 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes On 10/18/24 6:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From chen.l.liang at oracle.com Fri Oct 18 13:24:45 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 18 Oct 2024 13:24:45 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes ________________________________ From: jdk-dev on behalf of Alan Bateman Sent: Friday, October 18, 2024 5:40 AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Reviewer: Viktor Klang I hereby nominate Viktor Klang to jdk Reviewer. Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. Votes are due by 23.59 UTC on Friday, 1 November. Only current jdk Reviewers [4] 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 [5]. -Alan [1] https://openjdk.org/jeps/485 [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com [4] https://openjdk.org/census [5] https://openjdk.org/projects/#reviewer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Oct 18 16:07:46 2024 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Oct 2024 09:07:46 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes Mandy On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From naoto.sato at oracle.com Fri Oct 18 16:08:33 2024 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 18 Oct 2024 09:08:33 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes Naoto On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/? > author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/? > author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From huizhe.wang at oracle.com Fri Oct 18 16:14:37 2024 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Oct 2024 09:14:37 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes Joe (joehw) On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From brent.christian at oracle.com Fri Oct 18 16:46:34 2024 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 18 Oct 2024 09:46:34 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <446aa1bb-9f85-4df7-bed1-2800f1a412a4@oracle.com> Vote: Yes On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > From mikael.vidstedt at oracle.com Fri Oct 18 17:40:24 2024 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 18 Oct 2024 17:40:24 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <401E6C41-814D-4F60-8FA8-F07F26606A65@oracle.com> Vote: yes Cheers, Mikael > On Oct 18, 2024, at 3:40?AM, Alan Bateman wrote: > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From patricio.chilano.mateo at oracle.com Fri Oct 18 18:13:27 2024 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Fri, 18 Oct 2024 14:13:27 -0400 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <0fce3876-e5e7-72ff-4868-3938beb78066@oracle.com> Vote: yes On 10/18/24 6:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From vladimir.kozlov at oracle.com Fri Oct 18 18:56:39 2024 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2024 11:56:39 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <8b1ad731-7628-45e0-88cc-181ad4ef99c1@oracle.com> Vote: yes Thanks, Vladimir K On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with > his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has > ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From philip.race at oracle.com Fri Oct 18 19:46:39 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 18 Oct 2024 12:46:39 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <4718b06d-6ed3-4fd3-b637-00eb579d9322@oracle.com> Vote: yes -phil. From brian.burkhalter at oracle.com Fri Oct 18 20:26:55 2024 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 18 Oct 2024 20:26:55 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes From michael.x.mcmahon at oracle.com Fri Oct 18 21:28:21 2024 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 18 Oct 2024 22:28:21 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: Yes On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Oct 18 23:04:19 2024 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Oct 2024 23:04:19 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang Message-ID: <0B9EC875-6AC3-4D27-8423-070552E45D23@amazon.com> Vote: yes ?On 10/18/24, 3:40 AM, "jdk-dev on behalf of Alan Bateman" on behalf of alan.bateman at oracle.com > wrote: I hereby nominate Viktor Klang to jdk Reviewer. Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. Votes are due by 23.59 UTC on Friday, 1 November. Only current jdk Reviewers [4] 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 [5]. -Alan [1] https://openjdk.org/jeps/485 [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com [4] https://openjdk.org/census [5] https://openjdk.org/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Sat Oct 19 00:59:50 2024 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Oct 2024 17:59:50 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <6dd2038b-3efb-4df5-9589-1143f89e80e5@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 10/18/24 03:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. From javalists at cbfiddle.com Sat Oct 19 01:59:15 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 18 Oct 2024 18:59:15 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development Message-ID: I appreciate the emphasis in this JEP on minimizing the burden of backporting changes. However, for me, maintaining multiple releases is also burdensome. For that reason, I target library development to JDK 8 and probably will continue to do so as long as JDK 8 is relevant. I understand that there are disadvantages to not being able to use newer language features, but so far, the disadvantages of maintaining multiple releases outweigh the advantages of the new language features. Value types are tempting, primarily as they impact library APIs, but I will probably try to resist using them as long as I can. I have a suggestion that might be helpful to me and others in the same boat. Are there language features that do not impact the byte code and do not require runtime support? If so, would it be possible to support those features (using a compiler flag) when targeting older releases like JDK 8? Features that might have this property that I would find useful include * flexible constructor bodies * local variable type inference * string templates * text blocks * unnamed variables * pattern matching for instanceof Something that might be useful in the future is support for multi-release class files. That might allow some language features that impact byte code to be supported on older JDKs. I?m thinking specifically of value types. If value types could have run as ordinary classes in older JDKs that would be Nirvana. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Mon Oct 21 07:44:20 2024 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 21 Oct 2024 09:44:20 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes StefanJ On 2024-10-18 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Oct 21 07:45:26 2024 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Oct 2024 09:45:26 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes On 18.10.24 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From pavel.rappo at oracle.com Mon Oct 21 09:37:48 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 21 Oct 2024 09:37:48 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes -Pavel > On 18 Oct 2024, at 11:40, Alan Bateman wrote: > > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From david.holmes at oracle.com Mon Oct 21 10:03:20 2024 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Oct 2024 20:03:20 +1000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes David On 18/10/2024 8:40 pm, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From adinn at redhat.com Mon Oct 21 11:17:27 2024 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 21 Oct 2024 12:17:27 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <38c3d0a1-a285-4a0b-af41-8a316f2b6731@redhat.com> Vote: yes On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle > two years ago. Many of you will be familiar with his work on Stream > Gatherers, currently proposed to move to a permanent feature in JDK 24 > with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in > the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From maurizio.cimadamore at oracle.com Mon Oct 21 11:18:20 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 Oct 2024 12:18:20 +0100 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes Maurizio On 18/10/2024 11:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From magnus.ihse.bursie at oracle.com Mon Oct 21 12:48:16 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2024 14:48:16 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <69f54d13-63c8-439f-85c6-54e3edfb225d@oracle.com> Vote: yes /Magnus On 2024-10-18 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From mark.reinhold at oracle.com Mon Oct 21 16:14:19 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 21 Oct 2024 16:14:19 +0000 Subject: New candidate JEP: 493: Linking Run-Time Images without JMODs Message-ID: <20241021161418.0CD9677ED45@eggemoggin.niobe.net> https://openjdk.org/jeps/493 Summary: Reduce the size of the JDK by approximately 25% by enabling the jlink tool to create custom run-time images without using the JDK's JMOD files. This feature must be enabled when the JDK is built; it will not be enabled by default, and some JDK vendors may choose not to enable it. - Mark From iris.clark at oracle.com Mon Oct 21 16:25:09 2024 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 21 Oct 2024 16:25:09 +0000 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: yes Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Oct 21 17:15:06 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 21 Oct 2024 10:15:06 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: On 10/18/2024 6:59 PM, Alan Snyder wrote: > I have a suggestion that might be helpful to me and others in the same > boat. Are there language features that do not impact the byte code and > do not require runtime support? If so, would it be possible to support > those features (using a compiler flag) when targeting older releases > like JDK 8? The JDK is all-in on tip & tail, so backporting new language features to old JDKs isn't going to happen. It's not just a matter of patching javac in JDK 8uXX: it's also the cost of revising the JLS, the JCK, documentation, etc, from the Java 8 release. In addition, many recent language features need library and/or VM support. For example, the translation of text blocks from source code to bytecode is specified in terms of new methods in java.lang.String (see JLS 3.10.6), while the translation of patterns involves a new class file attribute and new methods in java.lang.invoke (search for "carrier runtime" in https://mail.openjdk.org/pipermail/amber-spec-experts/2023-March/003766.html). Now the cost of backporting spreads to Hotspot, the JVMS, and the javadoc. What if a new feature's supporting API in javadoc uses code snippets (JEP 413) or Markdown comments (JEP 467) that aren't support by javadoc from JDK 8? Even when a language feature appears truly small and standalone, that's often just an artifact of how we're choosing to split up a larger feature for faster delivery in the tip train. You don't have to wait years for a big-bang release to get pattern matching because we've been delivering useful parts of the pattern story in every release. This means that most pattern matching JEPs, in addition to specifying their advertised feature, make deep cuts in the JLS and javac to prepare for future pattern matching JEPs, so it's not possible to pick and choose pattern features -- they all build on each other. Alex > Features that might have this property that I would find useful include > > * flexible constructor bodies > * local variable type inference > * string templates > * text blocks > * unnamed variables > * pattern matching for instanceof > > Something that might be useful in the future is support for multi- > release class files. That might allow some language features that impact > byte code to be supported on older JDKs. I?m thinking specifically of > value types. If value types could have run as ordinary classes in older > JDKs that would be Nirvana. From karsten.silz at gmail.com Mon Oct 21 19:02:23 2024 From: karsten.silz at gmail.com (Karsten Silz) Date: Mon, 21 Oct 2024 21:02:23 +0200 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development Message-ID: Hi! I'm writing an InfoQ news item about this JEP and contacted some folks for feedback. One person viewed the JEP more as recommendations than a strictly defined process and told me that, based on my explanation, Spring Boot may not fully do "Tip & Tail". Another person wasn't sure whether "Tip & Tail" required tip releases to pick the latest JDK as their baseline. Please tell me whether my interpretation of "Tip & Tail" and how Spring Boot fits is correct. And do the authors see the JEP as a strictly defined process or as recommendations? Thank you! I depicted some Spring Boot releases as the JEP does. It's too wide for text in an email, so I attached the picture. I uploaded it, too: https://app.screencast.com/p1YIaYwkSBuft ? REQUIRED 1. New functionality only appears on the one tip release train - YES: Only 3.2, 3.3, and 3.4 add new features every six months... - ?though unsupported releases (typically three milestone builds plus a release candidate, shown above) add nearly all those features 2. "From time to time", tip releases start a tail train - YES: every tip release creates a tail train (tails 3-5 in the picture) 3. "backport as little as possible": Tail trains only get "critical bug fixes and security patches", though "there may be exceptions" - YES: Tail releases only get bug fixes, documentation updates, and dependency updates... - ?though tail releases now add two Java versions to an enum during their one-year existence, which is classified as a new feature (e.g., 3.2.4: https://github.com/spring-projects/spring-boot/releases/tag/v3.2.4 and 3.2.9: https://github.com/spring-projects/spring-boot/releases/tag/v3.2.9) 4. Developers "continue update [tail train] even after new tip releases are made" - YES: Tail train for version X is updated for one year - until tip release X+2 appears (3.0 until 3.2, 3.1 until 3.3, and 3.2 until 3.4 in the picture above)? - ?except for the last tail release in a generation, which is maintained for 1.5 years (see the 2.7.x tail train here, not pictured above: https://spring.io/projects/spring-boot#support) 5. Developers "ensure that tail releases depend on the tail releases of other libraries, where available" - YES: Spring Boo team tries to avoid dependency updates and picks tail releases where possible 6. There can be multiple tail trains - YES: There are usually two at any time I think Spring Boot does "Tip & Tail", as described by the JEP, as it follows all required procedures. RECOMMENDED 7. "In the tip train, baseline each tip release on the JDK version that best supports the library's new features and enhancements." - NO: 3.2 supported Java 21 via a multi-release JAR, but the baseline was still 17 (https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes#support-for-virtual-threads) 8. "In a tail train, keep the JDK baseline as constant as possible over the life of the train." - YES: The JDK baseline only changes with a new Spring Framework Generation every few years 9. "It is not necessary to develop tip releases in lock step with the JDK's six-month tip releases." - YES: Tip releases now appear two months after a new Java release and support features of that release 10. "It is typical to bump the JDK baseline of the tip train when the library needs new JDK features." - NO: Baseline only changes with a new Spring Framework generation 11. "It is wise to baseline tail trains on JDK versions for which long-term support (LTS) offerings are available from reputable vendors." - YES: All 3.x releases are based on Java 17 NO OPINION 12. "when or why tail trains are created, nor when or why they are discontinued" - Every tip release creates a tail train that lives for 12 months ? or 18 months if it's the last one in a generation 13. Release cycles: time-boxed vs. driven by features or bug fixes - Time-boxed except for out-of-band security fixes, such as 2.6.6 (https://github.com/spring-projects/spring-boot/releases/tag/v2.6.6) for CVE-2022-22965 (https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement) 14. Library metadata, such as versioning number scheme - The versioning scheme is MAJOR.MINOR.PATCH[-MODIFIER] (https://spring.io/blog/2020/04/30/updates-to-spring-versions#project-module-version-changes) Regards, Karsten Silz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spring Boot Tip and Tail.png Type: image/png Size: 55138 bytes Desc: not available URL: From alex.buckley at oracle.com Mon Oct 21 20:29:59 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 21 Oct 2024 13:29:59 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: <212e1cc4-544a-4166-891b-e88b30ea79b9@oracle.com> On 10/21/2024 12:02 PM, Karsten Silz wrote: > Another person wasn't sure whether "Tip & Tail" required tip > releases to pick the latest JDK as their baseline. T&T does not require the tip train of a library to be baselined on the tip JDK. After all, the tip JDK changes every six months, and we're clear in JEP 14 that we're not asking libraries to adopt a six-month release cadence even for their tips. ("It is not necessary to develop tip releases in lock step with the JDK's six-month tip releases.") That said, the tip JDK has more bug fixes, performance enhancements, and security patches than any tail JDK, so testing the library tip on the JDK tip is smart. The library's most enthusiastic users will try to run its tip on JDK 24 as soon as 24 is released anyway. If a library is baselining its tip train on JDK LTS releases, then early testing on tip JDKs will make it easier to move the baseline up to the next LTS. > I think Spring Boot *does* "Tip & Tail", as described ?by the JEP, as it > follows all required procedures. I agree. > *RECOMMENDED* > > 7. "In the tip train, baseline each tip release on the JDK version that > best supports the library's new features and enhancements." > ? - NO: 3.2 supported?Java 21?via a multi-release JAR, but the baseline > was still 17 (https://github.com/spring-projects/spring-boot/wiki/ > Spring-Boot-3.2-Release-Notes#support-for-virtual-threads github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release- > Notes#support-for-virtual-threads>) IIRC Sprint Boot 3.2 was developed in roughly the same period as the JDK 18-19-20-21 cycle, so it makes sense to have chosen JDK 17 as the baseline at the start of that period. There were many new features in 3.2 that were happy with JDK 17, so I'd put #7 in the YES column. Using an MRJAR to achieve "baseline on 17 but support new 21 features" will IMO be more costly for a long-term tail than saying: 3.j is baselined on 17 and doesn't use virtual threads, while 3.k is baselined on 21 and does use virtual threads. > 10. "It is typical to bump the JDK baseline of the tip train when the > library needs new JDK features." > ? - NO: Baseline only changes with a new Spring Framework generation Which might well use (either directly or in its many dependencies) post-21 JDK features such as the Foreign Function & Memory API, the Class-File API, Markdown documentation comments, etc. Alex From anthony.scarpino at oracle.com Mon Oct 21 23:13:49 2024 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 21 Oct 2024 16:13:49 -0700 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: Vote: Yes Tony On 10/18/24 3:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two > years ago. Many of you will be familiar with his work on Stream Gatherers, > currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. > Viktor has ~40 contributions so far [2][3], mostly in the streams and > j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From tobias.hartmann at oracle.com Tue Oct 22 06:39:43 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Oct 2024 08:39:43 +0200 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <5a108510-a3df-4cda-8042-e34492fbe10d@oracle.com> Vote: yes Best regards, Tobias On 10/18/24 12:40, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining Oracle two years ago. Many of you will be familiar with his work on Stream Gatherers, currently proposed to move to a permanent feature in JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote From mark.reinhold at oracle.com Tue Oct 22 13:48:07 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 22 Oct 2024 13:48:07 +0000 Subject: JEP proposed to target JDK 24: 490: ZGC: Remove the Non-Generational Mode Message-ID: <20241022134734.CDEF477EF8A@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 490: ZGC: Remove the Non-Generational Mode https://openjdk.org/jeps/490 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 16:00 UTC on Tuesday, 29 October, 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 24. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From Tom.Mooney at bjss.com Tue Oct 22 15:12:31 2024 From: Tom.Mooney at bjss.com (Tom Mooney) Date: Tue, 22 Oct 2024 15:12:31 +0000 Subject: Onboarding instructions for new contributors Message-ID: Hi My name is Tom Mooney and I'm looking to start committing to the OpenJDK project specifically the JDK. Can I get some onboarding pointers etc and an overview of what I'd need to do to do this please? I've never contributed to this project before but I've got 10+ years experience with Java and would love to be able to contribute and give back to the project that's given me so much . + its just so interesting and I'd give such enjoyment of this if I can get some traction. Ta Tom The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Tue Oct 22 15:37:21 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 22 Oct 2024 15:37:21 +0000 Subject: New candidate JEP: 494: Module Import Declarations (Second Preview) Message-ID: <20241022153719.21BC277EFDA@eggemoggin.niobe.net> https://openjdk.org/jeps/494 Summary: Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. This is a preview language feature. - Mark From mark.reinhold at oracle.com Tue Oct 22 15:37:24 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 22 Oct 2024 15:37:24 +0000 Subject: New candidate JEP: 495: Simple Source Files and Instance Main Methods (Fourth Preview) Message-ID: <20241022153723.5B59777EFDC@eggemoggin.niobe.net> https://openjdk.org/jeps/495 Summary: Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This is a preview language feature. - Mark From chen.l.liang at oracle.com Tue Oct 22 15:39:32 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 22 Oct 2024 15:39:32 +0000 Subject: Onboarding instructions for new contributors In-Reply-To: References: Message-ID: Hello Tom, For a starting point, please check https://openjdk.org/guide and first try to successfully build the JDK and set up an IDE project. (The docs directory within the root JDK project is a good resource) For picking up contributions, I recommend checking the JBS bug search at https://bugs.openjdk.org/browse/JDK-8338625?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC You should use the "Component" and "Subcomponent" to find the area you wish to work on: for example, Java's core libraries like java.util is "core-libs" component, and has subcomponents including "java.lang.invoke" "java.util:collections". You can also navigate to the code you wish to work on, open git blame, and look at the component and subcomponent of the issue related to that change, in case it is confusing to you. Use "Resolution: Unresolved" filters to find actually workable bugs instead of closed ones. Note that when picking up issues, prefer bugs over enhancements and prefer unassigned ones (especially ones without fix versions field set). Enhancements are not always a good idea, assigned bugs already have people working on, so those contributions are less likely to be accepted. Best regards, Chen Liang ________________________________ From: jdk-dev on behalf of Tom Mooney Sent: Tuesday, October 22, 2024 10:12 AM To: jdk-dev at openjdk.org Subject: Onboarding instructions for new contributors Hi My name is Tom Mooney and I'm looking to start committing to the OpenJDK project specifically the JDK. Can I get some onboarding pointers etc and an overview of what I'd need to do to do this please? I've never contributed to this project before but I've got 10+ years experience with Java and would love to be able to contribute and give back to the project that's given me so much . + its just so interesting and I'd give such enjoyment of this if I can get some traction. Ta Tom The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Tue Oct 22 16:32:43 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 22 Oct 2024 09:32:43 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> > On Oct 21, 2024, at 10:15?AM, Alex Buckley wrote: > > The JDK is all-in on tip & tail, so backporting new language features to old JDKs isn't going to happen. It's not just a matter of patching javac in JDK 8uXX: it's also the cost of revising the JLS, the JCK, documentation, etc, from the Java 8 release. Perhaps there is a misunderstanding. My suggestion does not involve changing old JDKs or compilers. The suggestion is to enhance javac with a new command line flag. This flag is similar to the ?enable-preview flag in that it allows some language features to be used that otherwise would be rejected (in this case, because they are not supported by the target JDK release). It is unlike ?enable-preview in that it does not have any corresponding JVM support (by definition). Any language extension that could be implemented on the target JDK using a preprocessor is a candidate for support by this javac feature. (In theory, javac could implement this feature using a preprocessor, but a direct implementation would be simpler.) I would think that new syntax for string literals would fall in this category as long as the result is a string literal that is supported by the target JDK. The fact that javac uses new APIs to implement the new syntax is irrelevant. Some language extensions may involve removing restrictions performed by older compilers. Such extensions probably cannot be implemented using a preprocessor. However, if no JVM support is required, then these extensions are also candidates for a direct implementation by javac. Flexible constructor bodies might fit in this category. Even a restricted version of this feature would be useful. You make a good point that javadoc would need to support the same flag, just as it currently supports ?enable-preview. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Oct 22 16:51:18 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2024 09:51:18 -0700 Subject: [External] : Re: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> Message-ID: On 10/22/2024 9:32 AM, Alan Snyder wrote: > The suggestion is to enhance javac with a new command line flag. This > flag is similar to the ?enable-preview flag in that it allows some > language features to be used that otherwise would be rejected (in this > case, because they are not supported by the target JDK release). javac accepts source code written in a version of the Java language defined by a specific edition of the JLS. You are suggesting that javac in JDK 24 has a flag to accept source code which uses the Java 8 language + some but not all of the language features from Java 24. There is no edition of the JLS which specifies that hybrid language. Alex From javalists at cbfiddle.com Tue Oct 22 16:59:34 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 22 Oct 2024 09:59:34 -0700 Subject: [External] : Re: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> Message-ID: <585D957A-DC0A-44B4-B428-271B605354E4@cbfiddle.com> > On Oct 22, 2024, at 9:51?AM, Alex Buckley wrote: > > javac accepts source code written in a version of the Java language defined by a specific edition of the JLS. You are suggesting that javac in JDK 24 has a flag to accept source code which uses the Java 8 language + some but not all of the language features from Java 24. There is no edition of the JLS which specifies that hybrid language. > True, but fixable. The extra features could be incorporated by reference, as preview features are. Alan From alex.buckley at oracle.com Tue Oct 22 17:42:08 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2024 10:42:08 -0700 Subject: [External] : Re: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <585D957A-DC0A-44B4-B428-271B605354E4@cbfiddle.com> References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> <585D957A-DC0A-44B4-B428-271B605354E4@cbfiddle.com> Message-ID: <4efd534d-c631-456b-8455-7db237b9ae86@oracle.com> On 10/22/2024 9:59 AM, Alan Snyder wrote: >> On Oct 22, 2024, at 9:51?AM, Alex Buckley >> wrote: >> >> javac accepts source code written in a version of the Java >> language defined by a specific edition of the JLS. You are >> suggesting that javac in JDK 24 has a flag to accept source code >> which uses the Java 8 language + some but not all of the language >> features from Java 24. There is no edition of the JLS which >> specifies that hybrid language. > > True, but fixable. The extra features could be incorporated by > reference, as preview features are. Everything is fixable given enough time and energy. We prefer to focus our time and energy on designing and delivering new versions of the Java language, rather than backporting new features to old versions of the language (`javac --accept-java-8-plus-flexible-ctor-bodies`). As JEP 14 says, "Backporting as little as possible is the discipline that distinguishes the tip & tail model of library development from traditional multi-train models." Alex From jesper.wilhelmsson at oracle.com Tue Oct 22 18:17:43 2024 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Oct 2024 18:17:43 +0000 Subject: Onboarding instructions for new contributors In-Reply-To: References: Message-ID: <8E80B0CC-978C-412E-9E51-D07E695E9E21@oracle.com> Welcome Tom! Please start by reading the introduction and the "Contributing to an OpenJDK Project" sections of the OpenJDK Developers' Guide (https://openjdk.org/guide/). These contain important information on what to do and what not to do when proposing changes in the JDK. There is so much more to it than just finding an issue and fixing it. /Jesper On 22 Oct 2024, at 17:39, Chen Liang wrote: Hello Tom, For a starting point, please check https://openjdk.org/guide and first try to successfully build the JDK and set up an IDE project. (The docs directory within the root JDK project is a good resource) For picking up contributions, I recommend checking the JBS bug search at https://bugs.openjdk.org/browse/JDK-8338625?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC You should use the "Component" and "Subcomponent" to find the area you wish to work on: for example, Java's core libraries like java.util is "core-libs" component, and has subcomponents including "java.lang.invoke" "java.util:collections". You can also navigate to the code you wish to work on, open git blame, and look at the component and subcomponent of the issue related to that change, in case it is confusing to you. Use "Resolution: Unresolved" filters to find actually workable bugs instead of closed ones. Note that when picking up issues, prefer bugs over enhancements and prefer unassigned ones (especially ones without fix versions field set). Enhancements are not always a good idea, assigned bugs already have people working on, so those contributions are less likely to be accepted. Best regards, Chen Liang ________________________________ From: jdk-dev on behalf of Tom Mooney Sent: Tuesday, October 22, 2024 10:12 AM To: jdk-dev at openjdk.org Subject: Onboarding instructions for new contributors Hi My name is Tom Mooney and I'm looking to start committing to the OpenJDK project specifically the JDK. Can I get some onboarding pointers etc and an overview of what I'd need to do to do this please? I've never contributed to this project before but I've got 10+ years experience with Java and would love to be able to contribute and give back to the project that's given me so much . + its just so interesting and I'd give such enjoyment of this if I can get some traction. Ta Tom The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten.silz at gmail.com Tue Oct 22 18:42:08 2024 From: karsten.silz at gmail.com (Karsten Silz) Date: Tue, 22 Oct 2024 20:42:08 +0200 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development Message-ID: Hi! Non-LTS Java versions get patch releases, too, such as 19..0.1 or 22.0.2 ? see https://www.java.com/releases/matrix. These are tip releases. Correct? Regards, Karsten Silz -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Oct 22 19:30:15 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2024 12:30:15 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: On 10/22/2024 11:42 AM, Karsten Silz wrote: > Non-LTS Java versions get patch releases, too, such as 19.0.1 or 22.0.2 > ? see https://www.java.com/releases/matrix releases/matrix>. These are tip releases. Every tip release of the JDK (e.g., "19") has a tail train forked from it. Here's the wiki for JDK 19's tail train, which consisted of two tail releases: https://wiki.openjdk.org/display/JDKUpdates/JDK+19u Some tip releases of the JDK have a tail train which consists of many tail releases. Here's the wiki for JDK 17's tail train: https://wiki.openjdk.org/display/JDKUpdates/JDK+17u There's lots of info about tail trains in the JDK Updates Project: https://openjdk.org/projects/jdk-updates/ Alex From ron.pressler at oracle.com Tue Oct 22 20:44:01 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 22 Oct 2024 20:44:01 +0000 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: <89FEFCB6-94A8-4FC5-AB8B-A8FAF8EF709E@oracle.com> > On 19 Oct 2024, at 02:59, Alan Snyder wrote: > > I appreciate the emphasis in this JEP on minimizing the burden of backporting changes. > > However, for me, maintaining multiple releases is also burdensome. For that reason, I target library development to JDK 8 and probably will continue to do so as long as JDK 8 is relevant. I understand that there are disadvantages to not being able to use newer language features, but so far, the disadvantages of maintaining multiple releases outweigh the advantages of the new language features. ?Maintaining multiple releases? in T&T effectively means backporting security patches and fixes to the most critical bugs, and unless your library keeps having many of those discovered in *old code*, there isn?t much maintaining to do. But say that you do have lots of security problems or lots of criticial bugs and it is a burden to backport solutions to so many problems. There are still two things to consider: 1. T&T delivers to your users more of what they want. If your library has lots of major bugs, it stands to reason that new features would only add more. ?Legacy" users don?t want these new bugs (and potentially other regressions/breaking changes that come with new features). 2. Even if new language features in your API aren?t a win for your users, maintaining a single release train can mean more work (given that the tail releases don?t require much maintenance). For example, if a library uses Unsafe on 8, it will simply stop working soon on newer JDK. Picking dynamically between Unsafe and VarHandles/FFM is more work than letting the Unsafe version be, only backporting security patches. The same happens if you want to offer better performance on new JDKs by using new features internally. Anyone is, of course, free to use OSFA, but claiming that it?s less work and/or delivers more value is something I would very much doubt unless the library is swarming with yet-to-be-discovered major bugs or security vulnerabilities. > > I have a suggestion that might be helpful to me and others in the same boat. Are there language features that do not impact the byte code and do not require runtime support? If so, would it be possible to support those features (using a compiler flag) when targeting older releases like JDK 8? It is probably true that if we also picked the path that requires more effort and more likely to destabalise those who want stability it could mean that those who choose to do things the hard way may need to work a little less hard, but why do that if in most situations (maybe not all) the easy way is available? How big is that boat of maintainers of libraries with so many critical problems that backporting them becomes such a big burden that it offsets both the extra effort of dynamic feature detection and the risk of destabalising legacy users? ? Ron From brian.goetz at oracle.com Tue Oct 22 21:32:06 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 22 Oct 2024 17:32:06 -0400 Subject: CFV: New JDK Reviewer: Viktor Klang In-Reply-To: References: Message-ID: <67e8a039-f594-467d-9a0d-015d40ae37f9@oracle.com> Vote: Yes On 10/18/2024 6:40 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to jdk Reviewer. > > Viktor has been working in the core libraries area since joining > Oracle two years ago. Many of you will be familiar with his work on > Stream Gatherers, currently proposed to move to a permanent feature in > JDK 24 with JEP 485 [1]. Viktor has ~40 contributions so far [2][3], > mostly in the streams and j.u.concurrent areas. > > Votes are due by 23.59 UTC on Friday, 1 November. > > Only current jdk Reviewers [4] 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 [5]. > > -Alan > > [1] https://openjdk.org/jeps/485 > [2] > https://github.com/openjdk/jdk/commits/master/?author=vklang at openjdk.org > [3] > https://github.com/openjdk/jdk/commits/master/?author=viktor.klang at oracle.com > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#reviewer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten.silz at gmail.com Tue Oct 22 22:17:21 2024 From: karsten.silz at gmail.com (Karsten Silz) Date: Wed, 23 Oct 2024 00:17:21 +0200 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: Message-ID: <053E0DD7-04A7-4BC6-85EB-7CCB34CCF3B1@gmail.com> > On 22 Oct 2024, at 21:30, Alex Buckley wrote: > > On 10/22/2024 11:42 AM, Karsten Silz wrote: >> Non-LTS Java versions get patch releases, too, such as 19.0.1 or 22.0.2 ? see https://www.java.com/releases/matrix . These are tip releases. > > Every tip release of the JDK (e.g., "19") has a tail train forked from it. Thank you for the swift reply! I'm afraid I find the JEP confusing about tail trains now. First, the JEP says this: "A selection of older JDK versions -- 8, 11, 17, and 21 -- are maintained in tail trains." I interpreted that as "Only these older JDK versions have tail trains." I think the JEP could have mentioned that all OpenJDK versions have had tail trains since Java 13. Especially since it mentions OpenJDK and Spring Boot as examples of "Tip & Tail" but depicts neither of those. Second, the JEP also says this: "From time to time, library developers designate a tip release as the start of a new tail train that they will continue update even after new tip releases are made. " To me, the "From time to time" suggests again that not every tip release spawns a tail release. So, a sentence like this would be helpful for me in the JEP: "Although not all tip releases have to create a tail release, they do for OpenJDK and Spring Boot today." And then there's this: "a new tail train that they will continue update even after new tip releases are made". This was in the "Tip & Tail" description, so I read it as a definition: "All tail trains must get updates after the next tip release". Non-LTS OpenJDK tail trains don't today. So, a tail train getting updates after the next tip release is a recommendation, not a requirement? Regards, Karsten Silz -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Oct 22 23:15:16 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2024 16:15:16 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <053E0DD7-04A7-4BC6-85EB-7CCB34CCF3B1@gmail.com> References: <053E0DD7-04A7-4BC6-85EB-7CCB34CCF3B1@gmail.com> Message-ID: <3bf749d6-72bb-4c01-b3d3-f2714a7c7dbf@oracle.com> On 10/22/2024 3:17 PM, Karsten Silz wrote: > First, the JEP says this: "A selection of older JDK versions -- 8, 11, > 17, and 21 -- are maintained in tail trains." I interpreted that as > "Only these older JDK versions have tail trains." Fair comment. I have updated that paragraph in "Success with tip & tail" to clarify that all JDK versions have tail trains, some maintained longer than others. > Second, the JEP also says this: "From time to time, library developers > designate a tip release as the start of a new tail train that they will > continue update even after new tip releases are made.?" To me, the "From > time to time" suggests again that not every tip release spawns a tail > release. That text is from the highest level part of the Description. It is necessarily broad. I don't see it as incompatible with the JDK's "implementation" of T&T that forks every tip release into a tail train. > And then there's this: "a new tail train that they will continue > [to] update even after new tip releases are made". This was in the > "Tip & Tail" description, so I read it as a definition: "All tail > trains must get updates after the next tip release". Non-LTS OpenJDK > tail trains don't today. So, a tail train getting updates after the > next tip release is a recommendation, not a requirement? Again, that part of the Description is high level and needs to be applicable to all libraries. The most interesting scenario for users is where a tail train makes tail releases for many years, long after the next tip release has shipped, so that's how we start describing the T&T model. I don't want to weaken the text to accommodate the JDK's T&T implementation -- "a new tail train that they MAY continue to update even after new tip releases are made" -- because this phrasing, while technically correct, will send readers off-track. Alex From maurizio.cimadamore at oracle.com Wed Oct 23 11:12:25 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 23 Oct 2024 12:12:25 +0100 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> Message-ID: On 22/10/2024 17:32, Alan Snyder wrote: > Some language extensions may involve removing restrictions performed > by older compilers. Such extensions probably cannot be implemented > using a preprocessor. However, if no JVM support is required, then > these extensions are also candidates for a direct implementation by > javac. Flexible constructor bodies might fit in this category. Even a > restricted version of this feature would be useful. I find the general idea of having magic switches to allow new features to target older JDKs rather unworkable in practice. Most features we do (sealed classes, records, pattern matching) do have rather deep ramifications, sometimes in terms of the Java SE API (e.g. patterns switches are translated with an indy targeting a bootstrap method that is not available in older JDKs), sometimes in terms of the JVM itself (e.g. the JVM knows about sealed classes). So, if you start cherry picking language features, you quickly end up with a Frankenstein Java, which has some of the latest features, but not others. When we design a feature, we do not just design _that_ feature. A big part of designing a new feature (the biggest, often) is making sure that the feature work in harmony with other features that are part of that version of the language. An example of this is the strong synergy between record types, sealed interfaces and pattern matching which, together, give us algebraic data types (or, how we came to call it the "data-oriented programming" model [1]). To put it bluntly, what you are asking for amounts at throwing all this careful design work down the drain, and work with _some_ unspecified version of the language where things *might* work (but also might break in surprising ways). Logistically, this is also a big nightmare, as the JDK will have different implementations for the same feature - which makes code harder to maintain and test, and much more difficult to evolve. This is certain to translate in *less* new features being added to Java, as a lot of our budget will be spent in fixing arcane issues when a feature in Java N doesn't work as expected when running on Java N - M. But, since you specifically refer to "Flexible constructor bodies", as one of those seemingly low-hanging fruits that javac should "just" translate away and make available for older runtimes, please take a look at the size and complexity of some of the patches involved to support that feature [2, 3, 4]. Can we "just" enable flexible constructor bodies for older targets? In theory, yes. In practice, the chances that such changes can be enabled for any older target and not disrupt anything else are rather slim -- in fact, the work in (4) was to fix an obscure regression with serializable lambdas that was only possible to spot due to extensive testing. In my experience, there's no such thing as a "simple" language feature -- even a feature might be *conceptually* simple, the devil is always in the details, and it is those details that, in the end, make your suggestion unworkable in most cases I can think of. [1] - https://www.infoq.com/articles/data-oriented-programming-java/ [2] - https://github.com/openjdk/jdk/pull/13656 [3] - https://git.openjdk.org/jdk/pull/19836 [4] - https://git.openjdk.org/jdk/pull/20349 From mark.reinhold at oracle.com Wed Oct 23 13:43:32 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 23 Oct 2024 13:43:32 +0000 Subject: JEP proposed to target JDK 24: 404: Generational Shenandoah (Experimental) Message-ID: <20241023134330.AF36377F1E8@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 404: Generational Shenandoah (Experimental) https://openjdk.org/jeps/404 Summary: Enhance the Shenandoah garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization. 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 16:00 UTC on Wednesday, 30 October, 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 24. - 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 Wed Oct 23 13:57:24 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 23 Oct 2024 13:57:24 +0000 Subject: JEP proposed to target JDK 24: 487: Scoped Values (Fourth Preview) Message-ID: <20241023135723.71EF577F1F0@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 487: Scoped Values (Fourth Preview) https://openjdk.org/jeps/487 Summary: Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). 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 16:00 UTC on Wednesday, 30 October, 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 24. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From javalists at cbfiddle.com Wed Oct 23 14:52:56 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 23 Oct 2024 07:52:56 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <89FEFCB6-94A8-4FC5-AB8B-A8FAF8EF709E@oracle.com> References: <89FEFCB6-94A8-4FC5-AB8B-A8FAF8EF709E@oracle.com> Message-ID: <768E91E6-0D63-4B40-87FF-F4D2B9E22350@cbfiddle.com> I don?t agree with your characterization of the situation. You are probably in a better position than I am to know why people still use JDK 8, but my assumption is many or most of them stick with JDK 8 because they use code that has never been ported to JDK 9 or later and it would be risky and/or expensive to port it. That does not imply that they don?t want bug fixes and new features from libraries that are being actively maintained, in which case forking the library and only backporting critical/security problems would not be well received. My libraries run on JDK 8 and all later JDKs. I use reflection to cover the API differences between JDK 8 and JDK 9+. Fortunately, or perhaps not surprisingly, I have not yet run into a situation where I need to change my code to run on later JDKs (except for that command line argument that will be needed for my libraries to use JNI, and you already know what I think about that.) If at some point using features of more recent JDKs internally would make a big performance difference, I still have the option to extend my reflection solution. If the changes impact the API then I would have a big decision to make. Alan > On Oct 22, 2024, at 1:44?PM, Ron Pressler wrote: > > > >> On 19 Oct 2024, at 02:59, Alan Snyder wrote: >> >> I appreciate the emphasis in this JEP on minimizing the burden of backporting changes. >> >> However, for me, maintaining multiple releases is also burdensome. For that reason, I target library development to JDK 8 and probably will continue to do so as long as JDK 8 is relevant. I understand that there are disadvantages to not being able to use newer language features, but so far, the disadvantages of maintaining multiple releases outweigh the advantages of the new language features. > > ?Maintaining multiple releases? in T&T effectively means backporting security patches and fixes to the most critical bugs, and unless your library keeps having many of those discovered in *old code*, there isn?t much maintaining to do. > > But say that you do have lots of security problems or lots of criticial bugs and it is a burden to backport solutions to so many problems. There are still two things to consider: > > 1. T&T delivers to your users more of what they want. If your library has lots of major bugs, it stands to reason that new features would only add more. ?Legacy" users don?t want these new bugs (and potentially other regressions/breaking changes that come with new features). > > 2. Even if new language features in your API aren?t a win for your users, maintaining a single release train can mean more work (given that the tail releases don?t require much maintenance). For example, if a library uses Unsafe on 8, it will simply stop working soon on newer JDK. Picking dynamically between Unsafe and VarHandles/FFM is more work than letting the Unsafe version be, only backporting security patches. The same happens if you want to offer better performance on new JDKs by using new features internally. > > Anyone is, of course, free to use OSFA, but claiming that it?s less work and/or delivers more value is something I would very much doubt unless the library is swarming with yet-to-be-discovered major bugs or security vulnerabilities. > >> >> I have a suggestion that might be helpful to me and others in the same boat. Are there language features that do not impact the byte code and do not require runtime support? If so, would it be possible to support those features (using a compiler flag) when targeting older releases like JDK 8? > > It is probably true that if we also picked the path that requires more effort and more likely to destabalise those who want stability it could mean that those who choose to do things the hard way may need to work a little less hard, but why do that if in most situations (maybe not all) the easy way is available? How big is that boat of maintainers of libraries with so many critical problems that backporting them becomes such a big burden that it offsets both the extra effort of dynamic feature detection and the risk of destabalising legacy users? > > ? Ron From javalists at cbfiddle.com Wed Oct 23 14:56:17 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 23 Oct 2024 07:56:17 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> Message-ID: <7126CE6A-195D-44D5-9AB1-930E4B1CAEF0@cbfiddle.com> It seems that you have set up a straw man [1] here and used it to predict doom. I did not suggest targeting features that affect the Java data model like sealed classes, records, and pattern matching to older JDKs for exactly the reasons you mention. My suggestion was intended to apply to convenience features like new syntax for string literals and improved type inference, which can be defined in terms of source to source translation. Flexible constructor bodies is a more challenging topic, and I don?t claim to know what the implications are. The motivation would be to untangle the complexity in my current code to work around the current strict requirements. The code examples you give are all changes to the compiler (and test programs), which don?t tell me anything about the impact on the runtime environment. Performing the required extensive testing on Frankenstein Java might not be that hard, if the test programs do not use other recent language features or can be altered to avoid them. Alan [1] https://en.wikipedia.org/wiki/Straw_man > On Oct 23, 2024, at 4:12?AM, Maurizio Cimadamore wrote: > > > On 22/10/2024 17:32, Alan Snyder wrote: >> Some language extensions may involve removing restrictions performed by older compilers. Such extensions probably cannot be implemented using a preprocessor. However, if no JVM support is required, then these extensions are also candidates for a direct implementation by javac. Flexible constructor bodies might fit in this category. Even a restricted version of this feature would be useful. > > I find the general idea of having magic switches to allow new features to target older JDKs rather unworkable in practice. Most features we do (sealed classes, records, pattern matching) do have rather deep ramifications, sometimes in terms of the Java SE API (e.g. patterns switches are translated with an indy targeting a bootstrap method that is not available in older JDKs), sometimes in terms of the JVM itself (e.g. the JVM knows about sealed classes). > > So, if you start cherry picking language features, you quickly end up with a Frankenstein Java, which has some of the latest features, but not others. When we design a feature, we do not just design _that_ feature. A big part of designing a new feature (the biggest, often) is making sure that the feature work in harmony with other features that are part of that version of the language. An example of this is the strong synergy between record types, sealed interfaces and pattern matching which, together, give us algebraic data types (or, how we came to call it the "data-oriented programming" model [1]). > > To put it bluntly, what you are asking for amounts at throwing all this careful design work down the drain, and work with _some_ unspecified version of the language where things *might* work (but also might break in surprising ways). Logistically, this is also a big nightmare, as the JDK will have different implementations for the same feature - which makes code harder to maintain and test, and much more difficult to evolve. This is certain to translate in *less* new features being added to Java, as a lot of our budget will be spent in fixing arcane issues when a feature in Java N doesn't work as expected when running on Java N - M. > > But, since you specifically refer to "Flexible constructor bodies", as one of those seemingly low-hanging fruits that javac should "just" translate away and make available for older runtimes, please take a look at the size and complexity of some of the patches involved to support that feature [2, 3, 4]. Can we "just" enable flexible constructor bodies for older targets? In theory, yes. In practice, the chances that such changes can be enabled for any older target and not disrupt anything else are rather slim -- in fact, the work in (4) was to fix an obscure regression with serializable lambdas that was only possible to spot due to extensive testing. > > In my experience, there's no such thing as a "simple" language feature -- even a feature might be *conceptually* simple, the devil is always in the details, and it is those details that, in the end, make your suggestion unworkable in most cases I can think of. > > [1] - https://www.infoq.com/articles/data-oriented-programming-java/ > [2] - https://github.com/openjdk/jdk/pull/13656 > [3] - https://git.openjdk.org/jdk/pull/19836 > [4] - https://git.openjdk.org/jdk/pull/20349 > From maurizio.cimadamore at oracle.com Wed Oct 23 15:16:59 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 23 Oct 2024 16:16:59 +0100 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <7126CE6A-195D-44D5-9AB1-930E4B1CAEF0@cbfiddle.com> References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> <7126CE6A-195D-44D5-9AB1-930E4B1CAEF0@cbfiddle.com> Message-ID: <7232a49d-e922-4c6e-afdb-b2d4bd8e7cc4@oracle.com> On 23/10/2024 15:56, Alan Snyder wrote: > It seems that you have set up a straw man [1] here and used it to predict doom. Uhm not sure I did that :-) > > I did not suggest targeting features that affect the Java data model like sealed classes, records, and pattern matching to older JDKs for exactly the reasons you mention. > My suggestion was intended to apply to convenience features like new syntax for string literals and improved type inference, which can be defined in terms of source to source translation. So you agree with me that what you propose will amount to cherry pick features. And, since features are more often than not, inter-related, it is not clear to me how you draw that line. I mean, I see the line that you so badly want to draw - what I'm trying to say is: that line doesn't really exist (or is not nearly as widely applicable as you think it is). > > Flexible constructor bodies is a more challenging topic, and I don?t claim to know what the implications are. The motivation would be to untangle the complexity in my current code to work around the current strict requirements. The code examples you give are all changes to the compiler (and test programs), which don?t tell me anything about the impact on the runtime environment. Performing the required extensive testing on Frankenstein Java might not be that hard, if the test programs do not use other recent language features or can be altered to avoid them. Again, you are not really arguing against what I said - you are saying that it will be _somebody else's job_ to do the required amount of testing required to make sure that you can happily use flexible constructor bodies in Java 8. The key question is: whose job? If the job falls on the same group of developers who is also trying to move Java forward, don't you see an issue? In the end, like many other things, it's a matter of deciding how to allocate a (finite) amount of resources at our disposal to the things in our radar. Maurizio > > Alan > > [1] https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Straw_man__;!!ACWV5N9M2RV99hQ!IxQbll_o6FDxAoxj7eG3LtIdih93WMdfB8o3Jm_9idBJqOGqF6kTF2KAOggyTTeMg6pLBEmmUc7ioOGeLrXVUPyQCskF$ > > >> On Oct 23, 2024, at 4:12?AM, Maurizio Cimadamore wrote: >> >> >> On 22/10/2024 17:32, Alan Snyder wrote: >>> Some language extensions may involve removing restrictions performed by older compilers. Such extensions probably cannot be implemented using a preprocessor. However, if no JVM support is required, then these extensions are also candidates for a direct implementation by javac. Flexible constructor bodies might fit in this category. Even a restricted version of this feature would be useful. >> I find the general idea of having magic switches to allow new features to target older JDKs rather unworkable in practice. Most features we do (sealed classes, records, pattern matching) do have rather deep ramifications, sometimes in terms of the Java SE API (e.g. patterns switches are translated with an indy targeting a bootstrap method that is not available in older JDKs), sometimes in terms of the JVM itself (e.g. the JVM knows about sealed classes). >> >> So, if you start cherry picking language features, you quickly end up with a Frankenstein Java, which has some of the latest features, but not others. When we design a feature, we do not just design _that_ feature. A big part of designing a new feature (the biggest, often) is making sure that the feature work in harmony with other features that are part of that version of the language. An example of this is the strong synergy between record types, sealed interfaces and pattern matching which, together, give us algebraic data types (or, how we came to call it the "data-oriented programming" model [1]). >> >> To put it bluntly, what you are asking for amounts at throwing all this careful design work down the drain, and work with _some_ unspecified version of the language where things *might* work (but also might break in surprising ways). Logistically, this is also a big nightmare, as the JDK will have different implementations for the same feature - which makes code harder to maintain and test, and much more difficult to evolve. This is certain to translate in *less* new features being added to Java, as a lot of our budget will be spent in fixing arcane issues when a feature in Java N doesn't work as expected when running on Java N - M. >> >> But, since you specifically refer to "Flexible constructor bodies", as one of those seemingly low-hanging fruits that javac should "just" translate away and make available for older runtimes, please take a look at the size and complexity of some of the patches involved to support that feature [2, 3, 4]. Can we "just" enable flexible constructor bodies for older targets? In theory, yes. In practice, the chances that such changes can be enabled for any older target and not disrupt anything else are rather slim -- in fact, the work in (4) was to fix an obscure regression with serializable lambdas that was only possible to spot due to extensive testing. >> >> In my experience, there's no such thing as a "simple" language feature -- even a feature might be *conceptually* simple, the devil is always in the details, and it is those details that, in the end, make your suggestion unworkable in most cases I can think of. >> >> [1] - https://urldefense.com/v3/__https://www.infoq.com/articles/data-oriented-programming-java/__;!!ACWV5N9M2RV99hQ!IxQbll_o6FDxAoxj7eG3LtIdih93WMdfB8o3Jm_9idBJqOGqF6kTF2KAOggyTTeMg6pLBEmmUc7ioOGeLrXVUN5UCHON$ >> [2] - https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13656__;!!ACWV5N9M2RV99hQ!IxQbll_o6FDxAoxj7eG3LtIdih93WMdfB8o3Jm_9idBJqOGqF6kTF2KAOggyTTeMg6pLBEmmUc7ioOGeLrXVUJLRkAxp$ >> [3] - https://git.openjdk.org/jdk/pull/19836 >> [4] - https://git.openjdk.org/jdk/pull/20349 >> From sandhya.viswanathan at intel.com Wed Oct 23 17:34:17 2024 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 23 Oct 2024 17:34:17 +0000 Subject: Result: New JDK Committer: Smita Kamath Message-ID: Voting for Smita Kamath [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best Regards, Sandhya Viswanathan [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009462.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten.silz at gmail.com Wed Oct 23 19:00:36 2024 From: karsten.silz at gmail.com (Karsten Silz) Date: Wed, 23 Oct 2024 21:00:36 +0200 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <3bf749d6-72bb-4c01-b3d3-f2714a7c7dbf@oracle.com> References: <053E0DD7-04A7-4BC6-85EB-7CCB34CCF3B1@gmail.com> <3bf749d6-72bb-4c01-b3d3-f2714a7c7dbf@oracle.com> Message-ID: <9EFDD715-79A0-477E-AF2F-F3E87087F6F8@gmail.com> >> On 23 Oct 2024, at 01:15, Alex Buckley > wrote: > > On 10/22/2024 3:17 PM, Karsten Silz wrote: >> And then there's this: "a new tail train that they will continue >> [to] update even after new tip releases are made". This was in the >> "Tip & Tail" description, so I read it as a definition: "All tail >> trains must get updates after the next tip release". Non-LTS OpenJDK >> tail trains don't today. So, a tail train getting updates after the >> next tip release is a recommendation, not a requirement? > Again, that part of the Description is high level and needs to be applicable to all libraries. The most interesting scenario for users is where a tail train makes tail releases for many years, long after the next tip release has shipped, so that's how we start describing the T&T model. > > I don't want to weaken the text to accommodate the JDK's T&T implementation -- "a new tail train that they MAY continue to update even after new tip releases are made" -- because this phrasing, while technically correct, will send readers off-track. Thank you, Alex, for taking the time to answer my questions! Here are two observations. There's no call to action here, and there's no need for you to reply. First, I'm a JEP newbie. I thought JEPs were like standards, full of MUST and MUSTN'T, SHALL and SHAN'T. I didn't find many of these here. Instead, I found statements that were ambiguous to me. Like this one: "library developers designate a tip release as the start of a new tail train that they will continue to update even after new tip releases are made". I read that as "tail train MUST live beyond the next tip train". But it either isn't a MUST, or it's overruled by this sentence here: "Tip & tail does not specify when or why tail trains are created, nor when or why they are discontinued." As a result, I didn't know how I would move a library to the "Tip & Tail model" just by reading the JEP. Second, the JEP cites OpenJDK and Spring Boot as "Tip & Tail" examples. However, the differences between "Generic Tip & Tail", "OpenJDK Tip & Tail", and "Spring Boot Tip & Tail" weren't clear to me from reading the JEP. "OpenJDK Tip & Tail" and "Spring Boot Tip & Tail" also seem identical, except for a different tail train length. If folks just skim the JEP and look at OpenJDK and Spring Boot instead, they may think, "'Tip & Tail' means you have to release a new tip every six months." and turn away. I would have found a table comparing "Generic Tip & Tail", "Spring Boot Tip & Tail", and "Tip & Tail" for a feature-driven library useful. Though not in this JEP ? it's already quite long. :-) Regards, Karsten Silz -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Oct 23 23:48:54 2024 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 23 Oct 2024 16:48:54 -0700 Subject: New informational JEP: 14: The Tip & Tail Model of Library Development In-Reply-To: <7232a49d-e922-4c6e-afdb-b2d4bd8e7cc4@oracle.com> References: <5E21044A-95AB-43B0-B39A-9FE2B694725C@cbfiddle.com> <7126CE6A-195D-44D5-9AB1-930E4B1CAEF0@cbfiddle.com> <7232a49d-e922-4c6e-afdb-b2d4bd8e7cc4@oracle.com> Message-ID: <63b9d994-0f14-4247-aa20-fcca52ea00ef@oracle.com> On 10/23/2024 8:16 AM, Maurizio Cimadamore wrote: > > On 23/10/2024 15:56, Alan Snyder wrote: >> It seems that you have set up a straw man [1] here and used it to >> predict doom. > Uhm not sure I did that :-) >> >> I did not suggest targeting features that affect the Java data model >> like sealed classes, records, and pattern matching to older JDKs for >> exactly the reasons you mention. >> My suggestion was intended to apply to convenience features like new >> syntax for string literals and improved type inference, which can be >> defined in terms of source to source translation. > > So you agree with me that what you propose will amount to cherry pick > features. > > And, since features are more often than not, inter-related, it is not > clear to me how you draw that line. I mean, I see the line that you so > badly want to draw - what I'm trying to say is: that line doesn't > really exist (or is not nearly as widely applicable as you think it is). > >> >> Flexible constructor bodies is a more challenging topic, and I don?t >> claim to know what the implications are. The motivation would be to >> untangle the complexity in my current code to work around the current >> strict requirements. The code examples you give are all changes to >> the compiler (and test programs), which don?t tell me anything about >> the impact on the runtime environment. Performing the required >> extensive testing on Frankenstein Java might not be that hard, if the >> test programs do not use other recent language features or can be >> altered to avoid them. > > Again, you are not really arguing against what I said - you are saying > that it will be _somebody else's job_ to do the required amount of > testing required to make sure that you can happily use flexible > constructor bodies in Java 8. The key question is: whose job? If the > job falls on the same group of developers who is also trying to move > Java forward, don't you see an issue? In the end, like many other > things, it's a matter of deciding how to allocate a (finite) amount of > resources at our disposal to the things in our radar. To reiterate Maurizio's points, a task being technically feasible -- such as selective backporting of new language features to old releases -- is a necessary but not sufficient condition for it to be considered for the JDK. As always, there is a balance between stability and progress in maintaining the platform, and creating chimeric hybrids of language features grafted onto old releases doesn't have favorable cost vs benefit trade-offs. We want to use and do use new language features in implementing the JDK and its regression tests and it is an unreasonable constraint to limit the language features used in the JDK in 2024 to, say, the language features that were first shipped in 2014 with JDK 8. Since JDK 9 with the introduction of the --release N option to javac, it is easier to think of the source level, class file target version, and platform libraries as three inter-related properties that evolve in lockstep. (At a first approximation, --release OLD_VERSION is equivalent to "-source OLD_VERSION -target OLD_VERSION --bootclasspath OLD_PLATFORM_LIBRARIES.jar".) -Joe From magnus.ihse.bursie at oracle.com Thu Oct 24 11:04:13 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Oct 2024 13:04:13 +0200 Subject: Largest files in the JDK repo Message-ID: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 could integrate a 7 MB large file without nobody noticing, so I started wondering how many other huge text files there is in our repo. (We are much more restrictive with binary files, even if they are small...) So I compiled a top 100 list, which basically ended up being all files larger than 400 kB. In total, these 100 files account from ca 82 MB of data. I'm not saying that any of these files are wrong per se, but maybe some of the files on this list could provide a bit food for thought. Further down is the complete top-list, but it is a bit hard to get a grip on. I sorted and grouped the result, since the large files are not randomly sprinkled throughout the code base. This list does not contain test files. The huge test files are more numerous, but there are also (imho) more compelling reasons in general to allow for bigger files in testing. With that said, even some of the test files seems a bit excessive. (And one can not help but wonder what kind of file src/java.base/share/data/unicodedata/NormalizationTest.txt really is.) Character sets and localization: * make/data/charsetmapping * make/data/cldr * src/java.base/share/data/lsrdata/ * src/java.base/share/data/unicodedata * src/java.base/share/classes/java/lang/Character.java * src/java.base/share/classes/sun/nio/cs/GB18030.java * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template 3rd party source: * src/jdk.incubator.vector/*/native/libjsvml/*.S * src/java.base/share/native/libzip/zlib/crc32.h * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h Symbols from previous JDKS: * src/jdk.compiler/share/data/symbols Huge Hotspot files: * src/hotspot/cpu/*/*.ad * src/hotspot/cpu/x86/assembler_x86.cpp * src/hotspot/share/prims/jvmti.xml Other: * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf * src/java.base/share/classes/java/lang/invoke/MethodHandles.java * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java And a binary file: * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg And here is the complete top list: 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java 1.5M ./test/jdk/java/foreign/libTestUpcall.c 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt 928K ./make/data/charsetmapping/EUC_TW.map 927K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java 912K ./make/data/cldr/common/supplemental/likelySubtags.xml 898K ./make/data/charsetmapping/MS936.map 865K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template 857K ./test/jdk/java/foreign/libTestDowncall.c 843K ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h 794K ./make/data/cldr/common/main/ru.xml 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c 767K ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java 752K ./make/data/cldr/common/main/uk.xml 742K ./make/data/charsetmapping/Johab.map 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java 733K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S 731K ./make/data/charsetmapping/MS950.map 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt 698K ./make/data/charsetmapping/MS949.map 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c 655K ./src/hotspot/cpu/x86/assembler_x86.cpp 647K ./test/jdk/java/lang/instrument/BigClass.java 634K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S 628K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S 616K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java 597K ./src/hotspot/share/prims/jvmti.xml 597K ./test/jdk/sun/security/ec/SigGen-1.txt 593K ./make/data/cldr/common/main/lt.xml 582K ./make/data/cldr/common/main/cs.xml 579K ./src/java.base/share/native/libzip/zlib/crc32.h 577K ./make/data/cldr/common/main/sk.xml 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt 572K ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java 534K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S 532K ./make/data/cldr/common/main/ff_Adlm.xml 531K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt 523K ./make/data/cldr/common/main/pl.xml 520K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java 518K ./make/data/cldr/common/main/sl.xml 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java 509K ./make/data/cldr/common/main/mr.xml 507K ./make/data/cldr/common/main/kn.xml 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java 504K ./make/data/cldr/common/main/sr.xml 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar 501K ./make/data/cldr/common/main/ta.xml 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java 485K ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold 485K ./src/hotspot/cpu/aarch64/aarch64.ad 478K ./src/hotspot/cpu/ppc/ppc.ad 467K ./make/data/cldr/common/main/gd.xml 466K ./src/java.base/share/classes/java/lang/Character.java 453K ./make/data/cldr/common/main/ar.xml 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java 446K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S 445K ./make/data/cldr/common/main/cy.xml 443K ./make/data/cldr/common/main/ml.xml 442K ./make/data/cldr/common/main/br.xml 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java 442K ./make/data/cldr/common/main/hr.xml 441K ./src/hotspot/cpu/x86/x86_32.ad 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml 433K ./make/data/cldr/common/main/el.xml 432K ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java 429K ./make/data/cldr/common/main/lv.xml 428K ./make/data/cldr/common/main/fi.xml 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java 421K ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg 419K ./make/data/cldr/common/main/en.xml 418K ./src/hotspot/cpu/x86/x86.ad 416K ./make/data/cldr/common/main/sr_Latn.xml The list was compiled by running: find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | numfmt --field=1 --to=iec | head -n 100 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Oct 24 13:44:17 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 24 Oct 2024 13:44:17 +0000 Subject: JEP proposed to target JDK 24: 478: Key Derivation Function API (Preview) Message-ID: <20241024134414.D670477F43E@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 478: Key Derivation Function API (Preview) https://openjdk.org/jeps/478 Summary: Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. 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 16:00 UTC on Thursday, 31 October, 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 24. - 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 24 13:46:18 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 24 Oct 2024 13:46:18 +0000 Subject: JEP proposed to target JDK 24: 485: Stream Gatherers In-Reply-To: <20241016120850.E4CEE77E499@eggemoggin.niobe.net> References: <20241016120850.E4CEE77E499@eggemoggin.niobe.net> Message-ID: <20241024094617.796164958@eggemoggin.niobe.net> 2024/10/16 8:08:53 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 24: > > 485: Stream Gatherers > https://openjdk.org/jeps/485 > > Summary: Enhance the Stream API to support custom intermediate > operations. This will allow stream pipelines to transform data in ways > that are not easily achievable with the existing built-in intermediate > operations. > > 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 16:00 UTC on Wednesday, 23 October, 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 24. Hearing no objections, I?ve targeted this JEP to JDK 24. - Mark From naoto.sato at oracle.com Thu Oct 24 16:38:16 2024 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 24 Oct 2024 09:38:16 -0700 Subject: Largest files in the JDK repo In-Reply-To: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> References: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> Message-ID: <978f178e-9be5-4b95-8163-ed84a2a7291a@oracle.com> Thanks Magnus for food for thought. Character sets and localizations are inherently huge, as they cover each Unicode code point and locales. But I see some possibility of reducing, or removing ones that are for compatibility reasons, such as old GB18030 or *_OLD mappings. > excessive. (And one can not help but wonder what kind of file src/ > java.base/share/data/unicodedata/NormalizationTest.txt really is.) This file is a golden file from Unicode Consortium, in order to check the conformance to their normalization spec. Naoto On 10/24/24 4:04 AM, Magnus Ihse Bursie wrote: > I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 could > integrate a 7 MB large file without nobody noticing, so I started > wondering how many other huge text files there is in our repo. (We are > much more restrictive with binary files, even if they are small...) > > So I compiled a top 100 list, which basically ended up being all files > larger than 400 kB. In total, these 100 files account from ca 82 MB of > data. I'm not saying that any of these files are wrong per se, but maybe > some of the files on this list could provide a bit food for thought. > Further down is the complete top-list, but it is a bit hard to get a > grip on. I sorted and grouped the result, since the large files are not > randomly sprinkled throughout the code base. This list does not contain > test files. The huge test files are more numerous, but there are also > (imho) more compelling reasons in general to allow for bigger files in > testing. With that said, even some of the test files seems a bit > excessive. (And one can not help but wonder what kind of file src/ > java.base/share/data/unicodedata/NormalizationTest.txt really is.) > > Character sets and localization: > * make/data/charsetmapping > * make/data/cldr > * src/java.base/share/data/lsrdata/ > * src/java.base/share/data/unicodedata > * src/java.base/share/classes/java/lang/Character.java > * src/java.base/share/classes/sun/nio/cs/GB18030.java > * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java > * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template > 3rd party source: > * src/jdk.incubator.vector/*/native/libjsvml/*.S > * src/java.base/share/native/libzip/zlib/crc32.h > * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h > Symbols from previous JDKS: > * src/jdk.compiler/share/data/symbols > Huge Hotspot files: > * src/hotspot/cpu/*/*.ad > * src/hotspot/cpu/x86/assembler_x86.cpp > * src/hotspot/share/prims/jvmti.xml > Other: > * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf > * src/java.base/share/classes/java/lang/invoke/MethodHandles.java > * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java > And a binary file: > * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg > > And here is the complete top list: > > 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c > 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c > 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt > 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java > 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt > 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf > 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt > 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt > 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt > 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java > 1.5M ./test/jdk/java/foreign/libTestUpcall.c > 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt > 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java > 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt > 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words > 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt > 928K ./make/data/charsetmapping/EUC_TW.map > 927K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java > 912K ./make/data/cldr/common/supplemental/likelySubtags.xml > 898K ./make/data/charsetmapping/MS936.map > 865K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template > 857K ./test/jdk/java/foreign/libTestDowncall.c > 843K ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java > 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h > 794K ./make/data/cldr/common/main/ru.xml > 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c > 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c > 767K ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java > 752K ./make/data/cldr/common/main/uk.xml > 742K ./make/data/charsetmapping/Johab.map > 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c > 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java > 733K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S > 731K ./make/data/charsetmapping/MS950.map > 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c > 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt > 698K ./make/data/charsetmapping/MS949.map > 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c > 655K ./src/hotspot/cpu/x86/assembler_x86.cpp > 647K ./test/jdk/java/lang/instrument/BigClass.java > 634K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S > 628K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S > 616K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S > 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java > 597K ./src/hotspot/share/prims/jvmti.xml > 597K ./test/jdk/sun/security/ec/SigGen-1.txt > 593K ./make/data/cldr/common/main/lt.xml > 582K ./make/data/cldr/common/main/cs.xml > 579K ./src/java.base/share/native/libzip/zlib/crc32.h > 577K ./make/data/cldr/common/main/sk.xml > 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt > 572K ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html > 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java > 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c > 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > 534K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S > 532K ./make/data/cldr/common/main/ff_Adlm.xml > 531K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S > 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c > 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt > 523K ./make/data/cldr/common/main/pl.xml > 520K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java > 518K ./make/data/cldr/common/main/sl.xml > 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java > 509K ./make/data/cldr/common/main/mr.xml > 507K ./make/data/cldr/common/main/kn.xml > 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java > 504K ./make/data/cldr/common/main/sr.xml > 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java > 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar > 501K ./make/data/cldr/common/main/ta.xml > 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java > 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java > 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java > 485K ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold > 485K ./src/hotspot/cpu/aarch64/aarch64.ad > 478K ./src/hotspot/cpu/ppc/ppc.ad > 467K ./make/data/cldr/common/main/gd.xml > 466K ./src/java.base/share/classes/java/lang/Character.java > 453K ./make/data/cldr/common/main/ar.xml > 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java > 446K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S > 445K ./make/data/cldr/common/main/cy.xml > 443K ./make/data/cldr/common/main/ml.xml > 442K ./make/data/cldr/common/main/br.xml > 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java > 442K ./make/data/cldr/common/main/hr.xml > 441K ./src/hotspot/cpu/x86/x86_32.ad > 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java > 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml > 433K ./make/data/cldr/common/main/el.xml > 432K ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java > 429K ./make/data/cldr/common/main/lv.xml > 428K ./make/data/cldr/common/main/fi.xml > 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java > 421K ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg > 419K ./make/data/cldr/common/main/en.xml > 418K ./src/hotspot/cpu/x86/x86.ad > 416K ./make/data/cldr/common/main/sr_Latn.xml > > The list was compiled by running: > > find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | > numfmt --field=1 --to=iec | head -n 100 > From jorn.vernee at oracle.com Thu Oct 24 18:47:53 2024 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 24 Oct 2024 20:47:53 +0200 Subject: Largest files in the JDK repo In-Reply-To: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> References: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> Message-ID: WRT the two biggest files: 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c These are mechanically generate C libraries featuring a lot of different function shapes, for testing of FFM downcalls. The Java code that is used to generate these C files could theoretically run as part of the test as well, but the problem is that then we then need to compile the generated sources into a native library. Currently the JDK build system will find and build all native libraries needed for tests before any of the tests run, but maybe it's possible to create a way for a test to request that a native library be built on demand. Then we wouldn't need to pre-generate these files and include them in the repo, and could instead generate + compile them when the test runs. (This might also help cut down on the build time of the test image, since you'd only need to compile test libraries for the tests that actually run). Jorn On 24-10-2024 13:04, Magnus Ihse Bursie wrote: > > I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 > could integrate a 7 MB large file without nobody noticing, so I > started wondering how many other huge text files there is in our repo. > (We are much more restrictive with binary files, even if they are > small...) > > So I compiled a top 100 list, which basically ended up being all files > larger than 400 kB. In total, these 100 files account from ca 82 MB of > data. I'm not saying that any of these files are wrong per se, but > maybe some of the files on this list could provide a bit food for > thought. Further down is the complete top-list, but it is a bit hard > to get a grip on. I sorted and grouped the result, since the large > files are not randomly sprinkled throughout the code base. This list > does not contain test files. The huge test files are more numerous, > but there are also (imho) more compelling reasons in general to allow > for bigger files in testing. With that said, even some of the test > files seems a bit excessive. (And one can not help but wonder what > kind of file > src/java.base/share/data/unicodedata/NormalizationTest.txt really is.) > > Character sets and localization: > * make/data/charsetmapping > * make/data/cldr > * src/java.base/share/data/lsrdata/ > * src/java.base/share/data/unicodedata > * src/java.base/share/classes/java/lang/Character.java > * src/java.base/share/classes/sun/nio/cs/GB18030.java > * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java > * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template > 3rd party source: > * src/jdk.incubator.vector/*/native/libjsvml/*.S > * src/java.base/share/native/libzip/zlib/crc32.h > * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h > Symbols from previous JDKS: > * src/jdk.compiler/share/data/symbols > Huge Hotspot files: > * src/hotspot/cpu/*/*.ad > * src/hotspot/cpu/x86/assembler_x86.cpp > * src/hotspot/share/prims/jvmti.xml > Other: > * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf > * src/java.base/share/classes/java/lang/invoke/MethodHandles.java > * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java > And a binary file: > * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg > > And here is the complete top list: > > 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c > 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c > 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt > 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java > 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt > 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf > 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt > 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt > 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt > 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java > 1.5M ./test/jdk/java/foreign/libTestUpcall.c > 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt > 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java > 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt > 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words > 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt > 928K ./make/data/charsetmapping/EUC_TW.map > 927K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java > 912K ./make/data/cldr/common/supplemental/likelySubtags.xml > 898K ./make/data/charsetmapping/MS936.map > 865K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template > 857K ./test/jdk/java/foreign/libTestDowncall.c > 843K ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java > 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h > 794K ./make/data/cldr/common/main/ru.xml > 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c > 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c > 767K ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java > 752K ./make/data/cldr/common/main/uk.xml > 742K ./make/data/charsetmapping/Johab.map > 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c > 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java > 733K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S > 731K ./make/data/charsetmapping/MS950.map > 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c > 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt > 698K ./make/data/charsetmapping/MS949.map > 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c > 655K ./src/hotspot/cpu/x86/assembler_x86.cpp > 647K ./test/jdk/java/lang/instrument/BigClass.java > 634K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S > 628K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S > 616K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S > 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java > 597K ./src/hotspot/share/prims/jvmti.xml > 597K ./test/jdk/sun/security/ec/SigGen-1.txt > 593K ./make/data/cldr/common/main/lt.xml > 582K ./make/data/cldr/common/main/cs.xml > 579K ./src/java.base/share/native/libzip/zlib/crc32.h > 577K ./make/data/cldr/common/main/sk.xml > 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt > 572K ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html > 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java > 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c > 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > 534K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S > 532K ./make/data/cldr/common/main/ff_Adlm.xml > 531K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S > 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c > 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt > 523K ./make/data/cldr/common/main/pl.xml > 520K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java > 518K ./make/data/cldr/common/main/sl.xml > 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java > 509K ./make/data/cldr/common/main/mr.xml > 507K ./make/data/cldr/common/main/kn.xml > 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java > 504K ./make/data/cldr/common/main/sr.xml > 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java > 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar > 501K ./make/data/cldr/common/main/ta.xml > 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java > 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java > 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java > 485K ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold > 485K ./src/hotspot/cpu/aarch64/aarch64.ad > 478K ./src/hotspot/cpu/ppc/ppc.ad > 467K ./make/data/cldr/common/main/gd.xml > 466K ./src/java.base/share/classes/java/lang/Character.java > 453K ./make/data/cldr/common/main/ar.xml > 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java > 446K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S > 445K ./make/data/cldr/common/main/cy.xml > 443K ./make/data/cldr/common/main/ml.xml > 442K ./make/data/cldr/common/main/br.xml > 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java > 442K ./make/data/cldr/common/main/hr.xml > 441K ./src/hotspot/cpu/x86/x86_32.ad > 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java > 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml > 433K ./make/data/cldr/common/main/el.xml > 432K ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java > 429K ./make/data/cldr/common/main/lv.xml > 428K ./make/data/cldr/common/main/fi.xml > 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java > 421K ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg > 419K ./make/data/cldr/common/main/en.xml > 418K ./src/hotspot/cpu/x86/x86.ad > 416K ./make/data/cldr/common/main/sr_Latn.xml > > The list was compiled by running: > > find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | > numfmt --field=1 --to=iec | head -n 100 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Oct 24 20:23:09 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Oct 2024 22:23:09 +0200 Subject: Largest files in the JDK repo In-Reply-To: <978f178e-9be5-4b95-8163-ed84a2a7291a@oracle.com> References: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> <978f178e-9be5-4b95-8163-ed84a2a7291a@oracle.com> Message-ID: On 2024-10-24 18:38, Naoto Sato wrote: > Thanks Magnus for food for thought. > > Character sets and localizations are inherently huge, as they cover > each Unicode code point and locales. I understand. I guess we are not trying to use any kind of compact representation in the source code either, assuming it is better to have something that is readable but large rather than e.g. a compressed binary file. > But I see some possibility of reducing, or removing ones that are for > compatibility reasons, such as old GB18030 or *_OLD mappings. That'd certainly be nice! > > excessive. (And one can not help but wonder what kind of file src/ > > java.base/share/data/unicodedata/NormalizationTest.txt really is.) > > This file is a golden file from Unicode Consortium, in order to check > the conformance to their normalization spec. Is it used in production code? Otherwise maybe we should move it to the test directory hierarchy. /Magnus > > Naoto > > On 10/24/24 4:04 AM, Magnus Ihse Bursie wrote: >> I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 >> could integrate a 7 MB large file without nobody noticing, so I >> started wondering how many other huge text files there is in our >> repo. (We are much more restrictive with binary files, even if they >> are small...) >> >> So I compiled a top 100 list, which basically ended up being all >> files larger than 400 kB. In total, these 100 files account from ca >> 82 MB of data. I'm not saying that any of these files are wrong per >> se, but maybe some of the files on this list could provide a bit food >> for thought. Further down is the complete top-list, but it is a bit >> hard to get a grip on. I sorted and grouped the result, since the >> large files are not randomly sprinkled throughout the code base. This >> list does not contain test files. The huge test files are more >> numerous, but there are also (imho) more compelling reasons in >> general to allow for bigger files in testing. With that said, even >> some of the test files seems a bit excessive. (And one can not help >> but wonder what kind of file src/ >> java.base/share/data/unicodedata/NormalizationTest.txt really is.) >> >> Character sets and localization: >> * make/data/charsetmapping >> * make/data/cldr >> * src/java.base/share/data/lsrdata/ >> * src/java.base/share/data/unicodedata >> * src/java.base/share/classes/java/lang/Character.java >> * src/java.base/share/classes/sun/nio/cs/GB18030.java >> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >> 3rd party source: >> * src/jdk.incubator.vector/*/native/libjsvml/*.S >> * src/java.base/share/native/libzip/zlib/crc32.h >> * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >> Symbols from previous JDKS: >> * src/jdk.compiler/share/data/symbols >> Huge Hotspot files: >> * src/hotspot/cpu/*/*.ad >> * src/hotspot/cpu/x86/assembler_x86.cpp >> * src/hotspot/share/prims/jvmti.xml >> Other: >> * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >> * src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >> And a binary file: >> * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >> >> And here is the complete top list: >> >> 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c >> 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c >> 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt >> 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java >> 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt >> 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >> 2.0M >> ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt >> 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt >> 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt >> 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java >> 1.5M ./test/jdk/java/foreign/libTestUpcall.c >> 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt >> 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java >> 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt >> 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words >> 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt >> 928K ./make/data/charsetmapping/EUC_TW.map >> 927K >> ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java >> 912K ./make/data/cldr/common/supplemental/likelySubtags.xml >> 898K ./make/data/charsetmapping/MS936.map >> 865K >> ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >> 857K ./test/jdk/java/foreign/libTestDowncall.c >> 843K >> ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java >> 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >> 794K ./make/data/cldr/common/main/ru.xml >> 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c >> 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c >> 767K >> ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java >> 752K ./make/data/cldr/common/main/uk.xml >> 742K ./make/data/charsetmapping/Johab.map >> 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c >> 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java >> 733K >> ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S >> 731K ./make/data/charsetmapping/MS950.map >> 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c >> 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt >> 698K ./make/data/charsetmapping/MS949.map >> 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c >> 655K ./src/hotspot/cpu/x86/assembler_x86.cpp >> 647K ./test/jdk/java/lang/instrument/BigClass.java >> 634K >> ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S >> 628K >> ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S >> 616K >> ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S >> 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >> 597K ./src/hotspot/share/prims/jvmti.xml >> 597K ./test/jdk/sun/security/ec/SigGen-1.txt >> 593K ./make/data/cldr/common/main/lt.xml >> 582K ./make/data/cldr/common/main/cs.xml >> 579K ./src/java.base/share/native/libzip/zlib/crc32.h >> 577K ./make/data/cldr/common/main/sk.xml >> 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt >> 572K >> ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html >> 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java >> 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c >> 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java >> 534K >> ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S >> 532K ./make/data/cldr/common/main/ff_Adlm.xml >> 531K >> ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S >> 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c >> 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt >> 523K ./make/data/cldr/common/main/pl.xml >> 520K >> ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java >> 518K ./make/data/cldr/common/main/sl.xml >> 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java >> 509K ./make/data/cldr/common/main/mr.xml >> 507K ./make/data/cldr/common/main/kn.xml >> 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java >> 504K ./make/data/cldr/common/main/sr.xml >> 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java >> 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar >> 501K ./make/data/cldr/common/main/ta.xml >> 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java >> 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java >> 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java >> 485K >> ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold >> 485K ./src/hotspot/cpu/aarch64/aarch64.ad >> 478K ./src/hotspot/cpu/ppc/ppc.ad >> 467K ./make/data/cldr/common/main/gd.xml >> 466K ./src/java.base/share/classes/java/lang/Character.java >> 453K ./make/data/cldr/common/main/ar.xml >> 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java >> 446K >> ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S >> 445K ./make/data/cldr/common/main/cy.xml >> 443K ./make/data/cldr/common/main/ml.xml >> 442K ./make/data/cldr/common/main/br.xml >> 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java >> 442K ./make/data/cldr/common/main/hr.xml >> 441K ./src/hotspot/cpu/x86/x86_32.ad >> 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml >> 433K ./make/data/cldr/common/main/el.xml >> 432K >> ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >> 429K ./make/data/cldr/common/main/lv.xml >> 428K ./make/data/cldr/common/main/fi.xml >> 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java >> 421K >> ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >> 419K ./make/data/cldr/common/main/en.xml >> 418K ./src/hotspot/cpu/x86/x86.ad >> 416K ./make/data/cldr/common/main/sr_Latn.xml >> >> The list was compiled by running: >> >> find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | >> numfmt --field=1 --to=iec | head -n 100 >> > From magnus.ihse.bursie at oracle.com Thu Oct 24 20:28:43 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Oct 2024 22:28:43 +0200 Subject: Largest files in the JDK repo In-Reply-To: References: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> Message-ID: <6ffb0658-7ec4-45c9-a282-d72d9ec07210@oracle.com> On 2024-10-24 20:47, Jorn Vernee wrote: > WRT the two biggest files: > > 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c > 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c > > These are mechanically generate C libraries featuring a lot of > different function shapes, for testing of FFM downcalls. The Java code > that is used to generate these C files could theoretically run as part > of the test as well, but the problem is that then we then need to > compile the generated sources into a native library. > > Currently the JDK build system will find and build all native > libraries needed for tests before any of the tests run, but maybe it's > possible to create a way for a test to request that a native library > be built on demand. Then we wouldn't need to pre-generate these files > and include them in the repo, and could instead generate + compile > them when the test runs. (This might also help cut down on the build > time of the test image, since you'd only need to compile test > libraries for the tests that actually run). > Unfortunately, requesting compilation of native code at test time is not trivial to support, and I don't even think we want to even try doing that, for various reasons. However, generating source code just in time for compilation is commonplace in the JDK; we call it "gensrc" in the build system. We have not done so for tests so far, but it would not be horribly hard to change add gensrc functionality to native tests as well. I'd say that there are three criteria that indicate we should start using a gensrc system for these tests: 1) They are generated by a Java tool 2) That tool runs rather quickly 3) Changing that tool, rather than changing the individual files, is the preferred way of updating this source code You indicated that 1 is true. Is that the case for 2 and 3 as well? /Magnus > Jorn > > On 24-10-2024 13:04, Magnus Ihse Bursie wrote: >> >> I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 >> could integrate a 7 MB large file without nobody noticing, so I >> started wondering how many other huge text files there is in our >> repo. (We are much more restrictive with binary files, even if they >> are small...) >> >> So I compiled a top 100 list, which basically ended up being all >> files larger than 400 kB. In total, these 100 files account from ca >> 82 MB of data. I'm not saying that any of these files are wrong per >> se, but maybe some of the files on this list could provide a bit food >> for thought. Further down is the complete top-list, but it is a bit >> hard to get a grip on. I sorted and grouped the result, since the >> large files are not randomly sprinkled throughout the code base. This >> list does not contain test files. The huge test files are more >> numerous, but there are also (imho) more compelling reasons in >> general to allow for bigger files in testing. With that said, even >> some of the test files seems a bit excessive. (And one can not help >> but wonder what kind of file >> src/java.base/share/data/unicodedata/NormalizationTest.txt really is.) >> >> Character sets and localization: >> * make/data/charsetmapping >> * make/data/cldr >> * src/java.base/share/data/lsrdata/ >> * src/java.base/share/data/unicodedata >> * src/java.base/share/classes/java/lang/Character.java >> * src/java.base/share/classes/sun/nio/cs/GB18030.java >> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >> 3rd party source: >> * src/jdk.incubator.vector/*/native/libjsvml/*.S >> * src/java.base/share/native/libzip/zlib/crc32.h >> * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >> Symbols from previous JDKS: >> * src/jdk.compiler/share/data/symbols >> Huge Hotspot files: >> * src/hotspot/cpu/*/*.ad >> * src/hotspot/cpu/x86/assembler_x86.cpp >> * src/hotspot/share/prims/jvmti.xml >> Other: >> * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >> * src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >> And a binary file: >> * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >> >> And here is the complete top list: >> >> 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c >> 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c >> 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt >> 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java >> 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt >> 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >> 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt >> 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt >> 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt >> 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java >> 1.5M ./test/jdk/java/foreign/libTestUpcall.c >> 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt >> 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java >> 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt >> 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words >> 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt >> 928K ./make/data/charsetmapping/EUC_TW.map >> 927K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java >> 912K ./make/data/cldr/common/supplemental/likelySubtags.xml >> 898K ./make/data/charsetmapping/MS936.map >> 865K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >> 857K ./test/jdk/java/foreign/libTestDowncall.c >> 843K ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java >> 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >> 794K ./make/data/cldr/common/main/ru.xml >> 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c >> 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c >> 767K ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java >> 752K ./make/data/cldr/common/main/uk.xml >> 742K ./make/data/charsetmapping/Johab.map >> 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c >> 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java >> 733K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S >> 731K ./make/data/charsetmapping/MS950.map >> 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c >> 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt >> 698K ./make/data/charsetmapping/MS949.map >> 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c >> 655K ./src/hotspot/cpu/x86/assembler_x86.cpp >> 647K ./test/jdk/java/lang/instrument/BigClass.java >> 634K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S >> 628K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S >> 616K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S >> 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >> 597K ./src/hotspot/share/prims/jvmti.xml >> 597K ./test/jdk/sun/security/ec/SigGen-1.txt >> 593K ./make/data/cldr/common/main/lt.xml >> 582K ./make/data/cldr/common/main/cs.xml >> 579K ./src/java.base/share/native/libzip/zlib/crc32.h >> 577K ./make/data/cldr/common/main/sk.xml >> 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt >> 572K ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html >> 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java >> 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c >> 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java >> 534K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S >> 532K ./make/data/cldr/common/main/ff_Adlm.xml >> 531K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S >> 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c >> 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt >> 523K ./make/data/cldr/common/main/pl.xml >> 520K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java >> 518K ./make/data/cldr/common/main/sl.xml >> 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java >> 509K ./make/data/cldr/common/main/mr.xml >> 507K ./make/data/cldr/common/main/kn.xml >> 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java >> 504K ./make/data/cldr/common/main/sr.xml >> 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java >> 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar >> 501K ./make/data/cldr/common/main/ta.xml >> 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java >> 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java >> 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java >> 485K ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold >> 485K ./src/hotspot/cpu/aarch64/aarch64.ad >> 478K ./src/hotspot/cpu/ppc/ppc.ad >> 467K ./make/data/cldr/common/main/gd.xml >> 466K ./src/java.base/share/classes/java/lang/Character.java >> 453K ./make/data/cldr/common/main/ar.xml >> 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java >> 446K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S >> 445K ./make/data/cldr/common/main/cy.xml >> 443K ./make/data/cldr/common/main/ml.xml >> 442K ./make/data/cldr/common/main/br.xml >> 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java >> 442K ./make/data/cldr/common/main/hr.xml >> 441K ./src/hotspot/cpu/x86/x86_32.ad >> 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml >> 433K ./make/data/cldr/common/main/el.xml >> 432K ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >> 429K ./make/data/cldr/common/main/lv.xml >> 428K ./make/data/cldr/common/main/fi.xml >> 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java >> 421K ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >> 419K ./make/data/cldr/common/main/en.xml >> 418K ./src/hotspot/cpu/x86/x86.ad >> 416K ./make/data/cldr/common/main/sr_Latn.xml >> >> The list was compiled by running: >> >> find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | >> numfmt --field=1 --to=iec | head -n 100 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorn.vernee at oracle.com Thu Oct 24 22:29:40 2024 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 25 Oct 2024 00:29:40 +0200 Subject: Largest files in the JDK repo In-Reply-To: <6ffb0658-7ec4-45c9-a282-d72d9ec07210@oracle.com> References: <25ae2fa6-0ecb-441a-b30b-629f74180741@oracle.com> <6ffb0658-7ec4-45c9-a282-d72d9ec07210@oracle.com> Message-ID: <73472f9b-2443-4ac1-b792-86525b8f9bc6@oracle.com> > You indicated that 1 is true. Is that the case for 2 and 3 as well? Yes, both 2 and 3 are true. (3 is in fact required, because the test code uses the same stream of 'shapes' to do the actual calls). The program that generates this code is test/jdk/java/foreign/CallgeneratorHelper.java [1] It generates 5 files in total. It's a bit entangled with the current test code, but nothing we can't separate out I think. I suppose the trickiest part is that the actual test also needs access to the code when running. FWIW, we have other examples of test code that is generated by scripts as well, such as test/jdk/java/lang/invoke/VarHandles/generate-vh-tests.sh and various scripts under test/jdk/java/nio/Buffer which invoke SPP. There are probably more cases like that. Jorn [1]: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/CallGeneratorHelper.java On 24-10-2024 22:28, Magnus Ihse Bursie wrote: > > On 2024-10-24 20:47, Jorn Vernee wrote: > >> WRT the two biggest files: >> >> 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c >> 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c >> >> These are mechanically generate C libraries featuring a lot of >> different function shapes, for testing of FFM downcalls. The Java >> code that is used to generate these C files could theoretically run >> as part of the test as well, but the problem is that then we then >> need to compile the generated sources into a native library. >> >> Currently the JDK build system will find and build all native >> libraries needed for tests before any of the tests run, but maybe >> it's possible to create a way for a test to request that a native >> library be built on demand. Then we wouldn't need to pre-generate >> these files and include them in the repo, and could instead generate >> + compile them when the test runs. (This might also help cut down on >> the build time of the test image, since you'd only need to compile >> test libraries for the tests that actually run). >> > Unfortunately, requesting compilation of native code at test time is > not trivial to support, and I don't even think we want to even try > doing that, for various reasons. > > However, generating source code just in time for compilation is > commonplace in the JDK; we call it "gensrc" in the build system. We > have not done so for tests so far, but it would not be horribly hard > to change add gensrc functionality to native tests as well. > > I'd say that there are three criteria that indicate we should start > using a gensrc system for these tests: > > 1) They are generated by a Java tool > > 2) That tool runs rather quickly > > 3) Changing that tool, rather than changing the individual files, is > the preferred way of updating this source code > > You indicated that 1 is true. Is that the case for 2 and 3 as well? > > /Magnus > > >> Jorn >> >> On 24-10-2024 13:04, Magnus Ihse Bursie wrote: >>> >>> I got intrigued at how https://bugs.openjdk.org/browse/JDK-8339507 >>> could integrate a 7 MB large file without nobody noticing, so I >>> started wondering how many other huge text files there is in our >>> repo. (We are much more restrictive with binary files, even if they >>> are small...) >>> >>> So I compiled a top 100 list, which basically ended up being all >>> files larger than 400 kB. In total, these 100 files account from ca >>> 82 MB of data. I'm not saying that any of these files are wrong per >>> se, but maybe some of the files on this list could provide a bit >>> food for thought. Further down is the complete top-list, but it is a >>> bit hard to get a grip on. I sorted and grouped the result, since >>> the large files are not randomly sprinkled throughout the code base. >>> This list does not contain test files. The huge test files are more >>> numerous, but there are also (imho) more compelling reasons in >>> general to allow for bigger files in testing. With that said, even >>> some of the test files seems a bit excessive. (And one can not help >>> but wonder what kind of file >>> src/java.base/share/data/unicodedata/NormalizationTest.txt really is.) >>> >>> Character sets and localization: >>> * make/data/charsetmapping >>> * make/data/cldr >>> * src/java.base/share/data/lsrdata/ >>> * src/java.base/share/data/unicodedata >>> * src/java.base/share/classes/java/lang/Character.java >>> * src/java.base/share/classes/sun/nio/cs/GB18030.java >>> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >>> * src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >>> 3rd party source: >>> * src/jdk.incubator.vector/*/native/libjsvml/*.S >>> * src/java.base/share/native/libzip/zlib/crc32.h >>> * src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >>> Symbols from previous JDKS: >>> * src/jdk.compiler/share/data/symbols >>> Huge Hotspot files: >>> * src/hotspot/cpu/*/*.ad >>> * src/hotspot/cpu/x86/assembler_x86.cpp >>> * src/hotspot/share/prims/jvmti.xml >>> Other: >>> * src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >>> * src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> * src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >>> And a binary file: >>> * src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >>> >>> And here is the complete top list: >>> >>> 6.8M ./test/jdk/java/foreign/libTestUpcallStack.c >>> 3.5M ./test/jdk/java/foreign/libTestDowncallStack.c >>> 2.7M ./test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >>> 2.6M ./src/java.base/share/data/unicodedata/NormalizationTest.txt >>> 2.3M ./test/jdk/sun/nio/cs/EUC_TW_OLD.java >>> 2.1M ./src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt >>> 2.0M ./src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf >>> 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.Corrigendum4.txt >>> 2.0M ./test/jdk/java/text/Normalizer/NormalizationTest-3.2.0.txt >>> 1.9M ./src/java.base/share/data/unicodedata/UnicodeData.txt >>> 1.6M ./test/hotspot/jtreg/gc/TestBigObj.java >>> 1.5M ./test/jdk/java/foreign/libTestUpcall.c >>> 1.4M ./src/jdk.compiler/share/data/symbols/java.base-8.sym.txt >>> 1.2M ./test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java >>> 1.1M ./src/java.base/share/data/unicodedata/DerivedCoreProperties.txt >>> 952K ./test/hotspot/jtreg/compiler/c2/stemmer/words >>> 941K ./src/jdk.compiler/share/data/symbols/java.base-M.sym.txt >>> 928K ./make/data/charsetmapping/EUC_TW.map >>> 927K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/INDIFY_Test.java >>> 912K ./make/data/cldr/common/supplemental/likelySubtags.xml >>> 898K ./make/data/charsetmapping/MS936.map >>> 865K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template >>> 857K ./test/jdk/java/foreign/libTestDowncall.c >>> 843K ./test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java >>> 830K ./src/java.desktop/share/native/common/java2d/opengl/J2D_GL/glext.h >>> 794K ./make/data/cldr/common/main/ru.xml >>> 774K ./test/jdk/sun/nio/cs/mapping/GB18030_2000.b2c >>> 774K ./test/jdk/sun/nio/cs/mapping/GB18030.b2c >>> 767K ./test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java >>> 752K ./make/data/cldr/common/main/uk.xml >>> 742K ./make/data/charsetmapping/Johab.map >>> 741K ./test/jdk/sun/nio/cs/mapping/Johab.b2c >>> 739K ./src/java.base/share/classes/sun/nio/cs/GB18030.java >>> 733K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S >>> 731K ./make/data/charsetmapping/MS950.map >>> 727K ./test/jdk/sun/nio/cs/mapping/MS950.b2c >>> 709K ./src/java.base/share/data/lsrdata/language-subtag-registry.txt >>> 698K ./make/data/charsetmapping/MS949.map >>> 695K ./test/jdk/sun/nio/cs/mapping/MS949.b2c >>> 655K ./src/hotspot/cpu/x86/assembler_x86.cpp >>> 647K ./test/jdk/java/lang/instrument/BigClass.java >>> 634K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S >>> 628K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S >>> 616K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S >>> 601K ./src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java >>> 597K ./src/hotspot/share/prims/jvmti.xml >>> 597K ./test/jdk/sun/security/ec/SigGen-1.txt >>> 593K ./make/data/cldr/common/main/lt.xml >>> 582K ./make/data/cldr/common/main/cs.xml >>> 579K ./src/java.base/share/native/libzip/zlib/crc32.h >>> 577K ./make/data/cldr/common/main/sk.xml >>> 577K ./src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt >>> 572K ./test/jdk/javax/swing/text/html/parser/Parser/8078268/slowparse.html >>> 567K ./test/jdk/sun/nio/cs/OLD/IBM933_OLD.java >>> 539K ./test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c >>> 536K ./test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java >>> 534K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S >>> 532K ./make/data/cldr/common/main/ff_Adlm.xml >>> 531K ./src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S >>> 526K ./test/jdk/sun/nio/cs/mapping/EUC_TW.b2c >>> 524K ./src/jdk.compiler/share/data/symbols/java.desktop-B.sym.txt >>> 523K ./make/data/cldr/common/main/pl.xml >>> 520K ./test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/java/loopsAndThreads/INDIFY_Test.java >>> 518K ./make/data/cldr/common/main/sl.xml >>> 510K ./test/jdk/sun/nio/cs/OLD/IBM950_OLD.java >>> 509K ./make/data/cldr/common/main/mr.xml >>> 507K ./make/data/cldr/common/main/kn.xml >>> 505K ./test/jdk/sun/nio/cs/OLD/IBM948_OLD.java >>> 504K ./make/data/cldr/common/main/sr.xml >>> 503K ./test/jdk/sun/nio/cs/OLD/IBM937_OLD.java >>> 502K ./test/jdk/sun/net/www/protocol/jar/foo1.jar >>> 501K ./make/data/cldr/common/main/ta.xml >>> 496K ./test/jdk/sun/nio/cs/OLD/Johab_OLD.java >>> 490K ./test/jdk/sun/nio/cs/OLD/MS949_OLD.java >>> 489K ./test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/LTTest.java >>> 485K ./test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold >>> 485K ./src/hotspot/cpu/aarch64/aarch64.ad >>> 478K ./src/hotspot/cpu/ppc/ppc.ad >>> 467K ./make/data/cldr/common/main/gd.xml >>> 466K ./src/java.base/share/classes/java/lang/Character.java >>> 453K ./make/data/cldr/common/main/ar.xml >>> 452K ./test/jdk/sun/nio/cs/OLD/IBM949_OLD.java >>> 446K ./src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S >>> 445K ./make/data/cldr/common/main/cy.xml >>> 443K ./make/data/cldr/common/main/ml.xml >>> 442K ./make/data/cldr/common/main/br.xml >>> 442K ./test/jdk/sun/nio/cs/OLD/MS950_OLD.java >>> 442K ./make/data/cldr/common/main/hr.xml >>> 441K ./src/hotspot/cpu/x86/x86_32.ad >>> 438K ./src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> 436K ./test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml >>> 433K ./make/data/cldr/common/main/el.xml >>> 432K ./src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java >>> 429K ./make/data/cldr/common/main/lv.xml >>> 428K ./make/data/cldr/common/main/fi.xml >>> 427K ./test/jdk/sun/nio/cs/OLD/GBK_OLD.java >>> 421K ./src/demo/share/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg >>> 419K ./make/data/cldr/common/main/en.xml >>> 418K ./src/hotspot/cpu/x86/x86.ad >>> 416K ./make/data/cldr/common/main/sr_Latn.xml >>> >>> The list was compiled by running: >>> >>> find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -nr | >>> numfmt --field=1 --to=iec | head -n 100 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: