From jianglizhou at google.com Sat Feb 1 00:29:29 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 31 Jan 2025 16:29:29 -0800 Subject: Jtreg tests with JNI native code on static JDK Message-ID: With the recently enhancements in JDK mainline (thanks for all contributions to the related work), it's able to build a static-jdk image (support a static-jdk/bin/java launcher executable statically linked with JDK/hotspot native), and able to execute jtreg tests on the static-jdk image. While the JDK mainline is reaching this milestone, I think it would be good to start a conversation to seed the brainstorm on jtreg testing on static-jdk image, specifically for tests with JNI natives. For jtreg tests with native, the native code has normally been linked into shared libraries. JEPS 178 enhanced JNI specification to support statically linked native libraries. As a result, we could build the jtreg test native code into static libraries and link those with the static-jdk/bin/java launcher. An obvious alternative is to continue building the jtreg test native code in shared libraries for testing on static-jdk images. The alternative is feasible (the current leyden/tree/hermetic-java-runtime branch can be used to demonstrate this capability). It's probably also a less disruptive solution for running jtreg tests on static JDK using today's existing testing framework/setup. There are some pre-existing assumptions about dynamic loading and linking native libraries in the tests (we have addressed and resolved many of those in JDK and VM in JDK mainline already). For both approaches described in above paragraph, we would need to remove these assumptions from the jtreg tests regardless which approach is used for building/packaging the test native code. Would be great to see this brief writeup brings in more thoughts and discussions on the Jtreg testing strategy on static JDK. Thanks! Best, Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens at lidestrom.se Mon Feb 3 10:13:01 2025 From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=C3=B6m?=) Date: Mon, 03 Feb 2025 11:13:01 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <2c47f37b3ae3decba2159e44f27ea33b@lidestrom.se> Hello Harald, I'm just an interested observer with a question. I think that the ambition is commendable! How can I find out which changes in the Battleblow repository that are for BSD customization? There is the branch bsd-port, but on that branch there are also a lot of changes that are integrated from the upstream JDK repository. I can search the repository for commits by the user battleblow: https://github.com/battleblow/jdk21u/commits/bsd-port/?author=battleblow But maybe there are more changes by other committers? Regards, Jens On 2025-01-30 19:17, Harald Eilertsen wrote: > Hi, > > I've been contracted by The FreeBSD Foundation to try to improve > OpenJDK > support for the FreeBSD operating system. Currently the BSD port lives > in a separate github org over at https://github.com/battleblow, but > we'd > like to make porting easier and more streamlined in the future by > submitting our changes to the mainline OpenJDK repo. > > Currently I'm thinking the best approach is to submit small, self > contained patches adressing specific issues when trying to build on > FreeBSD. Both to make reviewing more manageable, but also to get > feedback so that we ensure the changes integrate as smoothly with the > OpenJDK project as possible. > > Will it be best to create a JBS issue for each change, or one issue for > the entire effort? > > Thanks in advance! > > Harald Eilertsen > -- > Eilertsens Kodeknekkeri > https://kodeknekkeriet.net From harald+jdklists at volse.no Mon Feb 3 12:08:05 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Mon, 3 Feb 2025 13:08:05 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <2c47f37b3ae3decba2159e44f27ea33b@lidestrom.se> References: <2c47f37b3ae3decba2159e44f27ea33b@lidestrom.se> Message-ID: <44kjyslj3nvvh25y2ieg2oknf2lwlumczsgqf3x3shd56g67pn@ztsvmkjhba2e> Hi Jens, Thans for the response! On Mon, Feb 03, 2025 at 11:13:01AM +0100, Jens Lidestr?m wrote: > How can I find out which changes in the Battleblow repository that are for > BSD customization? My approach has been mainly to compare the diff between the bsd-port branch and the master branch (or the source repo from the openjdk org.) Looking at files changed, rather than commit history gives a better overview, I think. I've combined that with the commit history of specific files to find the rationale for why things are different, when it was unclear. Probably the best (minimal) diff for now is my work on the jdk24u port, that's still in my private fork: https://github.com/snake66/jdk24u > I can search the repository for commits by the user battleblow: > > https://github.com/battleblow/jdk21u/commits/bsd-port/?author=battleblow > > But maybe there are more changes by other committers? Yes, there are. The majority should be by battleblow, glewis or bsdkurt. But as mentioned, I find it better to start with the diff rather than the commit history for an overview. Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net From jorn.vernee at oracle.com Mon Feb 3 14:06:56 2025 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 3 Feb 2025 15:06:56 +0100 Subject: Jtreg tests with JNI native code on static JDK In-Reply-To: References: Message-ID: <5a641175-d37c-40c9-882f-d25140134be3@oracle.com> Statically linking native test libraries seems strange to me. If we think of a test case as a user of the Java runtime, it should not matter whether the Java runtime is a hermetic image or not, and dynamic linking of native libraries should continue to work as before, I think. Unless I'm misunderstanding the goal of hermetic images, it is still possible to dynamically load e.g. jar files with a hermetic Java image, right? Those jar files could contain/depend on dynamic native libraries, so I think either way those need to be supported. > There are some pre-existing assumptions about dynamic?loading and linking native libraries?in the tests (we have addressed and resolved many of those in JDK and VM in JDK mainline already). For both approaches described in above paragraph, we would need to remove these assumptions from the jtreg tests regardless which approach is used for building/packaging the test native code. Could you give some examples of the assumptions you're talking about here? Jorn On 1-2-2025 01:29, Jiangli Zhou wrote: > With the recently enhancements in JDK mainline (thanks for all > contributions to the related work), it's able to build a static-jdk > image (support a static-jdk/bin/java launcher executable statically > linked with JDK/hotspot native), and able to execute jtreg tests on > the static-jdk image. While the JDK mainline is reaching this > milestone, I think it would be good to start a conversation to seed > the brainstorm on jtreg testing on static-jdk image, specifically for > tests with JNI natives. > > For jtreg tests with native, the native code has normally been linked > into shared libraries. JEPS 178 > ?enhanced JNI specification to support > statically linked native libraries. As a result, we could build the > jtreg test native code into static libraries and link those with the > static-jdk/bin/java launcher. An obvious alternative is to continue > building the jtreg test native code in shared libraries for testing on > static-jdk images. The alternative is feasible (the current > leyden/tree/hermetic-java-runtime > ?branch > can be used to demonstrate this capability). It's probably also a less > disruptive solution for running jtreg tests on static JDK using > today's existing testing framework/setup. > > There are some pre-existing assumptions about dynamic?loading and > linking native libraries?in the tests (we have addressed and resolved > many of those in JDK and VM in JDK mainline already). For both > approaches described in above paragraph, we would need to remove these > assumptions from the jtreg tests regardless which approach is used for > building/packaging the test native code. Would be great to see this > brief writeup brings in more thoughts and discussions on the Jtreg > testing strategy?on static JDK.? Thanks! > > Best, > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianglizhou at google.com Mon Feb 3 19:42:10 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 3 Feb 2025 11:42:10 -0800 Subject: Jtreg tests with JNI native code on static JDK In-Reply-To: <5a641175-d37c-40c9-882f-d25140134be3@oracle.com> References: <5a641175-d37c-40c9-882f-d25140134be3@oracle.com> Message-ID: Thanks for the thoughts, Jorn! On Mon, Feb 3, 2025 at 6:07?AM Jorn Vernee wrote: > Could you give some examples of the assumptions you're talking about here? > One example is test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java. When building libatExt, it explicitly links with libjvm.so (e.g. on Linux), which becomes a recorded dependency of libatExit.so: https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49 ``` BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm ``` ``` $ ldd ./build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib/libatExit.so linux-vdso.so.1 (0x00007fb80017c000) libjvm.so => (snip) ... /lib64/ld-linux-x86-64.so.2 (0x00007fb80017e000) ``` Runtime linker and loader would resolve and load the dependency `libjvm.so` when loading `libatExit.so`. As static-jdk does not provide `libjvm.so`, it would fail when running the test using the static-jdk. I filed https://bugs.openjdk.org/browse/JDK-8349178. The good thing is so far testing only has found just a few such cases in Tier1 tests. Best regards, Jiangli From david.holmes at oracle.com Tue Feb 4 10:26:12 2025 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Feb 2025 20:26:12 +1000 Subject: Jtreg tests with JNI native code on static JDK In-Reply-To: References: <5a641175-d37c-40c9-882f-d25140134be3@oracle.com> Message-ID: <55371978-848b-4f92-856f-813bd2216dc9@oracle.com> Hi Jiangli, On 4/02/2025 5:42 am, Jiangli Zhou wrote: > Thanks for the thoughts, Jorn! > > On Mon, Feb 3, 2025 at 6:07?AM Jorn Vernee wrote: > >> Could you give some examples of the assumptions you're talking about here? >> > > One example is test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java. > When building libatExt, it explicitly links with libjvm.so (e.g. on > Linux), which becomes a recorded dependency of libatExit.so: > > https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49 > ``` > BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm > ``` So does this mean that any test (or application) that uses JNI and has to link to libjvm will need to be modified to work with a statically linked JDK? David ----- > ``` > $ ldd ./build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib/libatExit.so > linux-vdso.so.1 (0x00007fb80017c000) > libjvm.so => (snip) > ... > /lib64/ld-linux-x86-64.so.2 (0x00007fb80017e000) > ``` > > Runtime linker and loader would resolve and load the dependency > `libjvm.so` when loading `libatExit.so`. As static-jdk does not > provide `libjvm.so`, it would fail when running the test using the > static-jdk. I filed https://bugs.openjdk.org/browse/JDK-8349178. > > The good thing is so far testing only has found just a few such cases > in Tier1 tests. > > Best regards, > Jiangli From jianglizhou at google.com Tue Feb 4 17:59:43 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 4 Feb 2025 09:59:43 -0800 Subject: Jtreg tests with JNI native code on static JDK In-Reply-To: <55371978-848b-4f92-856f-813bd2216dc9@oracle.com> References: <5a641175-d37c-40c9-882f-d25140134be3@oracle.com> <55371978-848b-4f92-856f-813bd2216dc9@oracle.com> Message-ID: On Tue, Feb 4, 2025 at 2:26?AM David Holmes wrote: > > Hi Jiangli, > > On 4/02/2025 5:42 am, Jiangli Zhou wrote: > > Thanks for the thoughts, Jorn! > > > > On Mon, Feb 3, 2025 at 6:07?AM Jorn Vernee wrote: > > > >> Could you give some examples of the assumptions you're talking about here? > >> > > > > One example is test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java. > > When building libatExt, it explicitly links with libjvm.so (e.g. on > > Linux), which becomes a recorded dependency of libatExit.so: > > > > https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49 > > ``` > > BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm > > ``` > > So does this mean that any test (or application) that uses JNI and has > to link to libjvm will need to be modified to work with a statically > linked JDK? David, please see my responses in https://github.com/openjdk/jdk/pull/23431#issuecomment-2634531490: JNI functions are already dynamically called. E.g. in the same test here: res = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL); We don't need to change those at all to work on static-jdk. The existing design of JNI functions can work on both dynamic JDK and static JDK. The calls fixed by this PR are the very few exceptions that do not follow the design principle. I do think we should fix them by following the right patterns/conventions. Note LoadJavaVM in JDK code calls these functions 'properly', see jdk/src/java.base/unix/native/libjli/java_md.c. So far I've only found this test in hotspot tier1 and libExplicitAttach (AttachTest_id0) in JDK tier1 with the issue. @dholmes-ora If we don't go with this change, do you have any other suggestions? One other possible alternative that I can think of is using weak symbols, however I think that's no better. and https://github.com/openjdk/jdk/pull/23431#issuecomment-2634595988: Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely exist at runtime. The static JDK case is a good example. Best, Jiangli > > David > ----- > > > ``` > > $ ldd ./build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib/libatExit.so > > linux-vdso.so.1 (0x00007fb80017c000) > > libjvm.so => (snip) > > ... > > /lib64/ld-linux-x86-64.so.2 (0x00007fb80017e000) > > ``` > > > > Runtime linker and loader would resolve and load the dependency > > `libjvm.so` when loading `libatExit.so`. As static-jdk does not > > provide `libjvm.so`, it would fail when running the test using the > > static-jdk. I filed https://bugs.openjdk.org/browse/JDK-8349178. > > > > The good thing is so far testing only has found just a few such cases > > in Tier1 tests. > > > > Best regards, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 5 01:25:51 2025 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Feb 2025 11:25:51 +1000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi Harald, On 31/01/2025 4:17 am, Harald Eilertsen wrote: > Hi, > > I've been contracted by The FreeBSD Foundation to try to improve OpenJDK > support for the FreeBSD operating system. Currently the BSD port lives > in a separate github org over at https://github.com/battleblow, but we'd > like to make porting easier and more streamlined in the future by > submitting our changes to the mainline OpenJDK repo. > > Currently I'm thinking the best approach is to submit small, self > contained patches adressing specific issues when trying to build on > FreeBSD. Both to make reviewing more manageable, but also to get > feedback so that we ensure the changes integrate as smoothly with the > OpenJDK project as possible. > > Will it be best to create a JBS issue for each change, or one issue for > the entire effort? Can you create a PR against mainline so that we can see the scope of the changes and how they have been implemented? That would allow for a technical appraisal of what is involved in supporting FreeBSD. Knowing the technical scope would also aid evaluation of whether this needs to be treated as a full porting project, or whether it can just be accommodated the way we, for example, accommodate the MUSL libc used on Alpine Linux. Is this a re-vamp of the BSD-port project [1] or is this a distinct effort? I think the Porters Group [2] will need to weigh-in on this either way (cc'd). Thanks, David [1] https://openjdk.org/projects/bsd-port/ [2] https://openjdk.org/groups/porters/ > Thanks in advance! > > Harald Eilertsen > -- > Eilertsens Kodeknekkeri > https://kodeknekkeriet.net From christian.s.stein at oracle.com Wed Feb 5 07:28:56 2025 From: christian.s.stein at oracle.com (Christian Stein) Date: Wed, 5 Feb 2025 07:28:56 +0000 Subject: Coming soon: jtreg 7.5.1 Message-ID: JDK folk, This is a general heads-up that jtreg 7.5.1 is ready for use and that we should soon update JDK to use it. The most significant change in jtreg 7.5.1 is the removal of the `LIBRARY.properties` feature. It also contains a few new features and some bug fixes. Find a listing of all noteworthy changes at [1]. The plan is to make jtreg 7.5.1 the default version for JDK 25-ea starting mid February 2025. Thanks to everyone who has helped thus far! [1] https://github.com/openjdk/jtreg/blob/jtreg-7.5.1+1/CHANGELOG.md From thomas.stuefe at gmail.com Wed Feb 5 07:58:14 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Feb 2025 08:58:14 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi Harald, Welcome to the OpenJDK project. I am happy to see BSD getting some love after laying dormant for so many years. Adding to what David wrote: BSD has always been an outlier port because it was tolerated even though there was little commitment from anyone. The work that did happen was in downstream forks of older JDKs. I think that is in part because of a technicality: in hotspot, BSD and MacOS abstraction layer are in the same source files, so BSD flew a bit under the radar. But this is not perfect. Depending on how many changes are needed in that layer, I wonder whether we should split bsd off from a new macos tree and cleanly separate those two. Is your involvement temporary, or will the Foundation continue to fund you? Working on 24 is not perfect; I would work in mainline instead. It should be stable enough to work in it directly. Cheers, Thomas On Wed, Feb 5, 2025 at 2:26?AM David Holmes wrote: > Hi Harald, > > On 31/01/2025 4:17 am, Harald Eilertsen wrote: > > Hi, > > > > I've been contracted by The FreeBSD Foundation to try to improve OpenJDK > > support for the FreeBSD operating system. Currently the BSD port lives > > in a separate github org over at https://github.com/battleblow, but we'd > > like to make porting easier and more streamlined in the future by > > submitting our changes to the mainline OpenJDK repo. > > > > Currently I'm thinking the best approach is to submit small, self > > contained patches adressing specific issues when trying to build on > > FreeBSD. Both to make reviewing more manageable, but also to get > > feedback so that we ensure the changes integrate as smoothly with the > > OpenJDK project as possible. > > > > Will it be best to create a JBS issue for each change, or one issue for > > the entire effort? > > Can you create a PR against mainline so that we can see the scope of the > changes and how they have been implemented? That would allow for a > technical appraisal of what is involved in supporting FreeBSD. > > Knowing the technical scope would also aid evaluation of whether this > needs to be treated as a full porting project, or whether it can just be > accommodated the way we, for example, accommodate the MUSL libc used on > Alpine Linux. Is this a re-vamp of the BSD-port project [1] or is this a > distinct effort? I think the Porters Group [2] will need to weigh-in on > this either way (cc'd). > > Thanks, > David > > [1] https://openjdk.org/projects/bsd-port/ > [2] https://openjdk.org/groups/porters/ > > > > > Thanks in advance! > > > > Harald Eilertsen > > -- > > Eilertsens Kodeknekkeri > > https://kodeknekkeriet.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald+jdklists at volse.no Wed Feb 5 10:33:46 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Wed, 5 Feb 2025 11:33:46 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi David, On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: > > Will it be best to create a JBS issue for each change, or one issue for > > the entire effort? > > Can you create a PR against mainline so that we can see the scope of the > changes and how they have been implemented? Sure, I'll do that. It will take me some time, but I agree it's a good starting point. > Knowing the technical scope would also aid evaluation of whether this needs > to be treated as a full porting project, or whether it can just be > accommodated the way we, for example, accommodate the MUSL libc used on > Alpine Linux. That's actually an interesting perspective. As the current port is using a lot of code from the Linux version (sadly by duplication atm,) but also piggybacks on the MacOS port. Looking forward to see your thoughts on this when I present the code in a PR. > Is this a re-vamp of the BSD-port project [1] or is this a > distinct effort? As I've understood it, the goal is to revitalize the BSD-port, and to keep this as an ongoing effort. Thanks, Harald From harald+jdklists at volse.no Wed Feb 5 10:50:57 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Wed, 5 Feb 2025 11:50:57 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi Thomas, On Wed, Feb 05, 2025 at 08:58:14AM +0100, Thomas St?fe wrote: > Depending on how many changes are needed in that layer, I wonder whether we > should split bsd off from a new macos tree and cleanly separate those two. Yes, I've seen the same suggested in previous private communication as well, and my personal opinion is that this would be a good move. > Is your involvement temporary, or will the Foundation continue to fund you? The FreeBSD Foundation will have to answer that (I've cc'd my contacts there), but my impression is that they are aiming for continued funding for this project. > Working on 24 is not perfect; I agree, it's been a stepping stone to get towards working on the mainline. I've started moving the patches to the mainline now, and will focus on that going forward. Thanks a lot for the feedback so far! Harald From rajan.halade at oracle.com Wed Feb 5 19:27:51 2025 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 5 Feb 2025 19:27:51 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) Message-ID: I hereby nominate Fernando Guallini (fguallini) to JDK Committer. Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. Votes are due by February 19th, 2025, PST. 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]. Rajan Halade (rhalade) [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=fguallini -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorn.vernee at oracle.com Thu Feb 6 12:33:06 2025 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 6 Feb 2025 13:33:06 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <8f953cde-570c-4633-b3ff-d6d71f974862@oracle.com> FWIW, it's possible to compare changes through GitHub without creating a PR, by going to https://github.com///compare/ Here is the diff of battleblow:jdk:bsd-port against openjdk:jdk:master -> https://github.com/openjdk/jdk/compare/master...battleblow:jdk:bsd-port Jorn On 5-2-2025 02:25, David Holmes wrote: > Hi Harald, > > On 31/01/2025 4:17 am, Harald Eilertsen wrote: >> Hi, >> >> I've been contracted by The FreeBSD Foundation to try to improve OpenJDK >> support for the FreeBSD operating system. Currently the BSD port lives >> in a separate github org over at https://github.com/battleblow, but we'd >> like to make porting easier and more streamlined in the future by >> submitting our changes to the mainline OpenJDK repo. >> >> Currently I'm thinking the best approach is to submit small, self >> contained patches adressing specific issues when trying to build on >> FreeBSD. Both to make reviewing more manageable, but also to get >> feedback so that we ensure the changes integrate as smoothly with the >> OpenJDK project as possible. >> >> Will it be best to create a JBS issue for each change, or one issue for >> the entire effort? > > Can you create a PR against mainline so that we can see the scope of > the changes and how they have been implemented? That would allow for a > technical appraisal of what is involved in supporting FreeBSD. > > Knowing the technical scope would also aid evaluation of whether this > needs to be treated as a full porting project, or whether it can just > be accommodated the way we, for example, accommodate the MUSL libc > used on Alpine Linux. Is this a re-vamp of the BSD-port project [1] or > is this a distinct effort? I think the Porters Group [2] will need to > weigh-in on this either way (cc'd). > > Thanks, > David > > [1] https://openjdk.org/projects/bsd-port/ > [2] https://openjdk.org/groups/porters/ > > > >> Thanks in advance! >> >> Harald Eilertsen >> -- >> Eilertsens Kodeknekkeri >> https://kodeknekkeriet.net > From aleksej.efimov at oracle.com Thu Feb 6 12:37:41 2025 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Thu, 6 Feb 2025 12:37:41 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes - Aleksei ________________________________ From: jdk-dev on behalf of Rajan Halade Sent: Wednesday 5 February 2025 7:27 pm To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) I hereby nominate Fernando Guallini (fguallini) to JDK Committer. Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. Votes are due by February 19th, 2025, PST. 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]. Rajan Halade (rhalade) [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=fguallini -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Feb 7 16:28:28 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Feb 2025 11:28:28 -0500 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <2be5ebb2-24fb-4fbc-90b7-5fc589252f53@oracle.com> Vote: yes --Sean On 2/5/25 2:27 PM, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > > Fernando is a member of the Security Libraries team at Oracle and has > contributed 41 changesets [3] in core and security libraries areas as an > author to the OpenJDK repository. > > Votes are due by February 19^th , 2025, PST. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailinglist. > > For Lazy Consensus voting instructions, see [2]. > > Rajan Halade (rhalade) > > [1]https://openjdk.org/census > > [2]https://openjdk.org/projects/#committer-vote projects/#committer-vote> > > [3] https://github.com/openjdk/jdk/commits?author=fguallini github.com/openjdk/jdk/commits?author=fguallini> > From raffaello.giulietti at oracle.com Fri Feb 7 17:34:00 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 7 Feb 2025 18:34:00 +0100 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes On 2025-02-05 20:27, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > > Fernando is a member of the Security Libraries team at Oracle and has > contributed 41 changesets [3] in core and security libraries areas as an > author to the OpenJDK repository. > > Votes are due by February 19^th , 2025, PST. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailinglist. > > For Lazy Consensus voting instructions, see [2]. > > Rajan Halade (rhalade) > > [1]https://openjdk.org/census > > [2]https://openjdk.org/projects/#committer-vote projects/#committer-vote> > > [3] https://github.com/openjdk/jdk/commits?author=fguallini github.com/openjdk/jdk/commits?author=fguallini> > From weijun.wang at oracle.com Fri Feb 7 19:28:54 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 7 Feb 2025 19:28:54 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <42336356-697F-4886-B5E5-4D5E6EB20F38@oracle.com> Yes. ?weijun On Feb 5, 2025, at 14:27, Rajan Halade wrote: I hereby nominate Fernando Guallini (fguallini) to JDK Committer. Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. Votes are due by February 19th, 2025, PST. 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]. Rajan Halade (rhalade) [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=fguallini -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Sat Feb 8 16:33:53 2025 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 8 Feb 2025 08:33:53 -0800 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes --Jamil On 2/5/2025 11:27 AM, Rajan Halade wrote: > > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > > Fernando is a member of the Security Libraries team at Oracle and has > contributed 41 changesets [3] in core and security libraries areas as > an author to the OpenJDK repository. > > Votes are due by February 19^th , 2025, PST. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailinglist. > > For Lazy Consensus voting instructions, see [2]. > > Rajan Halade (rhalade) > > [1]https://openjdk.org/census > > [2]https://openjdk.org/projects/#committer-vote > > > [3] https://github.com/openjdk/jdk/commits?author=fguallini > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Feb 8 22:05:17 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Sat, 8 Feb 2025 22:05:17 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <45BE6DD9-06BD-40DC-97FC-AD2B7E7D2B1F@oracle.com> Vote: yes - weijun > On Feb 7, 2025, at 12:34, Raffaello Giulietti wrote: > > ?Vote: yes > >> On 2025-02-05 20:27, Rajan Halade wrote: >> I hereby nominate Fernando Guallini (fguallini) to JDK Committer. >> Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. >> Votes are due by February 19^th , 2025, PST. >> Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailinglist. >> For Lazy Consensus voting instructions, see [2]. >> Rajan Halade (rhalade) >> [1]https://openjdk.org/census >> [2]https://openjdk.org/projects/#committer-vote >> [3] https://github.com/openjdk/jdk/commits?author=fguallini > From szegedia at gmail.com Sun Feb 9 21:04:24 2025 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 9 Feb 2025 22:04:24 +0100 Subject: Default interface methods aren't considered abstract method implementations Message-ID: Hey folks, I found a somewhat puzzling behavior: default interface methods aren't considered abstract method implementations. Trying to compile this minimal reproducer: ------ C.java ------ abstract class A { abstract void m(); } interface F { default void m() {} } class C extends A implements F {} ------ C.java ------ $ javac C.java C.java:9: error: C is not abstract and does not override abstract method m() in A class C extends A implements F { ^ 1 error I can accept this being valid according to JLS today (I tried with 11, 21, and 23.) I admit this is one of rare occasions when I didn't go scouring the JLS to figure out what exactly prevents the compiler from accepting F.m() as implementation of A.m() in C. I'm wondering though if this isn't something that could be improved upon in the future. (I'm sure there's a gotcha somewhere. Right, Brian? ;-) ) Have a great day, Attila. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Sun Feb 9 22:12:35 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Sun, 9 Feb 2025 22:12:35 +0000 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: You are not specifically asking Brian, are you? If so, sorry for replying. My humble take is that the default method is something to use when there's nothing else there. When there's something, even if it's abstract, we use that. So, a default method is a minimally interfering fallback/extension scenario, if you will. That abstract A.m() effectively replaces default F.m() in C as if F.m() were never there. If F.m() were allowed to provide implementation for A.m() in C, then some uncompliable code could suddenly become compilable and operational at runtime. -Pavel. On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi wrote: > > Hey folks, > > I found a somewhat puzzling behavior: default interface methods aren't considered abstract method implementations. Trying to compile this minimal reproducer: > > ------ C.java ------ > abstract class A { > abstract void m(); > } > > interface F { > default void m() {} > } > > class C extends A implements F {} > ------ C.java ------ > > $ javac C.java > C.java:9: error: C is not abstract and does not override abstract method m() in A > class C extends A implements F { > ^ > 1 error > > I can accept this being valid according to JLS today (I tried with 11, 21, and 23.) I admit this is one of rare occasions when I didn't go scouring the JLS to figure out what exactly prevents the compiler from accepting F.m() as implementation of A.m() in C. I'm wondering though if this isn't something that could be improved upon in the future. (I'm sure there's a gotcha somewhere. Right, Brian? ;-) ) > > Have a great day, > Attila. From pavel.rappo at gmail.com Sun Feb 9 22:26:30 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Sun, 9 Feb 2025 22:26:30 +0000 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: Attila, Come to think of it, we should use some other, more narrowly focused, mailing list. Apologies to subscribers of this list. Since lambda-dev is defunct now, perhaps we could use compiler-dev, amber-dev, or core-libs-dev instead. I'm voting for amber-dev, where Brian mostly resides these days. -Pavel On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo wrote: > > You are not specifically asking Brian, are you? If so, sorry for replying. > > My humble take is that the default method is something to use when > there's nothing else there. When there's something, even if it's > abstract, we use that. So, a default method is a minimally interfering > fallback/extension scenario, if you will. > > That abstract A.m() effectively replaces default F.m() in C as if > F.m() were never there. If F.m() were allowed to provide > implementation for A.m() in C, then some uncompliable code could > suddenly become compilable and operational at runtime. > > -Pavel. > > On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi wrote: > > > > Hey folks, > > > > I found a somewhat puzzling behavior: default interface methods aren't considered abstract method implementations. Trying to compile this minimal reproducer: > > > > ------ C.java ------ > > abstract class A { > > abstract void m(); > > } > > > > interface F { > > default void m() {} > > } > > > > class C extends A implements F {} > > ------ C.java ------ > > > > $ javac C.java > > C.java:9: error: C is not abstract and does not override abstract method m() in A > > class C extends A implements F { > > ^ > > 1 error > > > > I can accept this being valid according to JLS today (I tried with 11, 21, and 23.) I admit this is one of rare occasions when I didn't go scouring the JLS to figure out what exactly prevents the compiler from accepting F.m() as implementation of A.m() in C. I'm wondering though if this isn't something that could be improved upon in the future. (I'm sure there's a gotcha somewhere. Right, Brian? ;-) ) > > > > Have a great day, > > Attila. From david.holmes at oracle.com Mon Feb 10 04:38:21 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Feb 2025 14:38:21 +1000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <8f953cde-570c-4633-b3ff-d6d71f974862@oracle.com> References: <8f953cde-570c-4633-b3ff-d6d71f974862@oracle.com> Message-ID: On 6/02/2025 10:33 pm, Jorn Vernee wrote: > FWIW, it's possible to compare changes through GitHub without creating a > PR, by going to https://github.com///compare/ > > Here is the diff of battleblow:jdk:bsd-port against openjdk:jdk:master - > > https://github.com/openjdk/jdk/compare/master...battleblow:jdk:bsd-port Thanks for that Jorn. An actual PR is more navigable however as it has a file list. :) David > Jorn > > On 5-2-2025 02:25, David Holmes wrote: >> Hi Harald, >> >> On 31/01/2025 4:17 am, Harald Eilertsen wrote: >>> Hi, >>> >>> I've been contracted by The FreeBSD Foundation to try to improve OpenJDK >>> support for the FreeBSD operating system. Currently the BSD port lives >>> in a separate github org over at https://github.com/battleblow, but we'd >>> like to make porting easier and more streamlined in the future by >>> submitting our changes to the mainline OpenJDK repo. >>> >>> Currently I'm thinking the best approach is to submit small, self >>> contained patches adressing specific issues when trying to build on >>> FreeBSD. Both to make reviewing more manageable, but also to get >>> feedback so that we ensure the changes integrate as smoothly with the >>> OpenJDK project as possible. >>> >>> Will it be best to create a JBS issue for each change, or one issue for >>> the entire effort? >> >> Can you create a PR against mainline so that we can see the scope of >> the changes and how they have been implemented? That would allow for a >> technical appraisal of what is involved in supporting FreeBSD. >> >> Knowing the technical scope would also aid evaluation of whether this >> needs to be treated as a full porting project, or whether it can just >> be accommodated the way we, for example, accommodate the MUSL libc >> used on Alpine Linux. Is this a re-vamp of the BSD-port project [1] or >> is this a distinct effort? I think the Porters Group [2] will need to >> weigh-in on this either way (cc'd). >> >> Thanks, >> David >> >> [1] https://openjdk.org/projects/bsd-port/ >> [2] https://openjdk.org/groups/porters/ >> >> >> >>> Thanks in advance! >>> >>> Harald Eilertsen >>> -- >>> Eilertsens Kodeknekkeri >>> https://kodeknekkeriet.net >> From mark.reinhold at oracle.com Mon Feb 10 14:22:39 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 10 Feb 2025 09:22:39 -0500 Subject: JDK 24: First Release Candidate Message-ID: <99658F20-F0EE-4D91-8E12-ACA8C2CD1548@oracle.com> There are no unresolved P1 bugs in build 36, so that is our first JDK 24 Release Candidate. Binaries available here, as usual: https://jdk.java.net/24/ - Mark From roger.riggs at oracle.com Mon Feb 10 14:59:52 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 10 Feb 2025 09:59:52 -0500 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <6b72e68c-3c10-4c38-9340-7c95d7af6643@oracle.com> Vote: Yes On 2/5/25 2:27 PM, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Mon Feb 10 17:36:54 2025 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 10 Feb 2025 17:36:54 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes From: Rajan Halade Date: Wednesday, February 5, 2025 at 11:27?AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) I hereby nominate Fernando Guallini (fguallini) to JDK Committer. Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. Votes are due by February 19th, 2025, PST. 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]. Rajan Halade (rhalade) [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=fguallini -------------- next part -------------- An HTML attachment was scrubbed... URL: From huizhe.wang at oracle.com Mon Feb 10 19:17:58 2025 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 10 Feb 2025 11:17:58 -0800 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <87bbae54-5d08-48ad-a4e8-6b7f1b2a0816@oracle.com> Vote: yes -Joe (joehw) On 2/5/25 11:27 AM, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. From anthony.scarpino at oracle.com Mon Feb 10 19:45:16 2025 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Feb 2025 11:45:16 -0800 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes Tony On 2/5/25 11:27 AM, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > > Fernando is a member of the Security Libraries team at Oracle and has > contributed 41 changesets [3] in core and security libraries areas as an > author to the OpenJDK repository. > > Votes are due by February 19^th , 2025, PST. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailinglist. > > For Lazy Consensus voting instructions, see [2]. > > Rajan Halade (rhalade) > > [1]https://openjdk.org/census > > [2]https://openjdk.org/projects/#committer-vote #committer-vote> > > [3] https://github.com/openjdk/jdk/commits?author=fguallini github.com/openjdk/jdk/commits?author=fguallini> > From jai.forums2013 at gmail.com Tue Feb 11 09:35:37 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 11 Feb 2025 15:05:37 +0530 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <323c1648-d871-4918-8bc8-44c6b3934dc6@gmail.com> vote: yes -Jaikiran On 07/02/25 11:04 pm, Raffaello Giulietti wrote: > Vote: yes > > On 2025-02-05 20:27, Rajan Halade wrote: >> I hereby nominate Fernando Guallini (fguallini) to JDK Committer. >> >> Fernando is a member of the Security Libraries team at Oracle and has >> contributed 41 changesets [3] in core and security libraries areas as >> an author to the OpenJDK repository. >> >> Votes are due by February 19^th , 2025, PST. >> >> Only current JDK Committers [1] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailinglist. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Rajan Halade (rhalade) >> >> [1]https://openjdk.org/census >> >> [2]https://openjdk.org/projects/#committer-vote > projects/#committer-vote> >> >> [3] https://github.com/openjdk/jdk/commits?author=fguallini > github.com/openjdk/jdk/commits?author=fguallini> >> > From daniel.fuchs at oracle.com Tue Feb 11 09:52:29 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Feb 2025 09:52:29 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <7a6458b2-72d2-4f37-a4a0-33e14e70a0a5@oracle.com> Vote: yes best regards, -- daniel On 05/02/2025 19:27, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. From ysr at amazon.com Tue Feb 11 20:51:47 2025 From: ysr at amazon.com (Ramakrishna, Ramki) Date: Tue, 11 Feb 2025 20:51:47 +0000 Subject: New JDK Reviewer: William Kemper In-Reply-To: <8AB8FEAA-6E36-4D8A-B874-53B8C346ED5F@amazon.com> References: <8AB8FEAA-6E36-4D8A-B874-53B8C346ED5F@amazon.com> Message-ID: <473F1F87-45D9-468E-BF8C-687F182955AB@amazon.com> Voting for William Kemper as JDK Reviewer [1] is now closed. Here's the final tally of votes cast: Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. / Ramki Ramakrishna (openjdk: ysr) [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-January/009676.html From ysr at amazon.com Tue Feb 11 20:56:39 2025 From: ysr at amazon.com (Ramakrishna, Ramki) Date: Tue, 11 Feb 2025 20:56:39 +0000 Subject: New JDK Committer: Kelvin Nilsen In-Reply-To: References: Message-ID: Voting for Kelvin Nilsen as JDK Committer [1] is now closed. Here's the final tally of votes cast: Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. / Ramki Ramakrishna (openjdk: ysr) [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-January/009677.html From harald+jdklists at volse.no Thu Feb 13 11:48:57 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Thu, 13 Feb 2025 12:48:57 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: > Hi Harald, > > Can you create a PR against mainline so that we can see the scope of the > changes and how they have been implemented? Here you go: https://github.com/openjdk/jdk/pull/23611 As mentioned in the notes for the PR, this is mainly ment to get your feedback and as a draft to assess the scope, and to be a base for discussing how (and if) to proceed with the port. Looking forward to your thoughts and feedback! Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net From david.holmes at oracle.com Fri Feb 14 04:37:55 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Feb 2025 14:37:55 +1000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> On 13/02/2025 9:48 pm, Harald Eilertsen wrote: > On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: >> Hi Harald, >> >> Can you create a PR against mainline so that we can see the scope of the >> changes and how they have been implemented? > > Here you go: > https://github.com/openjdk/jdk/pull/23611 Thanks for that - much appreciated. I hadn't realized FreeBSD port would cover x86_64, PPC and Aarch64. The PPC support concerns me a little as there may be FreeBSD-specific PPC changes that are needed for PPC systems that are different to what are typically used by the current PPC port. The number of makefile changes needed was surprising ... make me wonder what macOS was doing in some places. The amount of ifdefs is concerning though somewhat understandable. I see a mixed approach to other BSD ports - sometimes there is specific code for them and it has been modified; sometimes the unimplemented not-Apple code has been completely replaced with whatever works for FreeBSD - which shows the other BSD ports are incomplete and can't fully function ... so maybe we should dispense with the illusion that there is some support for them? (just thinking aloud) What is the relationship between __OpenBSD__ , __FreeBSD__ and _ALLBSD_SOURCE? The mixed usage is quite confusing. Overall the amount of changes for hotspot were less than I had expected, but I was surprised by some of them. There may be scope for additional code sharing if we can shuffle things around (the existing ports are far from exemplary - they were largely copy-paste-edit and there is still a slot of cleanup that could be done). David > As mentioned in the notes for the PR, this is mainly ment to get your > feedback and as a draft to assess the scope, and to be a base for > discussing how (and if) to proceed with the port. > > Looking forward to your thoughts and feedback! > > Harald Eilertsen > -- > Eilertsens Kodeknekkeri > https://kodeknekkeriet.net From thomas.stuefe at gmail.com Fri Feb 14 07:31:57 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 14 Feb 2025 08:31:57 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi Harald, In addition to what David wrote: - PPC changes: we already deal with AIX and Linux, and adding BSD is getting a bit #ifdef heavy. I wonder whether we should factor certain things out into (aix|bsd|linux)_ppc.cpp. For example, all of these os/cpu combinations use the same register set, but the ucontext is different for every one of them, so a utility function like `get_gpr_from_context(const ucontext_t* c, int num)` would help. Ultimately, that is up to Martin as ppc lead (I set him on cc). - the bigger issue to me is the amount of large ifdef sections added to os/bsd and bsd/ : I think its time to separate MacOS from BSD and make both first-class OSes. The amount of duplicate coding would be outweighed by clearer code. Up for discussion, of course; that is just my gut feeling right now. Cheers, Thomas On Thu, Feb 13, 2025 at 12:49?PM Harald Eilertsen wrote: > On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: > > Hi Harald, > > > > Can you create a PR against mainline so that we can see the scope of the > > changes and how they have been implemented? > > Here you go: > https://github.com/openjdk/jdk/pull/23611 > > As mentioned in the notes for the PR, this is mainly ment to get your > feedback and as a draft to assess the scope, and to be a base for > discussing how (and if) to proceed with the port. > > Looking forward to your thoughts and feedback! > > Harald Eilertsen > -- > Eilertsens Kodeknekkeri > https://kodeknekkeriet.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald+jdklists at volse.no Fri Feb 14 09:18:02 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Fri, 14 Feb 2025 10:18:02 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> References: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> Message-ID: Hi David, Thanks for your feedback! On Fri, Feb 14, 2025 at 02:37:55PM +1000, David Holmes wrote: > Thanks for that - much appreciated. I hadn't realized FreeBSD port would > cover x86_64, PPC and Aarch64. I'm not sure how important the PPC support is. My main focus is Aarch64 and x86_64. If that makes things easier, I can drop the PPC support for now, and get back to it if there's a need for it later. I also agree with you both on the amount of makefile changes, and the ifdefs. In particular, I think there's room for refactoring to reduce the amount of conditionally compiled code, especially for the larger sections in the mac/bsd sources. The makefile (and autoconf) changes reflect the differences between how the different UNIXes are organized at the file system and library level, but there's also a number of changes that just makes the compiler and linker flags identical for the BSD's and Linux. (A notable difference is how to link with pthread.) > - which shows > the other BSD ports are incomplete and can't fully function ... so maybe we > should dispense with the illusion that there is some support for them? As mentioned, my focus in only on FreeBSD, so I'm fine with dropping the parts that are only relevant for the others for now. It should still make a better foundation for a port to the other BSD's along the same lines as the full BSD port has been maintained up until now. > What is the relationship between __OpenBSD__ , __FreeBSD__ and > _ALLBSD_SOURCE? The mixed usage is quite confusing. It is confusing! _ALLBSD_SOURCE identifies all the BSD platforms _including_ __APPLE__. _BSDONLY_SOURCE identifies all the BSD platforms _except_ __APPLE__. __OpenBSD__, __NetBSD__ and __FreeBSD__ are the system provided defines identifying each specific OS. In addition there's `BSD` that's defined at least in parts of the hotspot code, that I think correspond to _BSDONLY_SOURCE. Personally I'm in favour of dropping the _ALLBSD_SOURCE, and renaming the _BSDONLY_SOURCE to just __BSD__, or even just using the already defined BSD from hotspot. > Overall the amount of changes for hotspot were less than I had expected, but > I was surprised by some of them. There may be scope for additional code > sharing if we can shuffle things around (...) Perhaps that's a place to start? Identify parts that by moving them to a common place would reduce the diff for the FreeBSD port? Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net From harald+jdklists at volse.no Fri Feb 14 10:03:08 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Fri, 14 Feb 2025 11:03:08 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: On Fri, Feb 14, 2025 at 08:31:57AM +0100, Thomas St?fe wrote: > Hi Harald, > > In addition to what David wrote: > > - PPC changes: we already deal with AIX and Linux, and adding BSD is > getting a bit #ifdef heavy. Yeah, as mentioned in the response to David, the PPC support isn't the primary focus anyways. So I think it should be fine to leave that for a later effeort, if at all. > - the bigger issue to me is the amount of large ifdef sections added to > os/bsd and bsd/ : I think its time to separate MacOS from BSD and > make both first-class OSes. I agree with this. Especially the os_bsd files are pretty hard to follow as it is now. One problem is that I don't have an OS X machine for testing that side of changes to this part. Not an unsovable problem, though. Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net From martin.doerr at sap.com Fri Feb 14 11:15:21 2025 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 14 Feb 2025 11:15:21 +0000 Subject: AW: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: Hi Harald and Thomas, > - PPC changes: we already deal with AIX and Linux, and adding BSD is getting a bit #ifdef heavy. I wonder whether we should factor certain things out into (aix|bsd|linux)_ppc.cpp. For example, all of these os/cpu combinations use the same register set, but the ucontext is different for every one of them, so a utility function like `get_gpr_from_context(const ucontext_t* c, int num)` would help. Ultimately, that is up to Martin as ppc lead (I set him on cc). Right, we should think about some refactoring. In addition, I don?t like having to maintain exact copies of some files for AIX/BSD/Linux. I think such changes would be appreciated. One more thing about PPC64: We are planning to remove Power7 support (and older): JDK-8331859 If anybody is willing to keep old processors supported and is also willing to keep testing them, we may discuss that. Best regards, Martin Von: Thomas St?fe Datum: Freitag, 14. Februar 2025 um 08:32 An: Harald Eilertsen Cc: JDK Dev list , porters-dev , David Holmes , Doerr, Martin Betreff: Re: Improving OpenJDK for FreeBSD Hi Harald, In addition to what David wrote: - PPC changes: we already deal with AIX and Linux, and adding BSD is getting a bit #ifdef heavy. I wonder whether we should factor certain things out into (aix|bsd|linux)_ppc.cpp. For example, all of these os/cpu combinations use the same register set, but the ucontext is different for every one of them, so a utility function like `get_gpr_from_context(const ucontext_t* c, int num)` would help. Ultimately, that is up to Martin as ppc lead (I set him on cc). - the bigger issue to me is the amount of large ifdef sections added to os/bsd and bsd/ : I think its time to separate MacOS from BSD and make both first-class OSes. The amount of duplicate coding would be outweighed by clearer code. Up for discussion, of course; that is just my gut feeling right now. Cheers, Thomas On Thu, Feb 13, 2025 at 12:49?PM Harald Eilertsen > wrote: On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: > Hi Harald, > > Can you create a PR against mainline so that we can see the scope of the > changes and how they have been implemented? Here you go: https://github.com/openjdk/jdk/pull/23611 As mentioned in the notes for the PR, this is mainly ment to get your feedback and as a draft to assess the scope, and to be a base for discussing how (and if) to proceed with the port. Looking forward to your thoughts and feedback! Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vieiro at gmail.com Fri Feb 14 12:05:04 2025 From: vieiro at gmail.com (Antonio) Date: Fri, 14 Feb 2025 13:05:04 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> Hi Harald, Talking about testing, even though it may seem premature. Are there any plans to test different JDK versions on FreeBSD on different platforms? Will these tests run in https://ci.freebsd.org/? Maybe the jtreg test reports will be made publicly available in https://ci.freebsd.org/tinderbox/? Also, I've noticed you've already have jtreg working on FreeBSD [1] (for the upcoming jtreg 7.6?). But each JDK version uses different jtreg versions [2]. Are you planning a jtreg port in FreeBSD for these older versions? Thanks and kind regards, Antonio PS: If strictly required I may be able to help with macos/aarch64 testing as time permits. [1] https://github.com/openjdk/jtreg/pull/237 [2] JDK21 is sporting jtreg 7.3.1+1 https://github.com/openjdk/jdk21u-dev/blob/950e655064a75e20540955ad91430c8bea7ae73b/make/conf/github-actions.conf#L29 JDK24 needs jtreg 7.4.+1 https://github.com/openjdk/jdk24u/blob/2397beac67bcf8dccc19dc472b354335dc28cc49/make/conf/github-actions.conf#L29C16-L29C20 El 14/2/25 a las 11:03, Harald Eilertsen escribi?: > On Fri, Feb 14, 2025 at 08:31:57AM +0100, Thomas St?fe wrote: > > I agree with this. Especially the os_bsd files are pretty hard to follow > as it is now. One problem is that I don't have an OS X machine for > testing that side of changes to this part. Not an unsovable problem, > though. > > > Harald Eilertsen > -- > Eilertsens Kodeknekkeri > https://kodeknekkeriet.net From haraldei at anduin.net Fri Feb 14 12:41:00 2025 From: haraldei at anduin.net (Harald Eilertsen) Date: Fri, 14 Feb 2025 13:41:00 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> References: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> Message-ID: <3sxwkonbtw2vtcbzx3e3wmnpz37a4zzepvs4k677ulowpysb63@hrtdwbdkuqse> Hi Antonio, On Fri, Feb 14, 2025 at 01:05:04PM +0100, Antonio wrote: > Talking about testing, even though it may seem premature. Are there any > plans to test different JDK versions on FreeBSD on different platforms? Yes, a part of my work will also be to set up a CI pipeline for the port. I don't know where that will be for now, but it's on the roadmap. I think it's probably about time to start thinking about that now :) > these tests run in https://ci.freebsd.org/? Maybe the jtreg test reports > will be made publicly available in https://ci.freebsd.org/tinderbox/? As said I don't know yet, but that's a likely choice. For the record, here's the jtreg test summary for the PR i made (with one additional change, but nothing substantial): ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 2642 2606 36 0 << jtreg:test/jdk:tier1 2450 2450 0 0 jtreg:test/langtools:tier1 4603 4603 0 0 jtreg:test/jaxp:tier1 0 0 0 0 jtreg:test/lib-test:tier1 35 35 0 0 ============================== TEST FAILURE Not quite there, but better than the existing JDK23u port for FreeBSD. > Also, I've noticed you've already have jtreg working on FreeBSD [1] (for the > upcoming jtreg 7.6?). But each JDK version uses different jtreg versions > [2]. Are you planning a jtreg port in FreeBSD for these older versions? So far I've just used the jtreg main branch to run the jdk tests, so I haven't thought about it. But that's a good point, and I will look into it. > PS: If strictly required I may be able to help with macos/aarch64 testing as > time permits. That would be really helpful! I'll try to manage without, but will let you know if it's needed. Thanks a lot! Harald Eilertsen -- Eilertsens Kodeknekkeri https://kodeknekkeriet.net From brent.christian at oracle.com Fri Feb 14 21:49:48 2025 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 14 Feb 2025 13:49:48 -0800 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <1419bcba-03bd-4f1b-aed6-f87d5747b932@oracle.com> Vote: Yes On 2/5/25 11:27 AM, Rajan Halade wrote: > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > From mbalao at redhat.com Mon Feb 17 20:57:15 2025 From: mbalao at redhat.com (Martin Balao) Date: Mon, 17 Feb 2025 15:57:15 -0500 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet Message-ID: I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. Francisco is an Author in the JDK project [1] and a Senior Software Engineer at Red Hat. Since January 2022, he has made significant contributions to the Security and Vulnerability groups of the OpenJDK project. These contributions include code patch development ?see a full list of authored and co-authored commits to the JDK repository below this email?, doc and spec proposals, security bug analysis and security fix reviews. Votes are due by March 3rd, 2025, 4:00 pm EST. Only current JDK Committers [2] 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 [3]. Thanks, Martin Balao Alonso (mbalao) -- [1] - https://openjdk.org/census#fferrari [2] - https://openjdk.org/census [3] - https://openjdk.org/projects/#committer-vote 1. 8301553: Support Password-Based Cryptography in SunPKCS11 https://github.com/openjdk/jdk/pull/12396 https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 https://github.com/openjdk/jdk/pull/14369 https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) https://github.com/openjdk/jdk/pull/18849 https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 https://github.com/openjdk/jdk/pull/18898 https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 https://github.com/openjdk/jdk/pull/20204 https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad 6. 8319332: Security properties files inclusion https://github.com/openjdk/jdk/pull/16483 https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab 7. 8332644: Improve graph optimizations CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS https://github.com/openjdk/jdk/pull/22461 https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb 9. 8330045: Enhance array handling CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory https://github.com/openjdk/jdk/pull/22215 https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa From alexey at azul.com Tue Feb 18 02:22:36 2025 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 18 Feb 2025 02:22:36 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <34839948-6879-4D6D-852B-32320D5B2E89@azul.com> Vote: yes > On 17 Feb 2025, at 12:57, Martin Balao wrote: > > Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a full > list of authored and co-authored commits to the JDK repository below > this email?, doc and spec proposals, security bug analysis and security > fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > https://github.com/openjdk/jdk/pull/12396 > > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > https://github.com/openjdk/jdk/pull/14369 > > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > https://github.com/openjdk/jdk/pull/18849 > > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > https://github.com/openjdk/jdk/pull/18898 > > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > https://github.com/openjdk/jdk/pull/20204 > > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > 6. 8319332: Security properties files inclusion > https://github.com/openjdk/jdk/pull/16483 > > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > 7. 8332644: Improve graph optimizations > CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > https://github.com/openjdk/jdk/pull/22461 > > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > 9. 8330045: Enhance array handling > CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > https://github.com/openjdk/jdk/pull/22215 > > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From matthias.baesken at sap.com Tue Feb 18 08:23:21 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Feb 2025 08:23:21 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote : yes From adinn at redhat.com Tue Feb 18 09:27:12 2025 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 18 Feb 2025 09:27:12 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: yes On 17/02/2025 20:57, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a full > list of authored and co-authored commits to the JDK repository below > this email?, doc and spec proposals, security bug analysis and security > fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/12396 > > https://github.com/openjdk/jdk/ > commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > ?? 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > ????? https://github.com/openjdk/jdk/pull/14369 > > https://github.com/openjdk/jdk/ > commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > ?? 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > ????? https://github.com/openjdk/jdk/pull/18849 > > https://github.com/openjdk/jdk/ > commit/8a8d9288980513db459f7d6b36554b65844951ca > > ?? 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/18898 > > https://github.com/openjdk/jdk/ > commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > ?? 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/20204 > > https://github.com/openjdk/jdk/ > commit/3251eea1f4289a0505052be204407c02ca38b0ad > > ?? 6. 8319332: Security properties files inclusion > ????? https://github.com/openjdk/jdk/pull/16483 > > https://github.com/openjdk/jdk/commit/ > c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > ?? 7. 8332644: Improve graph optimizations > ????? CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > https://github.com/openjdk/jdk/commit/ > c89f76c0b9ca085192775af9bd9368562b582dd6 > > ?? 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > ????? https://github.com/openjdk/jdk/pull/22461 > > https://github.com/openjdk/jdk/commit/ > a49f0776eb176129f558b6fab3f50e0453f8cbcb > > ?? 9. 8330045: Enhance array handling > ????? CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > https://github.com/openjdk/jdk/ > commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > ? 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > ????? https://github.com/openjdk/jdk/pull/22215 > > https://github.com/openjdk/jdk/ > commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > -- 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 sgehwolf at redhat.com Tue Feb 18 10:04:00 2025 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 18 Feb 2025 11:04:00 +0100 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: yes On Mon, 2025-02-17 at 15:57 -0500, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK > Committer. From neugens.limasoftware at gmail.com Tue Feb 18 10:50:51 2025 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 18 Feb 2025 11:50:51 +0100 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <8EE77C20-DEBE-4CEA-A65D-A8668DF5270B@gmail.com> Vote: Yes Cheers, Mario > On 17. Feb 2025, at 21:57, Martin Balao wrote: > > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software Engineer at Red Hat. Since January 2022, he has made significant contributions to the Security and Vulnerability groups of the OpenJDK project. These contributions include code patch development ?see a full list of authored and co-authored commits to the JDK repository below this email?, doc and spec proposals, security bug analysis and security fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > https://github.com/openjdk/jdk/pull/12396 > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 > https://github.com/openjdk/jdk/pull/14369 > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) > https://github.com/openjdk/jdk/pull/18849 > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > https://github.com/openjdk/jdk/pull/18898 > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > https://github.com/openjdk/jdk/pull/20204 > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > 6. 8319332: Security properties files inclusion > https://github.com/openjdk/jdk/pull/16483 > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > 7. 8332644: Improve graph optimizations > CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > https://github.com/openjdk/jdk/pull/22461 > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > 9. 8330045: Enhance array handling > CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory > https://github.com/openjdk/jdk/pull/22215 > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > From rwestrel at redhat.com Tue Feb 18 15:56:18 2025 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 18 Feb 2025 16:56:18 +0100 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <8734gbgsbh.fsf@redhat.com> Vote: yes Roland. From maurizio.cimadamore at oracle.com Tue Feb 18 17:02:22 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Feb 2025 17:02:22 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: <3dcb9b2f-dd08-495b-ad7e-9755534c9885@oracle.com> Vote: yes Maurizio On 05/02/2025 19:27, Rajan Halade wrote: > > I hereby nominate Fernando Guallini (fguallini) to JDK Committer. > > Fernando is a member of the Security Libraries team at Oracle and has > contributed 41 changesets [3] in core and security libraries areas as > an author to the OpenJDK repository. > > Votes are due by February 19^th , 2025, PST. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailinglist. > > For Lazy Consensus voting instructions, see [2]. > > Rajan Halade (rhalade) > > [1]https://openjdk.org/census > > [2]https://openjdk.org/projects/#committer-vote > > > [3] https://github.com/openjdk/jdk/commits?author=fguallini > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anmol.office123 at gmail.com Wed Feb 19 13:46:23 2025 From: anmol.office123 at gmail.com (anmol soni) Date: Wed, 19 Feb 2025 19:16:23 +0530 Subject: Help : Chat group or channel Enquiry Message-ID: Hi Team Composing to enquire whether we have a chat group or a channel where we can talk to people who have some experience in building jdk. -- Thanks and Regards Anmol Soni +91-8588871486 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.p.donovan at oracle.com Wed Feb 19 14:33:46 2025 From: matthew.p.donovan at oracle.com (Matthew Donovan) Date: Wed, 19 Feb 2025 14:33:46 +0000 Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) In-Reply-To: References: Message-ID: Vote: yes -Matthew From: jdk-dev on behalf of Rajan Halade Date: Wednesday, February 5, 2025 at 2:28?PM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Fernando Guallini (fguallini) I hereby nominate Fernando Guallini (fguallini) to JDK Committer. Fernando is a member of the Security Libraries team at Oracle and has contributed 41 changesets [3] in core and security libraries areas as an author to the OpenJDK repository. Votes are due by February 19th, 2025, PST. 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]. Rajan Halade (rhalade) [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=fguallini -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Feb 19 21:06:34 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2025 21:06:34 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: On 15:57 Mon 17 Feb 2025, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a full > list of authored and co-authored commits to the JDK repository below > this email?, doc and spec proposals, security bug analysis and security > fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > Vote: Yes -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnu.andrew at redhat.com Wed Feb 19 21:13:32 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2025 21:13:32 +0000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: On 08:31 Fri 14 Feb 2025, Thomas St?fe wrote: > > - the bigger issue to me is the amount of large ifdef sections added to > os/bsd and bsd/ : I think its time to separate MacOS from BSD and > make both first-class OSes. The amount of duplicate coding would be > outweighed by clearer code. Up for discussion, of course; that is just my > gut feeling right now. > +1 A cursory glance through the PR suggested to me that there is as much a case for the BSD port sharing a directory with Linux as there is MacOS, given the number of cases I saw where it was added to Linux #ifdefs. All the UNIX-based ports (currently everything bar Windows) are always going to share a degree of overlap, something we recognised on the JDK side when the 'unix' subdirectory was added (most of which still lives under 'solaris' in 8u and earlier). If *BSD is going to be maintained upstream, it should have its own directory distinct from MacOS. Another positive of this is that any *BSD changes then only affect that port and don't risk MacOS breakage. Of course, equally, that does mean the *BSD port will no longer get free updates which apply to MacOS. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From philip.race at oracle.com Wed Feb 19 21:28:43 2025 From: philip.race at oracle.com (Philip Race) Date: Wed, 19 Feb 2025 13:28:43 -0800 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <49d37c46-079c-4f8b-bb0e-60c090a93009@oracle.com> On 2/19/25 1:13 PM, Andrew Hughes wrote: > +1 > > A cursory glance through the PR suggested to me that there is as much > a case for the BSD port sharing a directory with Linux as there is > MacOS, given the number of cases I saw where it was added to Linux > #ifdefs. For the desktop code, this BSD port uses X11 (macOS is its own very different thing for desktop). So even more reason to share with Linux rather than macOS. -phil From raffaello.giulietti at oracle.com Wed Feb 19 22:04:14 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 19 Feb 2025 23:04:14 +0100 Subject: Help : Chat group or channel Enquiry In-Reply-To: References: Message-ID: <79d12054-35b3-45e3-9dac-43b91628a9da@oracle.com> Hi, here's an enumeration of the OpenJDK public mailing lists. https://mail.openjdk.org/mailman/listinfo Perhaps what you are looking for is the build-dev list. On 2025-02-19 14:46, anmol soni wrote: > Hi Team > > Composing to enquire whether we have a chat group or a channel where we > can talk to people who have some experience in building jdk. > > -- > Thanks and Regards > Anmol Soni > +91-8588871486 From gnu.andrew at redhat.com Wed Feb 19 22:27:12 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2025 22:27:12 +0000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <3sxwkonbtw2vtcbzx3e3wmnpz37a4zzepvs4k677ulowpysb63@hrtdwbdkuqse> References: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> <3sxwkonbtw2vtcbzx3e3wmnpz37a4zzepvs4k677ulowpysb63@hrtdwbdkuqse> Message-ID: On 13:41 Fri 14 Feb 2025, Harald Eilertsen wrote: > > For the record, here's the jtreg test summary for the PR i made (with > one additional change, but nothing substantial): > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > >> jtreg:test/hotspot/jtreg:tier1 2642 2606 36 0 > << > jtreg:test/jdk:tier1 2450 2450 0 0 > jtreg:test/langtools:tier1 4603 4603 0 0 > jtreg:test/jaxp:tier1 0 0 0 0 > jtreg:test/lib-test:tier1 35 35 0 0 > ============================== > TEST FAILURE > > Not quite there, but better than the existing JDK23u port for FreeBSD. > These are good results, especially against the moving target of trunk development. It might be worth putting the test changes in a separate PR which can likely go in fairly easily first. It's a shame GitHub Actions doesn't support BSD or each PR could then track these results. > > Also, I've noticed you've already have jtreg working on FreeBSD [1] (for the > > upcoming jtreg 7.6?). But each JDK version uses different jtreg versions > > [2]. Are you planning a jtreg port in FreeBSD for these older versions? > > So far I've just used the jtreg main branch to run the jdk tests, so I > haven't thought about it. But that's a good point, and I will look into > it. > Do you plan to try and backport to the long-term support (LTS) releases? My gut feeling is that this is probably too risky for anything other than the latest LTS (21). On the positive side, this does mean you can look forwards with these changes - like Thomas' suggestion of separating the *BSD and MacOS ports - rather than trying to retain compatibility with older versions. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnu.andrew at redhat.com Wed Feb 19 22:35:44 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2025 22:35:44 +0000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <49d37c46-079c-4f8b-bb0e-60c090a93009@oracle.com> References: <49d37c46-079c-4f8b-bb0e-60c090a93009@oracle.com> Message-ID: On 13:28 Wed 19 Feb 2025, Philip Race wrote: > > > On 2/19/25 1:13 PM, Andrew Hughes wrote: > > +1 > > > > A cursory glance through the PR suggested to me that there is as much > > a case for the BSD port sharing a directory with Linux as there is > > MacOS, given the number of cases I saw where it was added to Linux > > #ifdefs. > > For the desktop code, this BSD port uses X11 (macOS is its own very > different thing for desktop). > So even more reason to share with Linux rather than macOS. > > -phil > Good point. I was looking mainly at the HotSpot code and wondering why it needed to alter code outside the bsd trees, but, yes, on the desktop side, it's going to have more in common with AIX & Linux. I presume there's already a change in there to skip all the Objective C Mac code. I also noticed that, unlike MacOS, it supports building with gcc as well as clang, so this will be the first time some of the code is exposed to that compiler. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From harald+jdklists at volse.no Thu Feb 20 11:20:58 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Thu, 20 Feb 2025 12:20:58 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> <3sxwkonbtw2vtcbzx3e3wmnpz37a4zzepvs4k677ulowpysb63@hrtdwbdkuqse> Message-ID: On Wed, Feb 19, 2025 at 10:27:12PM +0000, Andrew Hughes wrote: > On 13:41 Fri 14 Feb 2025, Harald Eilertsen wrote: > > > > For the record, here's the jtreg test summary for the PR i made (with > > one additional change, but nothing substantial): > > [...snip...] > > It might be worth putting the test changes in a separate PR which can > likely go in fairly easily first. I've been thinking the same. Thanks for confirming that it's a viable approach. > It's a shame GitHub Actions doesn't > support BSD or each PR could then track these results. Yeah, we really would like to see support for FreeBSD in GitHub Actions. > > > Also, I've noticed you've already have jtreg working on FreeBSD [1] (for the > > > upcoming jtreg 7.6?). But each JDK version uses different jtreg versions > > > [2]. Are you planning a jtreg port in FreeBSD for these older versions? > > > > So far I've just used the jtreg main branch to run the jdk tests, so I > > haven't thought about it. But that's a good point, and I will look into > > it. > > Do you plan to try and backport to the long-term support (LTS) > releases? I'm not sure yet, but in any case I doubt I'll go for enything older than jdk21. My focus is on the main jdk branch. Thanks, Harald Eilertsen From magnus.ihse.bursie at oracle.com Thu Feb 20 16:12:11 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Feb 2025 17:12:11 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <9f90bd5a-c263-4279-986c-3da5b3a49563@oracle.com> On 2025-02-19 22:13, Andrew Hughes wrote: > A cursory glance through the PR suggested to me that there is as much > a case for the BSD port sharing a directory with Linux as there is > MacOS, given the number of cases I saw where it was added to Linux > #ifdefs. As Phil commented, this is likely mostly tied to X11. In fact, grouping OSes together as "unix" fits poorly with X11, since macOS is clearly a unix OS in most respects, but it does not use X11. We have a bunch of ugly hacks in the build system to include X11 on the "unix but not macOS" subset. I've been annoyed by it from time to time, but not really come up with any better solution. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Feb 20 16:17:14 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Feb 2025 17:17:14 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: Message-ID: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> Hi Harald (and others), Great to see that you've made it this far! Sorry for the delayed responses, I've been ill for a while and are starting to work through my backlog now. On 2025-02-13 12:48, Harald Eilertsen wrote: > On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: >> Hi Harald, >> >> Can you create a PR against mainline so that we can see the scope of the >> changes and how they have been implemented? > Here you go: > https://github.com/openjdk/jdk/pull/23611 > > As mentioned in the notes for the PR, this is mainly ment to get your > feedback and as a draft to assess the scope, and to be a base for > discussing how (and if) to proceed with the port. This was a good move. When actually integrating any code, a different approach will be needed (for instance, the original writer/copyright holder must be clear for every line of code that should be integrated so we can check OCA acceptance). I do believe that a piecewise integration is much preferable to trying to add everything once. That will however require us to accept that we for a while are going to have a port in the mainline that might not even successfully build, even less work. But I think that is preferable to a big massive integration. That reasoning also indicates that maybe the first parts that should go in is the build system changes that are needed to even try to build the BSD port... /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Feb 20 16:19:33 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Feb 2025 17:19:33 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> References: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> Message-ID: <565217b1-3785-4068-a8fe-296259f76f09@oracle.com> On 2025-02-14 05:37, David Holmes wrote: > The number of makefile changes needed was surprising ... make me > wonder what macOS was doing in some places. Actually, to me it is the other way around. :) If we have good portable source code, there would not have to be many changes to the actual code base to support BSD. The only changes that would be required would be allowing the build system to build on BSD. Thus I'm expecting the majority of the changes to be build related. Then again, maybe some of these changes are due to lack of generalization in the build system, but from the cursory glance I've given the PR so far, it does not look like it. /Magnus From magnus.ihse.bursie at oracle.com Thu Feb 20 16:21:26 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Feb 2025 17:21:26 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> Message-ID: On 2025-02-14 10:18, Harald Eilertsen wrote: > (A notable difference is how to link with pthread.) That is definitely something that should be generalized in the build system. Basically a $(PTHREAD_LIBS) variable, instead of a lot of hard-coded -lpthread. Such a change can be done directly on mainline, to prepare for the BSD port. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Feb 20 16:24:39 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Feb 2025 17:24:39 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <3c2d7e74-993e-4336-8fda-48530a5c9c59@gmail.com> <3sxwkonbtw2vtcbzx3e3wmnpz37a4zzepvs4k677ulowpysb63@hrtdwbdkuqse> Message-ID: On 2025-02-20 12:20, Harald Eilertsen wrote: > On Wed, Feb 19, 2025 at 10:27:12PM +0000, Andrew Hughes wrote: >> It's a shame GitHub Actions doesn't >> support BSD or each PR could then track these results. > Yeah, we really would like to see support for FreeBSD in GitHub Actions. Have you had a look at https://github.com/marketplace/actions/freebsd-vm? While it is perhaps less efficient than a native BSD runner (which GitHub does not offer), it seems easy to use and should probably be possible to add to our GHA scripts without too much of a hassle. /Magnus From aph at redhat.com Thu Feb 20 16:26:59 2025 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Feb 2025 16:26:59 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: yes On 2/17/25 20:57, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a full > list of authored and co-authored commits to the JDK repository below > this email?, doc and spec proposals, security bug analysis and security > fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > https://github.com/openjdk/jdk/pull/12396 > > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > https://github.com/openjdk/jdk/pull/14369 > > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > https://github.com/openjdk/jdk/pull/18849 > > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > https://github.com/openjdk/jdk/pull/18898 > > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > https://github.com/openjdk/jdk/pull/20204 > > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > 6. 8319332: Security properties files inclusion > https://github.com/openjdk/jdk/pull/16483 > > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > 7. 8332644: Improve graph optimizations > CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > https://github.com/openjdk/jdk/pull/22461 > > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > 9. 8330045: Enhance array handling > CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > https://github.com/openjdk/jdk/pull/22215 > > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > -- 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 harald+jdklists at volse.no Thu Feb 20 17:00:25 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Thu, 20 Feb 2025 18:00:25 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <9f90bd5a-c263-4279-986c-3da5b3a49563@oracle.com> References: <9f90bd5a-c263-4279-986c-3da5b3a49563@oracle.com> Message-ID: <5c3yjr63qovikjq2a4qu3rdlzx4dprxn42fqrsm7k3k6t7nmut@bfsejluxp3uw> On Thu, Feb 20, 2025 at 05:12:11PM +0100, Magnus Ihse Bursie wrote: > On 2025-02-19 22:13, Andrew Hughes wrote: > > > A cursory glance through the PR suggested to me that there is as much > > a case for the BSD port sharing a directory with Linux as there is > > MacOS, given the number of cases I saw where it was added to Linux > > #ifdefs. > > As Phil commented, this is likely mostly tied to X11. In fact, grouping OSes > together as "unix" fits poorly with X11, since macOS is clearly a unix OS in > most respects, but it does not use X11. When I looked through this code myself, I was thinking it would perhaps be better to have a HAS_X11 knob or something instead of trying to split by OS. I'm not sure how/if you plan on supporting Wayland, and how this would fit in with that. Harald From harald+jdklists at volse.no Thu Feb 20 17:15:28 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Thu, 20 Feb 2025 18:15:28 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <49d37c46-079c-4f8b-bb0e-60c090a93009@oracle.com> Message-ID: On Wed, Feb 19, 2025 at 10:35:44PM +0000, Andrew Hughes wrote: > I also noticed that, unlike MacOS, it supports building with gcc as > well as clang, Well, at least in theory. I've had some issues when trying to build with gcc, and I'm focusing my attention on the clang build for now. I've managed to get the gcc build to work sometimes, but it has many more issues than the clang build, and don't always even complete. -- Harald From rajan.halade at oracle.com Thu Feb 20 17:52:29 2025 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 20 Feb 2025 17:52:29 +0000 Subject: Result: New JDK Committer: Fernando Guallini (fguallini) Message-ID: Voting for Fernando Guallini (fguallini) [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Rajan Halade [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-February/009720.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From haraldei at anduin.net Thu Feb 20 17:11:02 2025 From: haraldei at anduin.net (Harald Eilertsen) Date: Thu, 20 Feb 2025 18:11:02 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> Message-ID: On Thu, Feb 20, 2025 at 05:17:14PM +0100, Magnus Ihse Bursie wrote: > Hi Harald (and others), > > Great to see that you've made it this far! Sorry for the delayed responses, No worries, I'm still learning a lot :) > I've been ill for a while and are starting to work through my backlog now. Hope you feel better now! > On 2025-02-13 12:48, Harald Eilertsen wrote: > > https://github.com/openjdk/jdk/pull/23611 > > > > As mentioned in the notes for the PR, this is mainly ment to get your > > feedback and as a draft to assess the scope, and to be a base for > > discussing how (and if) to proceed with the port. > > This was a good move. When actually integrating any code, a different > approach will be needed Yes, I am aware, and agree with the reasoning. This was still a useful exercise I think, both for my own part, and to get feedback on the scope and approach of the patches. > That will however require us to accept that we for a while are going to have > a port in the mainline that might not even successfully build, even less > work. I appreciate that. Hopefully I can make it so that it doesn't create too much noise for the rest of the project. Also I will look into the solution you mentioned for integrating with Github Actions. In my experience code that isn't tested regularly breaks easily. Thanks! Harald From david.holmes at oracle.com Fri Feb 21 02:59:03 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Feb 2025 12:59:03 +1000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <565217b1-3785-4068-a8fe-296259f76f09@oracle.com> References: <047fb029-c286-4d5b-b94b-7b01703afa72@oracle.com> <565217b1-3785-4068-a8fe-296259f76f09@oracle.com> Message-ID: <720187d7-6036-4189-b988-7a22eee879a4@oracle.com> On 21/02/2025 2:19 am, Magnus Ihse Bursie wrote: > On 2025-02-14 05:37, David Holmes wrote: > >> The number of makefile changes needed was surprising ... make me >> wonder what macOS was doing in some places. > > Actually, to me it is the other way around. :) If we have good portable > source code, there would not have to be many changes to the actual code > base to support BSD. Well we do have (pretty) good portable source code, but we also have OS specific layers that have to be adapted. As others have noted FreeBSD seems to have more in common with Linux than macOS in many places and that will cause quite a problem in terms of trying to share code. Cheers, David > The only changes that would be required would be > allowing the build system to build on BSD. Thus I'm expecting the > majority of the changes to be build related. Then again, maybe some of > these changes are due to lack of generalization in the build system, but > from the cursory glance I've given the PR so far, it does not look like it. > > /Magnus > > From david.holmes at oracle.com Fri Feb 21 03:03:43 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Feb 2025 13:03:43 +1000 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> Message-ID: On 21/02/2025 2:17 am, Magnus Ihse Bursie wrote: > Hi Harald (and others), > > Great to see that you've made it this far! Sorry for the delayed > responses, I've been ill for a while and are starting to work through my > backlog now. > > On 2025-02-13 12:48, Harald Eilertsen wrote: > >> On Wed, Feb 05, 2025 at 11:25:51AM +1000, David Holmes wrote: >>> Hi Harald, >>> >>> Can you create a PR against mainline so that we can see the scope of the >>> changes and how they have been implemented? >> Here you go: >> https://github.com/openjdk/jdk/pull/23611 >> >> As mentioned in the notes for the PR, this is mainly ment to get your >> feedback and as a draft to assess the scope, and to be a base for >> discussing how (and if) to proceed with the port. > > This was a good move. When actually integrating any code, a different > approach will be needed (for instance, the original writer/copyright > holder must be clear for every line of code that should be integrated so > we can check OCA acceptance). I do believe that a piecewise integration > is much preferable to trying to add everything once. > > That will however require us to accept that we for a while are going to > have a port in the mainline that might not even successfully build, even > less work. But I think that is preferable to a big massive integration. I would not like to see it happen that way. If it is to happen then I would prefer to see a project established and a project repo. This phased approach can be applied to the project repo and supporting changes upstreamed to mainline, then eventually the port itself will be integrated to mainline. Cheers, David > That reasoning also indicates that maybe the first parts that should go > in is the build system changes that are needed to even try to build the > BSD port... > > /Magnus > From sean.mullan at oracle.com Fri Feb 21 16:27:30 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Feb 2025 11:27:30 -0500 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <756683b6-3e9e-499d-a66b-10d70e2684bc@oracle.com> Vote: yes --Sean From jamil.j.nimeh at oracle.com Fri Feb 21 18:39:00 2025 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Feb 2025 10:39:00 -0800 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <473acdc6-920f-4afd-9267-1ef2e226015f@oracle.com> Vote: yes --Jamil On 2/17/2025 12:57 PM, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK > Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a > full list of authored and co-authored commits to the JDK repository > below this email?, doc and spec proposals, security bug analysis and > security fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/12396 > > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > > ?? 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > ????? https://github.com/openjdk/jdk/pull/14369 > > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > > ?? 3. 8330611: AES-CTR vector intrinsic may read out of bounds > (x86_64, AVX-512) > ????? https://github.com/openjdk/jdk/pull/18849 > > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > > ?? 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in > SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/18898 > > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > > ?? 5. 8336499: Failure when creating non-CRT RSA private keys in > SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/20204 > > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > > ?? 6. 8319332: Security properties files inclusion > ????? https://github.com/openjdk/jdk/pull/16483 > > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > > ?? 7. 8332644: Improve graph optimizations > ????? CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > > ?? 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > ????? https://github.com/openjdk/jdk/pull/22461 > > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > > ?? 9. 8330045: Enhance array handling > ????? CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > > ? 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > ????? https://github.com/openjdk/jdk/pull/22215 > > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > From thomas.stuefe at gmail.com Fri Feb 21 18:41:47 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 21 Feb 2025 19:41:47 +0100 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: yes On Mon, Feb 17, 2025 at 9:57?PM Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a full > list of authored and co-authored commits to the JDK repository below > this email?, doc and spec proposals, security bug analysis and security > fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > https://github.com/openjdk/jdk/pull/12396 > > > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > https://github.com/openjdk/jdk/pull/14369 > > > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > https://github.com/openjdk/jdk/pull/18849 > > > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > https://github.com/openjdk/jdk/pull/18898 > > > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > https://github.com/openjdk/jdk/pull/20204 > > > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > 6. 8319332: Security properties files inclusion > https://github.com/openjdk/jdk/pull/16483 > > > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > 7. 8332644: Improve graph optimizations > CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > https://github.com/openjdk/jdk/pull/22461 > > > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > 9. 8330045: Enhance array handling > CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > https://github.com/openjdk/jdk/pull/22215 > > > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Mon Feb 24 15:31:39 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 24 Feb 2025 10:31:39 -0500 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: Yes On 2/17/25 3:57 PM, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK > Committer. From weijun.wang at oracle.com Mon Feb 24 16:30:39 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 24 Feb 2025 16:30:39 +0000 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: <8B277C69-839C-41A0-960F-DCA024CE1C8D@oracle.com> Vote: yes ?Weijun > On Feb 17, 2025, at 15:57, Martin Balao wrote: > > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software Engineer at Red Hat. Since January 2022, he has made significant contributions to the Security and Vulnerability groups of the OpenJDK project. These contributions include code patch development ?see a full list of authored and co-authored commits to the JDK repository below this email?, doc and spec proposals, security bug analysis and security fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > https://github.com/openjdk/jdk/pull/12396 > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 > https://github.com/openjdk/jdk/pull/14369 > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > 3. 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) > https://github.com/openjdk/jdk/pull/18849 > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > https://github.com/openjdk/jdk/pull/18898 > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > 5. 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > https://github.com/openjdk/jdk/pull/20204 > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > 6. 8319332: Security properties files inclusion > https://github.com/openjdk/jdk/pull/16483 > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > 7. 8332644: Improve graph optimizations > CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > https://github.com/openjdk/jdk/pull/22461 > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > 9. 8330045: Enhance array handling > CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory > https://github.com/openjdk/jdk/pull/22215 > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > From sbabneet at ca.ibm.com Mon Feb 24 18:08:57 2025 From: sbabneet at ca.ibm.com (Babneet Singh) Date: Mon, 24 Feb 2025 18:08:57 +0000 Subject: Clarification on javap's -bootclasspath Behavior in JDK 24 Message-ID: One or more of the following files ( object_i.txt ) violates IBM policy and all attachment(s) have been removed from the message. ********************************************************************** Hi, I would like to inquire about changes to javap's -bootclasspath option in JDK 24. In previous versions, -bootclasspath allowed overriding classes in the java.base module. However, I have observed different behavior in JDK 24 when using javap -bootclasspath. I have attached object_i.jar (as object_i.txt; it should be renamed before use), which contains a modified version of the java.lang.Object class with an injected field: private int i. In JDK 23, using -bootclasspath successfully overrides the default java.lang.Object class with this modified version. However, in JDK 24, the override does not occur. The observed behaviour across JDK23 and JDK24 is shown below. Is this new behavior intentional (part of a new feature), or is it a bug? I couldn't find a mailing list specifically for javap. If this is not the appropriate mailing list for this inquiry, I would appreciate guidance on where to direct my question. Regards, Babneet Observed Behavior: ==== JDK 23 and Prior Versions ==== # jdk23/Contents/Home/bin/javap -p -bootclasspath object_i.jar java/lang/Object Compiled from "Object.java" public class java.lang.Object { // Injected field shows up private int i; public java.lang.Object(); protected java.lang.Object clone() throws java.lang.CloneNotSupportedException; public boolean equals(java.lang.Object); protected void finalize() throws java.lang.Throwable; public final native java.lang.Class getClass(); public int hashCode(); public final native void notify(); public final native void notifyAll(); public java.lang.String toString(); public final void wait() throws java.lang.InterruptedException; public final void wait(long) throws java.lang.InterruptedException; public final void wait(long, int) throws java.lang.InterruptedException; private final native void waitImpl(long, int) throws java.lang.InterruptedException; private java.lang.Object newInstancePrototype(java.lang.Class); } ==== JDK 24 ==== # jdk24/Contents/Home/bin/javap -p -bootclasspath object_i.jar java/lang/Object Compiled from "Object.java" public class java.lang.Object { // Injected field doesn't show up public java.lang.Object(); public final native java.lang.Class getClass(); public native int hashCode(); public boolean equals(java.lang.Object); protected native java.lang.Object clone() throws java.lang.CloneNotSupportedException; public java.lang.String toString(); public final native void notify(); public final native void notifyAll(); public final void wait() throws java.lang.InterruptedException; public final void wait(long) throws java.lang.InterruptedException; private final native void wait0(long) throws java.lang.InterruptedException; public final void wait(long, int) throws java.lang.InterruptedException; protected void finalize() throws java.lang.Throwable; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Tue Feb 25 10:16:06 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 25 Feb 2025 15:46:06 +0530 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: vote: yes -Jaikiran On 18/02/25 2:27 am, Martin Balao wrote: > I hereby nominate Francisco Ferrari Bihurriet (fferrari) to JDK > Committer. > > Francisco is an Author in the JDK project [1] and a Senior Software > Engineer at Red Hat. Since January 2022, he has made significant > contributions to the Security and Vulnerability groups of the OpenJDK > project. These contributions include code patch development ?see a > full list of authored and co-authored commits to the JDK repository > below this email?, doc and spec proposals, security bug analysis and > security fix reviews. > > Votes are due by March 3rd, 2025, 4:00 pm EST. > > Only current JDK Committers [2] 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 [3]. > > Thanks, > Martin Balao Alonso (mbalao) > > -- > [1] - https://openjdk.org/census#fferrari > [2] - https://openjdk.org/census > [3] - https://openjdk.org/projects/#committer-vote > > > 1. 8301553: Support Password-Based Cryptography in SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/12396 > > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > > ?? 2. 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java > fails after JDK-8301553 > ????? https://github.com/openjdk/jdk/pull/14369 > > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > > ?? 3. 8330611: AES-CTR vector intrinsic may read out of bounds > (x86_64, AVX-512) > ????? https://github.com/openjdk/jdk/pull/18849 > > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > > ?? 4. 8330842: Support AES CBC with Ciphertext Stealing (CTS) in > SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/18898 > > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > > ?? 5. 8336499: Failure when creating non-CRT RSA private keys in > SunPKCS11 > ????? https://github.com/openjdk/jdk/pull/20204 > > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > > ?? 6. 8319332: Security properties files inclusion > ????? https://github.com/openjdk/jdk/pull/16483 > > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > > ?? 7. 8332644: Improve graph optimizations > ????? CPU 2024-10 (https://github.com/openjdk/jdk/pull/21533) > > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > > ?? 8. 8345221: Replace legacy with new Provider APIs in SunNativeGSS > ????? https://github.com/openjdk/jdk/pull/22461 > > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > > ?? 9. 8330045: Enhance array handling > ????? CPU 2025-01 (https://github.com/openjdk/jdk/pull/23231) > > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > > ? 10. 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support > Generic keys in SunPKCS11 SecretKeyFactory > ????? https://github.com/openjdk/jdk/pull/22215 > > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > From mark.reinhold at oracle.com Wed Feb 26 22:56:55 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 26 Feb 2025 22:56:55 +0000 Subject: New candidate JEP: 503: Remove the 32-bit x86 Port Message-ID: <20250226225654.9C72778B09F@eggemoggin.niobe.net> https://openjdk.org/jeps/503 Summary: Remove the source code and build support for the 32-bit x86 port. This port was deprecated for removal in JDK 24 (JEP 501) with the express intent to remove it in a future release. - Mark From mark.reinhold at oracle.com Fri Feb 28 15:19:17 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 28 Feb 2025 15:19:17 +0000 Subject: JEP proposed to target JDK 25: 502: Stable Values (Preview) Message-ID: <20250228151916.D340478B469@eggemoggin.niobe.net> The following JEP is proposed to target JDK 25: 502: Stable Values (Preview) https://openjdk.org/jeps/502 Summary: Introduce an API for stable values, which are objects that hold immutable data. Stable values are treated as constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, stable values offer greater flexibility as to the timing of their initialization. This is a preview API. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Friday, 7 March, 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 25. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html