From raffaello.giulietti at oracle.com Mon Mar 3 09:34:46 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 3 Mar 2025 10:34:46 +0100 Subject: CFV: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Vote: yes On 2025-02-17 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. > From harald+jdklists at volse.no Wed Mar 5 12:03:01 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Wed, 5 Mar 2025 13:03:01 +0100 Subject: Parameterize pthread and iconv flags Message-ID: <7k6keygfbgde67zitfkysfa7w4cnutw23w3mu4t7f5f5qjlnjh@czxl2jkm7eim> Hi, As suggested by @magicus, I have split out a couple of trivial patches to move the compiler and linker flags for pthread and iconv support to be pupulated by the configure scripts. As any PR needs to have an assigned bug ID, I have tried to submit enhancement requests for these through bugreport.java.com. Not sure how long time that usually takes before it get's published (or I hear anything back,) but if anyone could have a look, the internal ID's are 9078187 (pthread) and 9078196 (iconv). For now, both of these will probably seem entirely unnecessary, but they are needed for the BSD port, and it was suggested to split them out and merge them to prepare for the port. Take care! Harald From mbalao at redhat.com Wed Mar 5 15:58:37 2025 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Mar 2025 10:58:37 -0500 Subject: Result: New JDK Committer: Francisco Ferrari Bihurriet In-Reply-To: References: Message-ID: Voting for Francisco Ferrari Bihurriet (fferrari) [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Martin Balao Alonso (mbalao) -- [1] - https://mail.openjdk.org/pipermail/jdk-dev/2025-February/009750.html From david.holmes at oracle.com Thu Mar 6 04:17:43 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Mar 2025 14:17:43 +1000 Subject: Parameterize pthread and iconv flags In-Reply-To: <7k6keygfbgde67zitfkysfa7w4cnutw23w3mu4t7f5f5qjlnjh@czxl2jkm7eim> References: <7k6keygfbgde67zitfkysfa7w4cnutw23w3mu4t7f5f5qjlnjh@czxl2jkm7eim> Message-ID: Hi Harald, On 5/03/2025 10:03 pm, Harald Eilertsen wrote: > Hi, > > As suggested by @magicus, I have split out a couple of trivial patches > to move the compiler and linker flags for pthread and iconv support to > be pupulated by the configure scripts. > > As any PR needs to have an assigned bug ID, I have tried to submit > enhancement requests for these through bugreport.java.com. Not sure how > long time that usually takes before it get's published (or I hear > anything back,) but if anyone could have a look, the internal ID's are > 9078187 (pthread) and 9078196 (iconv). I have requested these be transferred across to JBS. Cheers, David > For now, both of these will probably seem entirely unnecessary, but they > are needed for the BSD port, and it was suggested to split them out and > merge them to prepare for the port. > > Take care! > Harald From magnus.ihse.bursie at oracle.com Thu Mar 6 16:32:50 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Mar 2025 17:32:50 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> Message-ID: <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> On 2025-02-21 04:03, David Holmes wrote: > 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. So are your suggested course of action to create a new bsd port repo, that starts out identical with mainline, and then integrate PRs into that, with usual review and JBS bug numbers, and when all PRs are in place, we can make a wholesale integration of that repo into mainline? I think that could work as well, but I guess the difficult part will be to get reviewers from the relevant areas. Making PRs to mainline will ensure they get on the potential reviewers radar. I'm afraid that posting PRs on a separate port will just have them end up with a bunch of "Anyone?" posted every week, and if someone do show up to review them, it might not be the right person for the job. But if you think we can solve that, I agree that it is probably a better solution. Also, I don't know if this has been said before, but this work requires a JEP. /Magnus > > 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 harald+jdklists at volse.no Thu Mar 6 18:38:24 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Thu, 6 Mar 2025 19:38:24 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> Message-ID: On Thu, Mar 06, 2025 at 05:32:50PM +0100, Magnus Ihse Bursie wrote: > On 2025-02-21 04:03, David Holmes wrote: > > 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. > > [...snip...] > > I think that could work as well, but I guess the difficult part will be to > get reviewers from the relevant areas. I'm happy to go whichever way the OpenJDK community thinks is the best approach. On advantage I see from our perspective with the separate project repo is that it may be easier to do a bit of experimentation and testing different approaches before a merge into the mainline. It will still be possible to do a phased approach to merging the changes into the mainline, so that should give any reviewers that didn't come around for the first merges into the project repo a second chance to voice their concerns. > Also, I don't know if this has been said before, but this work requires a > JEP. No, I haven't heard anything about that (I think). I'll read up on it, and get back if I need a hand to hold on to :) Take care! Harald From magnus.ihse.bursie at oracle.com Thu Mar 6 19:19:36 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Mar 2025 20:19:36 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> Message-ID: <251c2111-2923-4df0-a371-a61336230060@oracle.com> On 2025-03-06 19:38, Harald Eilertsen wrote: > On Thu, Mar 06, 2025 at 05:32:50PM +0100, Magnus Ihse Bursie wrote: >> On 2025-02-21 04:03, David Holmes wrote: >>> 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. >> [...snip...] >> >> I think that could work as well, but I guess the difficult part will be to >> get reviewers from the relevant areas. > I'm happy to go whichever way the OpenJDK community thinks is the best > approach. On advantage I see from our perspective with the separate > project repo is that it may be easier to do a bit of experimentation and > testing different approaches before a merge into the mainline. > > It will still be possible to do a phased approach to merging the changes > into the mainline, so that should give any reviewers that didn't come > around for the first merges into the project repo a second chance to > voice their concerns. Formally, there is already a bsd-port project ("Port: BSD Project" is the formal name), and according to the Census, Greg Lewis is the Project Lead. That means he has the authority to request that a repo be setup for this project. I hope you have enough contact with him to ask him to send an email to ops at openjdk.org to request such a repo. Since the cogs of the OpenJDK administration moves slowly, I'd suggest trying get him to send such a request already; then the repo might be created in time for it to be actually needed. Formally, I believe it would be good if he also nominates you as member of the bsd-port project. In time, especially if your position at FreeBSD is turning out to be long-term, I think it would be good (and likely supported by Lewis) to have you moving into the Project Lead position of the BSD port project. There is also an old mailing list associated with the project; we might consider moving this discussion over there. (Otoh, the porters-dev list is basically empty so I don't think we're overwhelming everyone by keeping the discussion here as well.) > >> Also, I don't know if this has been said before, but this work requires a >> JEP. > No, I haven't heard anything about that (I think). I'll read up on it, > and get back if I need a hand to hold on to :) Have a look at e.g. JEP 388 (https://openjdk.org/jeps/388) which introduced the Windows/aarch64 port. That was really about combining an existing OS and an existing CPU, but I'd say the amount of changes required is similar to the BSD port, so I guess aiming at a JEP of similar complexity level is fine. /Magnus > > Take care! > Harald From harald+jdklists at volse.no Fri Mar 7 13:36:33 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Fri, 7 Mar 2025 14:36:33 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <251c2111-2923-4df0-a371-a61336230060@oracle.com> References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> <251c2111-2923-4df0-a371-a61336230060@oracle.com> Message-ID: On Thu, Mar 06, 2025 at 08:19:36PM +0100, Magnus Ihse Bursie wrote: > Formally, there is already a bsd-port project ("Port: BSD Project" is the > formal name), and according to the Census, Greg Lewis is the Project Lead. Yep that's right. I've mentioned to him that it would be a good idea to create a project repo, but did not get a response yet. I'll check with him again. > > > Also, I don't know if this has been said before, but this work requires a > > > JEP. > > No, I haven't heard anything about that (I think). I'll read up on it, > > and get back if I need a hand to hold on to :) > > Have a look at e.g. JEP 388 (https://openjdk.org/jeps/388) Thanks! Take care! Harald From thomas.stuefe at gmail.com Fri Mar 7 14:16:01 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 7 Mar 2025 15:16:01 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: <251c2111-2923-4df0-a371-a61336230060@oracle.com> References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> <251c2111-2923-4df0-a371-a61336230060@oracle.com> Message-ID: @Magnus Ihse Bursie Why would we need a JEP? That is a lot of unnecessary red tape. The BSD port already exists. It is technically not a new port. On Thu, Mar 6, 2025 at 8:19?PM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2025-03-06 19:38, Harald Eilertsen wrote: > > > On Thu, Mar 06, 2025 at 05:32:50PM +0100, Magnus Ihse Bursie wrote: > >> On 2025-02-21 04:03, David Holmes wrote: > >>> 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. > >> [...snip...] > >> > >> I think that could work as well, but I guess the difficult part will be > to > >> get reviewers from the relevant areas. > > I'm happy to go whichever way the OpenJDK community thinks is the best > > approach. On advantage I see from our perspective with the separate > > project repo is that it may be easier to do a bit of experimentation and > > testing different approaches before a merge into the mainline. > > > > It will still be possible to do a phased approach to merging the changes > > into the mainline, so that should give any reviewers that didn't come > > around for the first merges into the project repo a second chance to > > voice their concerns. > > Formally, there is already a bsd-port project ("Port: BSD Project" is > the formal name), and according to the Census, Greg Lewis is the Project > Lead. That means he has the authority to request that a repo be setup > for this project. I hope you have enough contact with him to ask him to > send an email to ops at openjdk.org to request such a repo. Since the cogs > of the OpenJDK administration moves slowly, I'd suggest trying get him > to send such a request already; then the repo might be created in time > for it to be actually needed. > > Formally, I believe it would be good if he also nominates you as member > of the bsd-port project. In time, especially if your position at FreeBSD > is turning out to be long-term, I think it would be good (and likely > supported by Lewis) to have you moving into the Project Lead position of > the BSD port project. > > There is also an old mailing list associated with the project; we might > consider moving this discussion over there. (Otoh, the porters-dev list > is basically empty so I don't think we're overwhelming everyone by > keeping the discussion here as well.) > > > > > >> Also, I don't know if this has been said before, but this work requires > a > >> JEP. > > No, I haven't heard anything about that (I think). I'll read up on it, > > and get back if I need a hand to hold on to :) > > Have a look at e.g. JEP 388 (https://openjdk.org/jeps/388) which > introduced the Windows/aarch64 port. That was really about combining an > existing OS and an existing CPU, but I'd say the amount of changes > required is similar to the BSD port, so I guess aiming at a JEP of > similar complexity level is fine. > > /Magnus > > > > > > Take care! > > Harald > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Mar 7 14:30:36 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 7 Mar 2025 15:30:36 +0100 Subject: Improving OpenJDK for FreeBSD In-Reply-To: References: <8bddd709-5747-4bd3-b6d5-dcd4b2e33886@oracle.com> <8bd44fbe-6efd-4e43-9683-e6be2c9458af@oracle.com> <251c2111-2923-4df0-a371-a61336230060@oracle.com> Message-ID: On 2025-03-07 15:16, Thomas St?fe wrote: > @Magnus Ihse Bursie > > Why would we need a JEP? That is a lot of unnecessary red tape. The > BSD port already exists. It is technically not a new port. If we are to include it in the mainline, which is the goal here, a JEP is needed. We have only ever added or removed supported platforms in mainline with a JEP. /Magnus > > On Thu, Mar 6, 2025 at 8:19?PM Magnus Ihse Bursie > wrote: > > On 2025-03-06 19:38, Harald Eilertsen wrote: > > > On Thu, Mar 06, 2025 at 05:32:50PM +0100, Magnus Ihse Bursie wrote: > >> On 2025-02-21 04:03, David Holmes wrote: > >>> 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. > >> [...snip...] > >> > >> I think that could work as well, but I guess the difficult part > will be to > >> get reviewers from the relevant areas. > > I'm happy to go whichever way the OpenJDK community thinks is > the best > > approach. On advantage I see from our perspective with the separate > > project repo is that it may be easier to do a bit of > experimentation and > > testing different approaches before a merge into the mainline. > > > > It will still be possible to do a phased approach to merging the > changes > > into the mainline, so that should give any reviewers that didn't > come > > around for the first merges into the project repo a second chance to > > voice their concerns. > > Formally, there is already a bsd-port project ("Port: BSD Project" is > the formal name), and according to the Census, Greg Lewis is the > Project > Lead. That means he has the authority to request that a repo be setup > for this project. I hope you have enough contact with him to ask > him to > send an email to ops at openjdk.org to request such a repo. Since the > cogs > of the OpenJDK administration moves slowly, I'd suggest trying get > him > to send such a request already; then the repo might be created in > time > for it to be actually needed. > > Formally, I believe it would be good if he also nominates you as > member > of the bsd-port project. In time, especially if your position at > FreeBSD > is turning out to be long-term, I think it would be good (and likely > supported by Lewis) to have you moving into the Project Lead > position of > the BSD port project. > > There is also an old mailing list associated with the project; we > might > consider moving this discussion over there. (Otoh, the porters-dev > list > is basically empty so I don't think we're overwhelming everyone by > keeping the discussion here as well.) > > > > > >> Also, I don't know if this has been said before, but this work > requires a > >> JEP. > > No, I haven't heard anything about that (I think). I'll read up > on it, > > and get back if I need a hand to hold on to :) > > Have a look at e.g. JEP 388 (https://openjdk.org/jeps/388) which > introduced the Windows/aarch64 port. That was really about > combining an > existing OS and an existing CPU, but I'd say the amount of changes > required is similar to the BSD port, so I guess aiming at a JEP of > similar complexity level is fine. > > /Magnus > > > > > > Take care! > > Harald > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald+jdklists at volse.no Fri Mar 7 15:28:09 2025 From: harald+jdklists at volse.no (Harald Eilertsen) Date: Fri, 7 Mar 2025 16:28:09 +0100 Subject: Help analyzing output from COMPARE_BUILD Message-ID: Hi, I've made a small patch to parameterize how support for pthreads is enables in the makefiles. This should not make any difference to existing builds, but running make with COMPARE_BUILD like this: make jdk-image test-image COMPARE_BUILD=PATCH=pthread-diff.patch I get the following results indicating that there are differences in libjvm.so: https://cryptpad.fr/code/#/2/code/view/t1NVNd5bPzuxVBfEgDKSrt2rLazJaFcFFRimYq6h1-0/ I could use some help analyzing this output. The full patch is here: https://cryptpad.fr/code/#/2/code/view/2bB0IOCAyG+RZTUSiUQE3g5skfYr2TE7Vx+XYO5a8wY/ The only difference I can see in the generated configure and makefiles is the added `LIBPTHREAD` variable in spec.gmk. Thanks in adcance, Harald From magnus.ihse.bursie at oracle.com Fri Mar 7 17:35:50 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 7 Mar 2025 18:35:50 +0100 Subject: Help analyzing output from COMPARE_BUILD In-Reply-To: References: Message-ID: <3e33b514-7829-4c21-8d47-8549e23f9c8a@oracle.com> This question belongs on build-dev. I've cc:ed that list, please keep future discussions there and not in jdk-dev. I'll repsond to your question in build-dev. /Magnus On 2025-03-07 16:28, Harald Eilertsen wrote: > Hi, > > I've made a small patch to parameterize how support for pthreads is > enables in the makefiles. This should not make any difference to > existing builds, but running make with COMPARE_BUILD like this: > > make jdk-image test-image COMPARE_BUILD=PATCH=pthread-diff.patch > > I get the following results indicating that there are differences in > libjvm.so: > > https://cryptpad.fr/code/#/2/code/view/t1NVNd5bPzuxVBfEgDKSrt2rLazJaFcFFRimYq6h1-0/ > > I could use some help analyzing this output. > > > The full patch is here: > > https://cryptpad.fr/code/#/2/code/view/2bB0IOCAyG+RZTUSiUQE3g5skfYr2TE7Vx+XYO5a8wY/ > > The only difference I can see in the generated configure and makefiles > is the added `LIBPTHREAD` variable in spec.gmk. > > Thanks in adcance, > Harald From magnus.ihse.bursie at oracle.com Tue Mar 11 10:53:12 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Mar 2025 11:53:12 +0100 Subject: Building/distributing more than one VM in a single JDK distribution Message-ID: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Since time immemorial, the JDK has had the ability to build more than one variant of Hotspot, and let the user select which one to use at runtime. The canonical example was how 32-bit Windows included both "client" and "server", and defaulted to "client". This flexibility comes at a cost, as it creates a lot of complexity in different parts of the JDK -- including, but not limited to, the build system, jlink, and the launcher. Hotspot has support for these variants: server, client, minimal, core and zero. Of these, "core" is apparently an old remnant that I even forgot where it was used (embedded, I think?), and "client" has only been used for 32-bit systems, which are now on their way out. Neither of these are tested regularly in the Oracle CI, or on GHA. That leaves only server, minimal and zero as the remaining relevant variants. These are kept up to date with testing, at least so that they are able to build. However, we do not build *both* server and minimal, or *both* server and zero, neither on GHA or on the Oracle CI. Instead, we *replace* server with either zero or minimal. The point of zero is to have a JVM that can run on hardware that server does not support (or, in the special case of the iOS mobile port -- a platform where JITting code is not allowed). It makes no sense to me to distribute a JDK that includes both the server and the zero variants of Hotspot. If server works, then zero is suboptimal in performance, and not needed. If server does not work, then it need not be included. The point of minimal is to create a JVM with the smallest possible footprint, by excluding functionality. If you distribute the a JDK with both the server and minimal JVM included, you fail doubly: the footprint will be larger, and there will never be any use of minimal, since it is just more limited than server. Hence, I see no need anymore to keep the ability to build more than one variant of Hotspot at the same time. I propose we drop this functionality, which will allow for us to clean up and remove a lot of complexity in several areas of the codebase. (Just to be clear: I do not propose removing zero or minimal, I'm just saying that you need to build *only* the zero or minimal JVM if that is what you want.) Feedback, thoughts? /Magnus From mark.reinhold at oracle.com Tue Mar 11 13:21:57 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 11 Mar 2025 13:21:57 +0000 Subject: JEP proposed to target JDK 25: 502: Stable Values (Preview) In-Reply-To: <20250228151916.D340478B469@eggemoggin.niobe.net> References: <20250228151916.D340478B469@eggemoggin.niobe.net> Message-ID: <20250311092156.195791162@eggemoggin.niobe.net> 2025/2/28 10:19:17 -0500, mark.reinhold at oracle.com: > 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. Hearing no objections, I?ve targeted this JEP to JDK 25. - Mark From mark.reinhold at oracle.com Tue Mar 11 13:29:14 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 11 Mar 2025 13:29:14 +0000 Subject: JEP proposed to target JDK 25: 503: Remove the 32-bit x86 Port Message-ID: <20250311132913.D526879608E@eggemoggin.niobe.net> The following JEP is proposed to target JDK 25: 503: Remove the 32-bit x86 Port 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. 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 Tuesday, 18 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 From matthias.baesken at sap.com Tue Mar 11 16:28:10 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Mar 2025 16:28:10 +0000 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: > Feedback, thoughts? Hi Magnus, we @ SAP do not ship those "more than one VM in a single JDK distribution" so I think the cleanup is fine and no problem for us. Best regards, Matthias From chris.plummer at oracle.com Tue Mar 11 16:53:09 2025 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 11 Mar 2025 09:53:09 -0700 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: <969a781d-ff8e-48aa-b43f-e809be1ada68@oracle.com> I just wanted note that the point of minimal isn't just reduced disk footprint, but also reduced memory footprint (while sacrificing some performance and functionality), so in that regard there could be some use for having both available in the same build. But I don't feel this flexibility is important enough to warrant the increased build complexity, so I'm ok with removing support for it. Chris On 3/11/25 3:53 AM, Magnus Ihse Bursie wrote: > ... > > The point of minimal is to create a JVM with the smallest possible > footprint, by excluding functionality. If you distribute the a JDK > with both the server and minimal JVM included, you fail doubly: the > footprint will be larger, and there will never be any use of minimal, > since it is just more limited than server. > ... From shipilev at amazon.de Tue Mar 11 17:11:11 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Tue, 11 Mar 2025 18:11:11 +0100 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: <33a74919-f3fa-45d8-8c04-7e72ae01a4f0@amazon.de> Hi Magnus, On 11.03.25 11:53, Magnus Ihse Bursie wrote: > Hence, I see no need anymore to keep the ability to build more than one > variant of Hotspot at the same time. I propose we drop this > functionality, which will allow for us to clean up and remove a lot of > complexity in several areas of the codebase. (Just to be clear: I do not > propose removing zero or minimal, I'm just saying that you need to build > *only* the zero or minimal JVM if that is what you want.) > > Feedback, thoughts? For the multi-variant bundle: I vaguely remember Debian folks building the VM that carried both Server and Zero in the same bundle. Matthias Klose showed me some of the scripts and related build errors. I cannot recall the reason for this. For the multi-JVM bundle: Multi-JVM bundles have a place in the world. You can currently frankenstein such a bundle from several JDK builds from the exact same source. The build support for them would be nice, and I would have thought the current multi-variant build support would serve as stepping stone towards it. I have not explored this in current build system at all, though -- so maybe you already know the answer to this from maintainability perspective. "Too hard, keep frankensteining them" is the acceptable answer :) I know two use cases for multi-JVM bundles: 1. Shipping fastdebug JVM along with release JVM in the same bundle. This allows users to quickly select assertions-rich or non-optimized JVM for debugging sessions, with a flip of the command line switch, like -fastdebug / -slowdebug. See for example: https://builds.shipilev.net/openjdk-jdk/ 2. Shipping completely different JVM in the same bundle. I believe this is how Espresso/Truffle does it with -server / -truffle. See: https://www.graalvm.org/latest/reference-manual/espresso/ Thanks, -Aleksey From tanksherman27 at gmail.com Tue Mar 11 17:20:25 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 12 Mar 2025 01:20:25 +0800 Subject: Building/distributing more than one VM in a single JDK distribution Message-ID: That's weird that Debian has both server and zero in the same bundle. From what I recall, Zero is the only VM variant that can only be compiled by itself; It cannot be combined with other VM variants, I'm pretty sure it's mentioned somewhere in the build system best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.petko at canonical.com Tue Mar 11 19:31:22 2025 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Wed, 12 Mar 2025 08:31:22 +1300 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <33a74919-f3fa-45d8-8c04-7e72ae01a4f0@amazon.de> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <33a74919-f3fa-45d8-8c04-7e72ae01a4f0@amazon.de> Message-ID: Hi, > I vaguely remember Debian folks building the VM that carried both Server and Zero in the same bundle. I think the only instance of configuring two vms is i386[1], and since x86 hotspot is being retired, the package only builds zero vm[2]. Server and Zero are built in separate steps[3]. Best Regards, Vladimir. [1] https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/rules?ref_type=heads#L426 [2] https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/rules?ref_type=heads#L63 [3] https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/rules?ref_type=heads#L423 On Wed, Mar 12, 2025 at 6:12?AM Aleksey Shipilev wrote: > > Hi Magnus, > > On 11.03.25 11:53, Magnus Ihse Bursie wrote: > > Hence, I see no need anymore to keep the ability to build more than one > > variant of Hotspot at the same time. I propose we drop this > > functionality, which will allow for us to clean up and remove a lot of > > complexity in several areas of the codebase. (Just to be clear: I do not > > propose removing zero or minimal, I'm just saying that you need to build > > *only* the zero or minimal JVM if that is what you want.) > > > > Feedback, thoughts? > > For the multi-variant bundle: > > I vaguely remember Debian folks building the VM that carried both Server and Zero in the same > bundle. Matthias Klose showed me some of the scripts and related build errors. I cannot recall the > reason for this. > > For the multi-JVM bundle: > > Multi-JVM bundles have a place in the world. You can currently frankenstein such a bundle from > several JDK builds from the exact same source. The build support for them would be nice, and I would > have thought the current multi-variant build support would serve as stepping stone towards it. I > have not explored this in current build system at all, though -- so maybe you already know the > answer to this from maintainability perspective. "Too hard, keep frankensteining them" is the > acceptable answer :) > > I know two use cases for multi-JVM bundles: > > 1. Shipping fastdebug JVM along with release JVM in the same bundle. This allows users to quickly > select assertions-rich or non-optimized JVM for debugging sessions, with a flip of the command line > switch, like -fastdebug / -slowdebug. See for example: https://builds.shipilev.net/openjdk-jdk/ > > 2. Shipping completely different JVM in the same bundle. I believe this is how Espresso/Truffle does > it with -server / -truffle. See: https://www.graalvm.org/latest/reference-manual/espresso/ > > Thanks, > -Aleksey From zjx001202 at gmail.com Wed Mar 12 00:15:15 2025 From: zjx001202 at gmail.com (Glavo) Date: Wed, 12 Mar 2025 08:15:15 +0800 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: Hi, As far as I know, BellSoft LibericaJDK provides both server vm and client vm for 64-bit platforms. > D:\Java\Windows\BellSoft\jdk-23.0.2-full\bin\java.exe -client --version > > openjdk 23.0.2 2025-01-21 > > OpenJDK Runtime Environment (build 23.0.2+9) > > OpenJDK 64-Bit Client VM (build 23.0.2+9, mixed mode, sharing) > > I thought maybe some users were using them. We noticed that for our GUI application, the client VM consumed significantly less memory than the server VM, so we also considered whether we should use client vm as much as possible, until we found that other JDK distributions often do not provide client vm. Glavo On Tue, Mar 11, 2025 at 6:53?PM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Since time immemorial, the JDK has had the ability to build more than > one variant of Hotspot, and let the user select which one to use at > runtime. The canonical example was how 32-bit Windows included both > "client" and "server", and defaulted to "client". > > This flexibility comes at a cost, as it creates a lot of complexity in > different parts of the JDK -- including, but not limited to, the build > system, jlink, and the launcher. > > Hotspot has support for these variants: server, client, minimal, core > and zero. Of these, "core" is apparently an old remnant that I even > forgot where it was used (embedded, I think?), and "client" has only > been used for 32-bit systems, which are now on their way out. Neither of > these are tested regularly in the Oracle CI, or on GHA. > > That leaves only server, minimal and zero as the remaining relevant > variants. These are kept up to date with testing, at least so that they > are able to build. > > However, we do not build *both* server and minimal, or *both* server and > zero, neither on GHA or on the Oracle CI. Instead, we *replace* server > with either zero or minimal. > > The point of zero is to have a JVM that can run on hardware that server > does not support (or, in the special case of the iOS mobile port -- a > platform where JITting code is not allowed). It makes no sense to me to > distribute a JDK that includes both the server and the zero variants of > Hotspot. If server works, then zero is suboptimal in performance, and > not needed. If server does not work, then it need not be included. > > The point of minimal is to create a JVM with the smallest possible > footprint, by excluding functionality. If you distribute the a JDK with > both the server and minimal JVM included, you fail doubly: the footprint > will be larger, and there will never be any use of minimal, since it is > just more limited than server. > > Hence, I see no need anymore to keep the ability to build more than one > variant of Hotspot at the same time. I propose we drop this > functionality, which will allow for us to clean up and remove a lot of > complexity in several areas of the codebase. (Just to be clear: I do not > propose removing zero or minimal, I'm just saying that you need to build > *only* the zero or minimal JVM if that is what you want.) > > Feedback, thoughts? > > /Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Wed Mar 12 00:31:36 2025 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 11 Mar 2025 17:31:36 -0700 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: <931B4B86-5F01-4CAD-A588-936EA9CE0D83@cbfiddle.com> A JDK distribution that provided both x86 and arm for macOS would be useful for building universal applications. It would be particularly good if the class files were shared, as I believe they can be (perhaps with some adjustment). From aleksei.voitylov at bell-sw.com Wed Mar 12 11:52:41 2025 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 12 Mar 2025 16:52:41 +0500 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> Hi Magnus, we at BellSoft still distribute the bundles which include Minimal, Client, and Server VMs alongside standard bundles with Server VM. This allows users to create Runtimes using jpackage with a VM of their choice. The use cases for that are 1. Application developers with simple GUI applications that prefer startup time and disk space offered by Client VM. 2. Embedded systems developers which typically strip down all modules besides java.base and use Minimal VM, but at the same tim often prefer something better performant for some of the more capable devices. 3. Client VM used in containers, with the same grounds as GUI app developers. So I'd argue that there are use cases for having several VMs in one bundle. Creating specialized builds for all these use cases at the distribution level is probably not worth the effort while having a build that includes all and having the users being able to decide what they want is. One other argument from a convenience standpoint of JDK developers is that you only have to build once with all VMs to verify they are buildable, the same goes for CI pipelines. On the other hand, I share your concern for build system complexity. Maybe what could be done is create a build step that will, once several VMs are built from the same codebase sequentially, merge them into one build? This would invovle patching java.base at this last step (which I don't particularly like). But if this is something that will simplify the build process, I'm all for it. That would allow distributions that ship such multi-VM bundles to keep doing so. Another option (less preferrable) is to drag support for building several VMs until 25 is released, as I anticipate that with Leyden startup time of Server VM will be less of an issue. With that, users of cases 1 and 3 will be given the technical option to improve the startup time they care for (but not the disk space). And we'd probably be fine with building the Minimal VM for Embedded world as those typically are specialized distributions. Thanks, -Aleksei On 11.03.2025 15:53, Magnus Ihse Bursie wrote: > Since time immemorial, the JDK has had the ability to build more than > one variant of Hotspot, and let the user select which one to use at > runtime. The canonical example was how 32-bit Windows included both > "client" and "server", and defaulted to "client". > > This flexibility comes at a cost, as it creates a lot of complexity in > different parts of the JDK -- including, but not limited to, the build > system, jlink, and the launcher. > > Hotspot has support for these variants: server, client, minimal, core > and zero. Of these, "core" is apparently an old remnant that I even > forgot where it was used (embedded, I think?), and "client" has only > been used for 32-bit systems, which are now on their way out. Neither > of these are tested regularly in the Oracle CI, or on GHA. > > That leaves only server, minimal and zero as the remaining relevant > variants. These are kept up to date with testing, at least so that > they are able to build. > > However, we do not build *both* server and minimal, or *both* server > and zero, neither on GHA or on the Oracle CI. Instead, we *replace* > server with either zero or minimal. > > The point of zero is to have a JVM that can run on hardware that > server does not support (or, in the special case of the iOS mobile > port -- a platform where JITting code is not allowed). It makes no > sense to me to distribute a JDK that includes both the server and the > zero variants of Hotspot. If server works, then zero is suboptimal in > performance, and not needed. If server does not work, then it need not > be included. > > The point of minimal is to create a JVM with the smallest possible > footprint, by excluding functionality. If you distribute the a JDK > with both the server and minimal JVM included, you fail doubly: the > footprint will be larger, and there will never be any use of minimal, > since it is just more limited than server. > > Hence, I see no need anymore to keep the ability to build more than > one variant of Hotspot at the same time. I propose we drop this > functionality, which will allow for us to clean up and remove a lot of > complexity in several areas of the codebase. (Just to be clear: I do > not propose removing zero or minimal, I'm just saying that you need to > build *only* the zero or minimal JVM if that is what you want.) > > Feedback, thoughts? > > /Magnus > From magnus.ihse.bursie at oracle.com Wed Mar 12 11:53:29 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Mar 2025 12:53:29 +0100 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <931B4B86-5F01-4CAD-A588-936EA9CE0D83@cbfiddle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <931B4B86-5F01-4CAD-A588-936EA9CE0D83@cbfiddle.com> Message-ID: On 2025-03-12 01:31, Alan Snyder wrote: > A JDK distribution that provided both x86 and arm for macOS would be useful for building universal applications. > > It would be particularly good if the class files were shared, as I believe they can be (perhaps with some adjustment). Supporting universal applications on macOS (that is, a single binary combining code for both x64 and aarch64) is a completely different question, and (if possible!) even more hairy than the multi-JVM solution. Having support for multiple JVMs will not in the slightest help any effort to make universal applications on macOS, on the contrary it is only likely to make it more complicated (just as it complicates any other build changes involving hotspot). And, just to be clear, supporting universal applications seems in the JDK seems extremely unlikely to me. Oracle is not spending any effort on doing that, and I don't know about anyone else doing it. I suspect that any attempt to do this would be built as a separate layer on top of the JDK build, where a x64 and an aarch64 builds are combined. But since not even the list of included classes is the same between macOS/x64 and macOS/aarch64, this is definitely a non-trivial amount of work. /Magnus From erik.joelsson at oracle.com Thu Mar 13 13:12:43 2025 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Mar 2025 06:12:43 -0700 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> Message-ID: Hello, I'm not an expert on the differences between server and client, so someone with better knowledge please correct me if I'm wrong, but my impression is that most of the differences in runtime behavior can be simulated using JVM args. In the build system, we use these two for better performance for short lived java processes: -XX:+UseSerialGC -XX:TieredStopAtLevel=1 For the minimal case, there is also the disk footprint issue which we can't really achieve with startup options, but for runtime performance and behavior it should be possible to get most of the way using the right set of options, which should reduce the need for distributing multiple JVMs. /Erik On 3/12/25 4:52 AM, Aleksei Voitylov wrote: > Hi Magnus, > > we at BellSoft still distribute the bundles which include Minimal, > Client, and Server VMs alongside standard bundles with Server VM. This > allows users to create Runtimes using jpackage with a VM of their > choice. The use cases for that are > > 1. Application developers with simple GUI applications that prefer > startup time and disk space offered by Client VM. > 2. Embedded systems developers which typically strip down all modules > besides java.base and use Minimal VM, but at the same tim often prefer > something better performant for some of the more capable devices. > 3. Client VM used in containers, with the same grounds as GUI app > developers. > > So I'd argue that there are use cases for having several VMs in one > bundle. Creating specialized builds for all these use cases at the > distribution level is probably not worth the effort while having a > build that includes all and having the users being able to decide what > they want is. > > One other argument from a convenience standpoint of JDK developers is > that you only have to build once with all VMs to verify they are > buildable, the same goes for CI pipelines. > > On the other hand, I share your concern for build system complexity. > Maybe what could be done is create a build step that will, once > several VMs are built from the same codebase sequentially, merge them > into one build? This would invovle patching java.base at this last > step (which I don't particularly like). But if this is something that > will simplify the build process, I'm all for it. That would allow > distributions that ship such multi-VM bundles to keep doing so. > > Another option (less preferrable) is to drag support for building > several VMs until 25 is released, as I anticipate that with Leyden > startup time of Server VM will be less of an issue. With that, users > of cases 1 and 3 will be given the technical option to improve the > startup time they care for (but not the disk space). And we'd probably > be fine with building the Minimal VM for Embedded world as those > typically are specialized distributions. > > Thanks, > -Aleksei > > On 11.03.2025 15:53, Magnus Ihse Bursie wrote: >> Since time immemorial, the JDK has had the ability to build more than >> one variant of Hotspot, and let the user select which one to use at >> runtime. The canonical example was how 32-bit Windows included both >> "client" and "server", and defaulted to "client". >> >> This flexibility comes at a cost, as it creates a lot of complexity >> in different parts of the JDK -- including, but not limited to, the >> build system, jlink, and the launcher. >> >> Hotspot has support for these variants: server, client, minimal, core >> and zero. Of these, "core" is apparently an old remnant that I even >> forgot where it was used (embedded, I think?), and "client" has only >> been used for 32-bit systems, which are now on their way out. Neither >> of these are tested regularly in the Oracle CI, or on GHA. >> >> That leaves only server, minimal and zero as the remaining relevant >> variants. These are kept up to date with testing, at least so that >> they are able to build. >> >> However, we do not build *both* server and minimal, or *both* server >> and zero, neither on GHA or on the Oracle CI. Instead, we *replace* >> server with either zero or minimal. >> >> The point of zero is to have a JVM that can run on hardware that >> server does not support (or, in the special case of the iOS mobile >> port -- a platform where JITting code is not allowed). It makes no >> sense to me to distribute a JDK that includes both the server and the >> zero variants of Hotspot. If server works, then zero is suboptimal in >> performance, and not needed. If server does not work, then it need >> not be included. >> >> The point of minimal is to create a JVM with the smallest possible >> footprint, by excluding functionality. If you distribute the a JDK >> with both the server and minimal JVM included, you fail doubly: the >> footprint will be larger, and there will never be any use of minimal, >> since it is just more limited than server. >> >> Hence, I see no need anymore to keep the ability to build more than >> one variant of Hotspot at the same time. I propose we drop this >> functionality, which will allow for us to clean up and remove a lot >> of complexity in several areas of the codebase. (Just to be clear: I >> do not propose removing zero or minimal, I'm just saying that you >> need to build *only* the zero or minimal JVM if that is what you want.) >> >> Feedback, thoughts? >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Thu Mar 13 13:20:31 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 14:20:31 +0100 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> Message-ID: Hi all, I hear that there are still relevant use cases to be able to distribute more than JVM and let the user select which one to use -- either directly for debugging purposes (Shipilev's use case), or by selecting which to include in a final jpackage (your use case). On 2025-03-12 12:52, Aleksei Voitylov wrote: > On the other hand, I share your concern for build system complexity. > Maybe what could be done is create a build step that will, once > several VMs are built from the same codebase sequentially, merge them > into one build? This would invovle patching java.base at this last > step (which I don't particularly like). But if this is something that > will simplify the build process, I'm all for it. That would allow > distributions that ship such multi-VM bundles to keep doing so. My thinking is that I should add a new configure option, --with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so, or something like that. That means no patching is needed, and if you want to build a JDK with multiple JVMs, all you need to do is to like: configure --with-conf-name=build-with-zero --with-jvm-variant=zero && make hotspot configure --with-conf-name=build-with-minimal --with-jvm-variant=minimal && make hotspot and then you can do configure --with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so && make jdk-image This would essentially just copy the relevant hotspot libraries in the correct place, and update jvm.cfg. No patching of java.base or such thing would be needed, and the build speed would be essentially unchanged. The only downside is a slight complication for the build scripts, but I think that would be livable. /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 13 13:23:39 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 14:23:39 +0100 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: References: Message-ID: <66f8fa3c-be56-474e-95b8-95914f656bbb@oracle.com> On 2025-03-11 18:20, Julian Waters wrote: > That's weird that Debian has both server and zero in the same bundle. > From what I recall, Zero is the only VM variant that can only be > compiled by itself; It cannot be combined with other VM variants, I'm > pretty sure it's mentioned somewhere in the build system I looked at Debians build script as posted by Vladimir Petko. They essentially do what I propose to do with `--with-import-jvms`; they build zero separately, and then copy it into place and modify jvm.cfg. That also proves that this is indeed a feasible solution. /Magnus From aleksei.voitylov at bell-sw.com Thu Mar 13 14:39:47 2025 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 13 Mar 2025 19:39:47 +0500 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> Message-ID: Hi Magnus, thank you for elaborating on the new possible configure option semantics. We'll be happy to see this as a replacement. -Aleksei On 13.03.2025 18:20, Magnus Ihse Bursie wrote: > Hi all, > > I hear that there are still relevant use cases to be able to > distribute more than JVM and let the user select which one to use -- > either directly for debugging purposes (Shipilev's use case), or by > selecting which to include in a final jpackage (your use case). > > On 2025-03-12 12:52, Aleksei Voitylov wrote: > >> On the other hand, I share your concern for build system complexity. >> Maybe what could be done is create a build step that will, once >> several VMs are built from the same codebase sequentially, merge them >> into one build? This would invovle patching java.base at this last >> step (which I don't particularly like). But if this is something that >> will simplify the build process, I'm all for it. That would allow >> distributions that ship such multi-VM bundles to keep doing so. > > My thinking is that I should add a new configure option, > --with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so, > or something like that. > > That means no patching is needed, and if you want to build a JDK with > multiple JVMs, all you need to do is to like: > > configure --with-conf-name=build-with-zero --with-jvm-variant=zero && > make hotspot > configure --with-conf-name=build-with-minimal > --with-jvm-variant=minimal && make hotspot > > and then you can do > > configure > --with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so > && make jdk-image > > This would essentially just copy the relevant hotspot libraries in the > correct place, and update jvm.cfg. No patching of java.base or such > thing would be needed, and the build speed would be essentially > unchanged. The only downside is a slight complication for the build > scripts, but I think that would be livable. > > /Magnus From aleksei.voitylov at bell-sw.com Thu Mar 13 14:44:51 2025 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 13 Mar 2025 19:44:51 +0500 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> <71fe16fc-42e9-48f9-acbd-5edae0f64bd0@bell-sw.com> Message-ID: <94693930-907f-4781-8882-1fb49290e61f@bell-sw.com> Hi Erik, you are basically right, with the caveat that users want both startup time and disk space savings. I think Magnus found a good solution that will make everyone happy. -Aleksei On 13.03.2025 18:12, Erik Joelsson wrote: > Hello, > > I'm not an expert on the differences between server and client, so > someone with better knowledge please correct me if I'm wrong, but my > impression is that most of the differences in runtime behavior can be > simulated using JVM args. In the build system, we use these two for > better performance for short lived java processes: > > -XX:+UseSerialGC -XX:TieredStopAtLevel=1 > > For the minimal case, there is also the disk footprint issue which we > can't really achieve with startup options, but for runtime performance > and behavior it should be possible to get most of the way using the > right set of options, which should reduce the need for distributing > multiple JVMs. > > /Erik > > On 3/12/25 4:52 AM, Aleksei Voitylov wrote: >> Hi Magnus, >> >> we at BellSoft still distribute the bundles which include Minimal, >> Client, and Server VMs alongside standard bundles with Server VM. >> This allows users to create Runtimes using jpackage with a VM of >> their choice. The use cases for that are >> >> 1. Application developers with simple GUI applications that prefer >> startup time and disk space offered by Client VM. >> 2. Embedded systems developers which typically strip down all modules >> besides java.base and use Minimal VM, but at the same tim often >> prefer something better performant for some of the more capable devices. >> 3. Client VM used in containers, with the same grounds as GUI app >> developers. >> >> So I'd argue that there are use cases for having several VMs in one >> bundle. Creating specialized builds for all these use cases at the >> distribution level is probably not worth the effort while having a >> build that includes all and having the users being able to decide >> what they want is. >> >> One other argument from a convenience standpoint of JDK developers is >> that you only have to build once with all VMs to verify they are >> buildable, the same goes for CI pipelines. >> >> On the other hand, I share your concern for build system complexity. >> Maybe what could be done is create a build step that will, once >> several VMs are built from the same codebase sequentially, merge them >> into one build? This would invovle patching java.base at this last >> step (which I don't particularly like). But if this is something that >> will simplify the build process, I'm all for it. That would allow >> distributions that ship such multi-VM bundles to keep doing so. >> >> Another option (less preferrable) is to drag support for building >> several VMs until 25 is released, as I anticipate that with Leyden >> startup time of Server VM will be less of an issue. With that, users >> of cases 1 and 3 will be given the technical option to improve the >> startup time they care for (but not the disk space). And we'd >> probably be fine with building the Minimal VM for Embedded world as >> those typically are specialized distributions. >> >> Thanks, >> -Aleksei >> >> On 11.03.2025 15:53, Magnus Ihse Bursie wrote: >>> Since time immemorial, the JDK has had the ability to build more >>> than one variant of Hotspot, and let the user select which one to >>> use at runtime. The canonical example was how 32-bit Windows >>> included both "client" and "server", and defaulted to "client". >>> >>> This flexibility comes at a cost, as it creates a lot of complexity >>> in different parts of the JDK -- including, but not limited to, the >>> build system, jlink, and the launcher. >>> >>> Hotspot has support for these variants: server, client, minimal, >>> core and zero. Of these, "core" is apparently an old remnant that I >>> even forgot where it was used (embedded, I think?), and "client" has >>> only been used for 32-bit systems, which are now on their way out. >>> Neither of these are tested regularly in the Oracle CI, or on GHA. >>> >>> That leaves only server, minimal and zero as the remaining relevant >>> variants. These are kept up to date with testing, at least so that >>> they are able to build. >>> >>> However, we do not build *both* server and minimal, or *both* server >>> and zero, neither on GHA or on the Oracle CI. Instead, we *replace* >>> server with either zero or minimal. >>> >>> The point of zero is to have a JVM that can run on hardware that >>> server does not support (or, in the special case of the iOS mobile >>> port -- a platform where JITting code is not allowed). It makes no >>> sense to me to distribute a JDK that includes both the server and >>> the zero variants of Hotspot. If server works, then zero is >>> suboptimal in performance, and not needed. If server does not work, >>> then it need not be included. >>> >>> The point of minimal is to create a JVM with the smallest possible >>> footprint, by excluding functionality. If you distribute the a JDK >>> with both the server and minimal JVM included, you fail doubly: the >>> footprint will be larger, and there will never be any use of >>> minimal, since it is just more limited than server. >>> >>> Hence, I see no need anymore to keep the ability to build more than >>> one variant of Hotspot at the same time. I propose we drop this >>> functionality, which will allow for us to clean up and remove a lot >>> of complexity in several areas of the codebase. (Just to be clear: I >>> do not propose removing zero or minimal, I'm just saying that you >>> need to build *only* the zero or minimal JVM if that is what you want.) >>> >>> Feedback, thoughts? >>> >>> /Magnus >>> From shipilev at amazon.de Fri Mar 14 15:28:38 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Fri, 14 Mar 2025 16:28:38 +0100 Subject: CFV: New JDK Committer: Cesar Soares Lucas Message-ID: I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Fri Mar 14 15:37:20 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Fri, 14 Mar 2025 15:37:20 +0000 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Aleksey Shipilev Sent: Friday, March 14, 2025 4:28 PM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Cesar Soares Lucas I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From shipilev at amazon.de Fri Mar 14 15:44:32 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Fri, 14 Mar 2025 16:44:32 +0100 Subject: CFV: New JDK Committer: Xiaolong Peng Message-ID: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. Xiaolong is a member of Java team in Amazon, working on JVM. In the last 10 months, Xiaolong has contributed 19 mainline changes to improve Hotspot code [2], including significant work in Shenandoah that required deep performance investigations and testing. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#xpeng [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From eastig at amazon.co.uk Fri Mar 14 16:09:52 2025 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Fri, 14 Mar 2025 16:09:52 +0000 Subject: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: <544A710B-9FAF-43FF-AFA4-0F446FCC1F6F@amazon.co.uk> Vote: yes ?On 14/03/2025, 15:46, "jdk-dev on behalf of Aleksey Shipilev" on behalf of shipilev at amazon.de > wrote: I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. Xiaolong is a member of Java team in Amazon, working on JVM. In the last 10 months, Xiaolong has contributed 19 mainline changes to improve Hotspot code [2], including significant work in Shenandoah that required deep performance investigations and testing. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#xpeng [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From eastig at amazon.co.uk Fri Mar 14 16:10:12 2025 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Fri, 14 Mar 2025 16:10:12 +0000 Subject: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <6382980C-B975-4875-9E5D-0D387EA61CD3@amazon.co.uk> Vote: yes ?On 14/03/2025, 15:30, "jdk-dev on behalf of Aleksey Shipilev" on behalf of shipilev at amazon.de > wrote: I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From kemperw at amazon.com Fri Mar 14 16:18:20 2025 From: kemperw at amazon.com (Kemper, William) Date: Fri, 14 Mar 2025 16:18:20 +0000 Subject: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: <75bf93ee32a94e2188d9baf745fcb849@amazon.com> Vote: yes ________________________________ From: jdk-dev on behalf of Aleksey Shipilev Sent: Friday, March 14, 2025 8:44:32 AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Xiaolong Peng I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. Xiaolong is a member of Java team in Amazon, working on JVM. In the last 10 months, Xiaolong has contributed 19 mainline changes to improve Hotspot code [2], including significant work in Shenandoah that required deep performance investigations and testing. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#xpeng [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From kemperw at amazon.com Fri Mar 14 16:18:52 2025 From: kemperw at amazon.com (Kemper, William) Date: Fri, 14 Mar 2025 16:18:52 +0000 Subject: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes ________________________________ From: jdk-dev on behalf of Aleksey Shipilev Sent: Friday, March 14, 2025 8:28:38 AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Cesar Soares Lucas I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Fri Mar 14 16:21:11 2025 From: rkennke at amazon.de (Kennke, Roman) Date: Fri, 14 Mar 2025 16:21:11 +0000 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes > On Mar 14, 2025, at 4:28?PM, Aleksey Shipilev wrote: > > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From hohensee at amazon.com Fri Mar 14 17:07:20 2025 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 14 Mar 2025 17:07:20 +0000 Subject: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: <5E933BB8-CFF9-4E30-9C82-15B154F16D25@amazon.com> Vote: yes ?On 3/14/25, 8:46 AM, "jdk-dev on behalf of Aleksey Shipilev" on behalf of shipilev at amazon.de > wrote: I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. Xiaolong is a member of Java team in Amazon, working on JVM. In the last 10 months, Xiaolong has contributed 19 mainline changes to improve Hotspot code [2], including significant work in Shenandoah that required deep performance investigations and testing. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#xpeng [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From hohensee at amazon.com Fri Mar 14 17:07:50 2025 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 14 Mar 2025 17:07:50 +0000 Subject: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes ?On 3/14/25, 8:30 AM, "jdk-dev on behalf of Aleksey Shipilev" on behalf of shipilev at amazon.de > wrote: I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From thomas.stuefe at gmail.com Fri Mar 14 18:52:34 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 14 Mar 2025 19:52:34 +0100 Subject: CFV: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: Vote: yes On Fri, Mar 14, 2025 at 4:44?PM Aleksey Shipilev wrote: > I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. > > Xiaolong is a member of Java team in Amazon, working on JVM. In the last > 10 months, Xiaolong has > contributed 19 mainline changes to improve Hotspot code [2], including > significant work in > Shenandoah that required deep performance investigations and testing. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#xpeng > [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bylokhov at amazon.com Fri Mar 14 19:05:24 2025 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Fri, 14 Mar 2025 12:05:24 -0700 Subject: CFV: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: <72cd785b-ef37-4bcb-bd48-a4251cdaf452@amazon.com> Vote: yes -- Best regards, Sergey. From vladimir.kozlov at oracle.com Fri Mar 14 19:17:02 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Mar 2025 12:17:02 -0700 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <38402444-ca1a-4006-9a99-c71f0f1637c1@oracle.com> Vote: yes On 3/14/25 8:28 AM, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar > has contributed 30+ mainline changes to improve compiler and GC code > [2], including significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > ??? https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From vladimir.x.ivanov at oracle.com Fri Mar 14 19:18:44 2025 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Mar 2025 12:18:44 -0700 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <26247a5a-f818-4e11-b45f-98e586db3b66@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 3/14/25 08:28, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. From john.r.rose at oracle.com Fri Mar 14 20:17:29 2025 From: john.r.rose at oracle.com (John Rose) Date: Fri, 14 Mar 2025 13:17:29 -0700 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes! From david.holmes at oracle.com Mon Mar 17 05:05:24 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Mar 2025 15:05:24 +1000 Subject: Building/distributing more than one VM in a single JDK distribution In-Reply-To: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> References: <69d7edce-e81a-410e-bd07-b7a7b97ceabd@oracle.com> Message-ID: Apologies for being late to the discussion. > If you distribute the a JDK with both the server and minimal JVM included, you fail doubly Well obviously you wouldn't do that. The idea is that you build a JDK/JRE with all the available VMs in it and then you use another tool (jlink, jpackage?) to prepare your distributable bundles from that. It seems a backward step to me to have to build a JDK/JRE image separately for each VM and then do the final build with --with-import-jvms=xxx to re-package them altogether so that you can then later use jlink/jpackage to split them out again. Also with --with-import-jvms there is the issue of dealing with the generated shared archives (as pointed out by Aleksey elsewhere). So while I understand the desire to simplify the build system, I don't think there is a complete end-to-end story here yet. David ----- On 11/03/2025 8:53 pm, Magnus Ihse Bursie wrote: > Since time immemorial, the JDK has had the ability to build more than > one variant of Hotspot, and let the user select which one to use at > runtime. The canonical example was how 32-bit Windows included both > "client" and "server", and defaulted to "client". > > This flexibility comes at a cost, as it creates a lot of complexity in > different parts of the JDK -- including, but not limited to, the build > system, jlink, and the launcher. > > Hotspot has support for these variants: server, client, minimal, core > and zero. Of these, "core" is apparently an old remnant that I even > forgot where it was used (embedded, I think?), and "client" has only > been used for 32-bit systems, which are now on their way out. Neither of > these are tested regularly in the Oracle CI, or on GHA. > > That leaves only server, minimal and zero as the remaining relevant > variants. These are kept up to date with testing, at least so that they > are able to build. > > However, we do not build *both* server and minimal, or *both* server and > zero, neither on GHA or on the Oracle CI. Instead, we *replace* server > with either zero or minimal. > > The point of zero is to have a JVM that can run on hardware that server > does not support (or, in the special case of the iOS mobile port -- a > platform where JITting code is not allowed). It makes no sense to me to > distribute a JDK that includes both the server and the zero variants of > Hotspot. If server works, then zero is suboptimal in performance, and > not needed. If server does not work, then it need not be included. > > The point of minimal is to create a JVM with the smallest possible > footprint, by excluding functionality. If you distribute the a JDK with > both the server and minimal JVM included, you fail doubly: the footprint > will be larger, and there will never be any use of minimal, since it is > just more limited than server. > > Hence, I see no need anymore to keep the ability to build more than one > variant of Hotspot at the same time. I propose we drop this > functionality, which will allow for us to clean up and remove a lot of > complexity in several areas of the codebase. (Just to be clear: I do not > propose removing zero or minimal, I'm just saying that you need to build > *only* the zero or minimal JVM if that is what you want.) > > Feedback, thoughts? > > /Magnus > From david.holmes at oracle.com Mon Mar 17 05:06:05 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Mar 2025 15:06:05 +1000 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <5b99eeae-b1b7-46af-b688-ecec97765063@oracle.com> Vote yes David On 15/03/2025 1:28 am, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, > Cesar has contributed 30+ mainline changes to improve compiler and GC > code [2], including significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > ??? https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From david.holmes at oracle.com Mon Mar 17 05:06:33 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Mar 2025 15:06:33 +1000 Subject: CFV: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: Vote yes David On 15/03/2025 1:44 am, Aleksey Shipilev wrote: > I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. > > Xiaolong is a member of Java team in Amazon, working on JVM. In the > last 10 months, Xiaolong has contributed 19 mainline changes to > improve Hotspot code [2], including significant work in Shenandoah > that required deep performance investigations and testing. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#xpeng > [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From ysr at amazon.com Mon Mar 17 06:19:00 2025 From: ysr at amazon.com (Ramakrishna, Ramki) Date: Mon, 17 Mar 2025 06:19:00 +0000 Subject: CFV: New JDK Committer: Xiaolong Peng Message-ID: <8BAE1B17-13CB-47C3-86E7-79E0D674A7F5@amazon.com> Vote: yes ?------------------------------------------------------- Date: Fri, 14 Mar 2025 16:44:32 +0100 From: Aleksey Shipilev > To: "jdk-dev at openjdk.org " > Subject: CFV: New JDK Committer: Xiaolong Peng Message-ID: <40405c2a-0f55-413a-bc81-fff53794589a at amazon.de > Content-Type: text/plain; charset="UTF-8"; format=flowed I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. Xiaolong is a member of Java team in Amazon, working on JVM. In the last 10 months, Xiaolong has contributed 19 mainline changes to improve Hotspot code [2], including significant work in Shenandoah that required deep performance investigations and testing. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#xpeng [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From ysr at amazon.com Mon Mar 17 06:19:00 2025 From: ysr at amazon.com (Ramakrishna, Ramki) Date: Mon, 17 Mar 2025 06:19:00 +0000 Subject: CFV: New JDK Committer: Cesar Soares Lucas (was Re: jdk-dev Digest, Vol 90, Issue 11) Message-ID: <40D30926-F871-4986-BEBF-554E708DD7F2@amazon.com> Vote: yes ------------------------------------------------- Date: Fri, 14 Mar 2025 16:28:38 +0100 From: Aleksey Shipilev > To: "jdk-dev at openjdk.org " > Subject: CFV: New JDK Committer: Cesar Soares Lucas Message-ID: > Content-Type: text/plain; charset="UTF-8"; format=flowed I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. Votes are due by March 29, 2025, 23.59 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, -Aleksey [1] https://openjdk.org/census#cslucas [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org https://github.com/openjdk/jdk/commits?author=JohnTortugo [3] https://openjdk.org/census#jdk [4] https://openjdk.org/projects/#committer-vote From tobias.hartmann at oracle.com Mon Mar 17 06:25:42 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 17 Mar 2025 07:25:42 +0100 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <6d8089d6-eab5-45ca-b200-26edfdb99d72@oracle.com> Vote: yes Best regards, Tobias On 3/14/25 16:28, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has contributed 30+ mainline changes to improve compiler and GC code [2], including significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > ??? https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From adinn at redhat.com Mon Mar 17 10:24:19 2025 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Mar 2025 10:24:19 +0000 Subject: CFV: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: Vote: yes On 14/03/2025 15:44, Aleksey Shipilev wrote: > I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. > > Xiaolong is a member of Java team in Amazon, working on JVM. In the last > 10 months, Xiaolong has contributed 19 mainline changes to improve > Hotspot code [2], including significant work in Shenandoah that required > deep performance investigations and testing. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#xpeng > [2] https://github.com/openjdk/jdk/commits?author=xpeng at openjdk.org > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Mon Mar 17 10:24:36 2025 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Mar 2025 10:24:36 +0000 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: Vote: yes On 14/03/2025 15:28, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar > has contributed 30+ mainline changes to improve compiler and GC code > [2], including significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > ??? https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From christian.hagedorn at oracle.com Mon Mar 17 14:55:37 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 17 Mar 2025 15:55:37 +0100 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <85b51f2c-3aa3-41ea-b43d-cf2c9912c4bd@oracle.com> Vote: yes Best regards, Christian On 14.03.25 16:28, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. > > Cesar is a member of Java team in Amazon, working on JVM. So far, Cesar has > contributed 30+ mainline changes to improve compiler and GC code [2], including > significant work in C2 and Shenandoah. > > Votes are due by March 29, 2025, 23.59 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > -Aleksey > > [1] https://openjdk.org/census#cslucas > [2] https://github.com/openjdk/jdk/commits?author=cslucas at openjdk.org > ??? https://github.com/openjdk/jdk/commits?author=JohnTortugo > [3] https://openjdk.org/census#jdk > [4] https://openjdk.org/projects/#committer-vote From roger.riggs at oracle.com Mon Mar 17 15:59:00 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 17 Mar 2025 11:59:00 -0400 Subject: CFV: New JDK Committer: Cesar Soares Lucas In-Reply-To: References: Message-ID: <1a5c943d-44db-4b1f-b9c2-96010fb6429f@oracle.com> Vote: Yes On 3/14/25 11:28 AM, Aleksey Shipilev wrote: > I hereby nominate Cesar Soares Lucas (cslucas) [1] to JDK Committer. From roger.riggs at oracle.com Mon Mar 17 16:00:56 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 17 Mar 2025 12:00:56 -0400 Subject: CFV: New JDK Committer: Xiaolong Peng In-Reply-To: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> References: <40405c2a-0f55-413a-bc81-fff53794589a@amazon.de> Message-ID: <42e6f296-4748-4b87-962c-b7ea0d9dccf9@oracle.com> Vote: Yes On 3/14/25 11:44 AM, Aleksey Shipilev wrote: > I hereby nominate Xiaolong Peng (xpeng) [1] to JDK Committer. From mark.reinhold at oracle.com Tue Mar 18 13:21:10 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 18 Mar 2025 06:21:10 -0700 Subject: Java 24 / JDK 24: General Availability Message-ID: <95DCBF45-44FE-4F1B-AD4F-4C702AADEF7C@oracle.com> JDK 24, the reference implementation of Java 24, is now Generally Available. We shipped build 36 as the initial Release Candidate of JDK 24 on 6 February, and no P1 bugs have been reported since then. Build 36 is therefore now the GA build, ready for production use. GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/24 Builds from other vendors will no doubt be available soon. This release includes 24 JEPs [1]: 404: Generational Shenandoah (Experimental) 450: Compact Object Headers (Experimental) 472: Prepare to Restrict the Use of JNI 475: Late Barrier Expansion for G1 478: Key Derivation Function API (Preview) 479: Remove the Windows 32-bit x86 Port 483: Ahead-of-Time Class Loading & Linking 484: Class-File API 485: Stream Gatherers 486: Permanently Disable the Security Manager 487: Scoped Values (Fourth Preview) 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) 489: Vector API (Ninth Incubator) 490: ZGC: Remove the Non-Generational Mode 491: Synchronize Virtual Threads without Pinning 492: Flexible Constructor Bodies (Third Preview) 493: Linking Run-Time Images without JMODs 494: Module Import Declarations (Second Preview) 495: Simple Source Files and Instance Main Methods (Fourth Preview) 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe 499: Structured Concurrency (Fourth Preview) 501: Deprecate the 32-bit x86 Port for Removal This release also includes, as usual, hundreds of smaller enhancements and thousands of bug fixes. Thank you to everyone who contributed this release, whether by designing and implementing features or enhancements, by fixing bugs, or by downloading and testing the early-access builds! - Mark [1] https://openjdk.org/projects/jdk/24/ From sakyosang at gmail.com Fri Mar 21 06:20:24 2025 From: sakyosang at gmail.com (last last) Date: Fri, 21 Mar 2025 14:20:24 +0800 Subject: Inquiry about PrintDialog Properties button behavior on Linux (JDK-8246742) Message-ID: *Dear OpenJDK Community,* I'm writing regarding an observation about the PrintDialog's Properties button behavior on Linux platforms. On my Ubuntu 20.04 system (OpenJDK version: 17), I noticed that the Properties button in the print dialog remains disabled. Through previous research, I found this is documented in JDK-8246742 ("Disable Properties button in PrintDialog for Unixes and Mac"). The ticket suggests this behavior was intentionally implemented. But from a user perspective, this disabled state raises some concerns: 1. 1.Users familiar with Windows implementation may find this inconsistent 2. 2.Prevents access to printer-specific options that might otherwise be configurable 3. 3.Could be confusing for applications relying on this functionality Reproducer: import java.awt.*; import java.awt.print.*; public class PrintDialogExample implements Printable { public static void main(String[] args) { // ?? PrinterJob ?? PrinterJob printerJob = PrinterJob.getPrinterJob(); // ?????? printerJob.setPrintable(new PrintDialogExample()); // ??????? if (printerJob.printDialog()) { try { // ?????? printerJob.print(); System.out.println("Printing complete."); } catch (PrinterException e) { e.printStackTrace(); } } else { System.out.println("Printing cancelled."); } } @Override public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException { // ?????? if (pageIndex > 0) { return Printable.NO_SUCH_PAGE; } // ? Graphics ????? Graphics2D Graphics2D g2d = (Graphics2D) graphics; // ??????? g2d.setFont(new Font("Serif", Font.PLAIN, 12)); g2d.setColor(Color.BLACK); // ???? String text = "Hello, this is a test print job!"; g2d.drawString(text, 100, 100); // ?????? return Printable.PAGE_EXISTS; } } I'd like to inquire: 1. 1.Is this considered an accepted platform behavior difference? 2. 2.Are there any plans to implement native printer property support for Linux/MacOS? 3. 3.Would there be value in creating a feature request for this capability? Additional environment details: - Desktop Environment: GNOME [3.34.3-0ubuntu1 ] - Default Print System: CUPS [2.3.1-9ubuntu1.4] Thank you for your insights. I'm happy to provide further testing support if needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Mar 21 06:44:21 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2025 16:44:21 +1000 Subject: Inquiry about PrintDialog Properties button behavior on Linux (JDK-8246742) In-Reply-To: References: Message-ID: <26044a5c-317b-4a3d-a954-81de6e0bf21b@oracle.com> Hi, This is probably better directed to the client-libs-dev at openjdk.org mailing list. Regards, David On 21/03/2025 4:20 pm, last last wrote: > *Dear OpenJDK Community,* > > I'm writing regarding an observation about the PrintDialog's Properties > button behavior on Linux platforms. On my Ubuntu 20.04 system (OpenJDK > version: 17), I noticed that the Properties button in the print dialog > remains disabled. > > Through previous research, I found this is documented in JDK-8246742 > ("Disable Properties button in PrintDialog for Unixes and Mac"). The > ticket suggests this behavior was intentionally implemented. > > But from a user perspective, this disabled state raises some concerns: > > 1. 1.Users familiar with Windows implementation may find this inconsistent > 2. 2.Prevents access to printer-specific options that might otherwise > be configurable > 3. 3.Could be confusing for applications relying on this functionality > > Reproducer: > import java.awt.*; > import java.awt.print.*; > > public class PrintDialogExample implements Printable { > > ? ? public static void main(String[] args) { > ? ? ? ? // ?? PrinterJob ?? > ? ? ? ? PrinterJob printerJob = PrinterJob.getPrinterJob(); > > ? ? ? ? // ?????? > ? ? ? ? printerJob.setPrintable(new PrintDialogExample()); > > ? ? ? ? // ??????? > ? ? ? ? if (printerJob.printDialog()) { > ? ? ? ? ? ? try { > ? ? ? ? ? ? ? ? // ?????? > ? ? ? ? ? ? ? ? printerJob.print(); > ? ? ? ? ? ? ? ? System.out.println("Printing complete."); > ? ? ? ? ? ? } catch (PrinterException e) { > ? ? ? ? ? ? ? ? e.printStackTrace(); > ? ? ? ? ? ? } > ? ? ? ? } else { > ? ? ? ? ? ? System.out.println("Printing cancelled."); > ? ? ? ? } > ? ? } > > ? ? @Override > ? ? public int print(Graphics graphics, PageFormat pageFormat, int > pageIndex) throws PrinterException { > ? ? ? ? // ?????? > ? ? ? ? if (pageIndex > 0) { > ? ? ? ? ? ? return Printable.NO_SUCH_PAGE; > ? ? ? ? } > > ? ? ? ? // ? Graphics ????? Graphics2D > ? ? ? ? Graphics2D g2d = (Graphics2D) graphics; > > ? ? ? ? // ??????? > ? ? ? ? g2d.setFont(new Font("Serif", Font.PLAIN, 12)); > ? ? ? ? g2d.setColor(Color.BLACK); > > ? ? ? ? // ???? > ? ? ? ? String text = "Hello, this is a test print job!"; > ? ? ? ? g2d.drawString(text, 100, 100); > > ? ? ? ? // ?????? > ? ? ? ? return Printable.PAGE_EXISTS; > ? ? } > } > > I'd like to inquire: > > 1. 1.Is this considered an accepted platform behavior difference? > 2. 2.Are there any plans to implement native printer property support > for Linux/MacOS? > 3. 3.Would there be value in creating a feature request for this > capability? > > Additional environment details: > > * Desktop Environment: GNOME [3.34.3-0ubuntu1 ] > * Default Print System: CUPS [2.3.1-9ubuntu1.4] > > Thank you for your insights. I'm happy to provide further testing > support if needed. > From jesper.wilhelmsson at oracle.com Fri Mar 21 15:40:22 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 21 Mar 2025 15:40:22 +0000 Subject: Reminder: New link type in JBS In-Reply-To: <0D1DB7AB-EBAB-40D2-8186-9D7FE5477C2E@oracle.com> References: <3960157A-9516-4DF4-846B-A2A48BFB5474@oracle.com> <0D1DB7AB-EBAB-40D2-8186-9D7FE5477C2E@oracle.com> Message-ID: <9920C869-4129-4D1F-9B49-F0FAA14728CF@oracle.com> This is just a friendly reminder that the new caused by/causes link type exists and that it would be good if we could remember to use it when filing issues in JBS. The caused by / causes link is to be used when filing a bug to refer to the issue that caused the bug. Thanks, /Jesper > On 28 Jan 2025, at 13:01, Jesper Wilhelmsson wrote: > > The new link type is now available in JBS. > > /Jesper > >> On 20 Jan 2025, at 18:37, Jesper Wilhelmsson wrote: >> >> Hi jdk-dev, >> >> This is a proposal to add a new link type to JBS, causes/caused by. The link type should be used to identify the cause of a regression, an ability that is currently missing in JBS. >> >> An update to the OpenJDK Developers' Guide [1] that explain the usage of the link type has been posted as well: >> >> causes / caused by - the causes link implies a stronger relationship than relates. If an issue B is filed which can be traced back to the fix for issue A then ?A causes B? (or ?B was caused by A?). >> >> >> Unless there are major concerns I propose to make this addition early next week. Once the link type is in place you will be able to find examples using it with this query: >> >> https://bugs.openjdk.org/issues/?jql=project%20%3D%20JDK%20AND%20issueLinkType%20%3D%20%22caused%20by%22 >> >> Best regards, >> /Jesper >> >> [1] https://github.com/openjdk/guide/pull/139 >> > From zafabar1 at gmail.com Sun Mar 23 20:10:33 2025 From: zafabar1 at gmail.com (DLOzTOR) Date: Sun, 23 Mar 2025 22:10:33 +0200 Subject: Adding an 'init' keyword for initializers in Java Message-ID: I encountered a problem when I mistakenly wrote a method without a name and it was perceived as an initializer, to avoid such cases I want to suggest adding a keyword for declaring initializers. Something like this: class Example { init {} static init {} } -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Mon Mar 24 03:18:00 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 24 Mar 2025 03:18:00 +0000 Subject: Adding an 'init' keyword for initializers in Java In-Reply-To: References: Message-ID: Hi, this mailing list is for general governance of the jdk project of OpenJDK instead for specific proposals for specific areas. >From a Java Language-specific perspective, it seems you are implying to make an instance initializer (JLS 8.6) an error. This seems unrealistic as the Java programming language has not yet removed any language feature. In addition, I don't think this problem is valid: Java programmers know that methods are declared with a return type, a name, and a parameter list. (See JLS 8.4, 9.4) There is no such concept as "a method without a name." I think your better bet is to adopt the habit of writing a method declaration before writing a method body and to turn on IDE inspections (if you have an IDE) to make instance initializers a warning. ________________________________ From: jdk-dev on behalf of DLOzTOR Sent: Sunday, March 23, 2025 3:10 PM To: jdk-dev at openjdk.org Subject: Adding an 'init' keyword for initializers in Java I encountered a problem when I mistakenly wrote a method without a name and it was perceived as an initializer, to avoid such cases I want to suggest adding a keyword for declaring initializers. Something like this: class Example { init {} static init {} } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Mar 24 15:16:45 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 24 Mar 2025 11:16:45 -0400 Subject: Adding an 'init' keyword for initializers in Java In-Reply-To: References: Message-ID: <63f3abb8-b651-4d66-8f12-3c6d99b65187@oracle.com> Chen is correct that this is not the right list for discussion. But, for the record: this suggestion (which has been made before) falls into the category of "fighting the previous war."? While the syntax that you propose is probably better than what was chosen for this originally, "fixing" this is unlikely to actually make things better.? The mistake you made would be no more unlikely, since the old syntax would still be accepted, and worse, there'd now be two ways to say the same thing, which might (a) confuse new users that there might be a difference between the two, or (b) spark value-destroying "style wars" (think: tabs vs spaces) for limited real benefit.? (Taking away the old syntax, however unclear or error-prone it might be (and it is), would break millions of Java programs, and those whose programs we break will not thank us for "making the language better" in this way.) So even if this is a mistake, its one for which fixing it (at the scale of the Java ecosystem) would be more expensive than living with it. On 3/23/2025 4:10 PM, DLOzTOR wrote: > I encountered a problem when I mistakenly wrote a method without a > name and it was perceived as an initializer, to avoid such cases I > want to suggest adding a keyword for declaring initializers. > Something like this: > class Example { > ? ? init {} > ? ? static init {} > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Tue Mar 25 12:28:12 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 25 Mar 2025 12:28:12 +0000 Subject: JEP proposed to target JDK 25: 503: Remove the 32-bit x86 Port In-Reply-To: <20250311132913.D526879608E@eggemoggin.niobe.net> References: <20250311132913.D526879608E@eggemoggin.niobe.net> Message-ID: <20250325082811.509775312@eggemoggin.niobe.net> 2025/3/11 9:29:14 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 25: > > 503: Remove the 32-bit x86 Port > 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. > > 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 Tuesday, 18 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. Hearing no objection, I?ve targeted this JEP to JDK 25. - Mark From p.hayder at altimate.de Fri Mar 28 16:27:34 2025 From: p.hayder at altimate.de (Paul Hayder) Date: Fri, 28 Mar 2025 17:27:34 +0100 Subject: Adding embedded events to awt ApplicationDelegate on MacOS Message-ID: Dear developers, I am currently fixing a bug on the JavaFX side which also affects the JDK (for details: https://bugs.openjdk.org/browse/JDK-8332947). I need to handle openURL events for a MacOS native Java application, while also using the native menu bar from within JavaFX. The main issue is that for opening an URL, I rely on AWT. Now I have the problem when firstly registering the openURL event handler with AWT, JavaFX will run embedded and won?t register the native menu. But if I firstly initialize JavaFX, AWT won?t receive the openURL events as it is running embedded and won?t register the appropriate app delegate. My proposal is to add a notification listener to the Notification Center that listens for events if running embedded (for the implementation: https://github.com/pabulaner/jdk/tree/embedded-event). Those events can be used to forward events not handled by other applications (like JavaFX and openURL) to AWT to handle them on their behalf. This would allow JavaFX to call the AWT openURL method without adding a direct dependency to it and would allow AWT to receive events, even if it runs embedded and only if the application desires it. Please let me know what Your feedback is on that proposal and the concrete implementation. Best Regards Paul Hayder Github: https://github.com/pabulaner -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Mar 28 16:50:54 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Mar 2025 09:50:54 -0700 Subject: Adding embedded events to awt ApplicationDelegate on MacOS In-Reply-To: References: Message-ID: <2c8fd15a-a55f-4e38-ba54-406ba48d2a77@oracle.com> Please direct your question to client-libs-dev at openjfx.org (you can continue discussing the JavaFX part of your question on openjfx-dev at openjdk.org) -- Kevin On 3/28/2025 9:27 AM, Paul Hayder wrote: > Dear developers, > > I am currently fixing a bug on the JavaFX side which also affects the > JDK (for details: https://bugs.openjdk.org/browse/JDK-8332947). > I need to handle openURL events for a MacOS native Java application, > while also using the native menu bar from within JavaFX. > The main issue is that for opening an URL, I rely on AWT. > Now I have the problem when firstly registering the openURL event > handler with AWT, JavaFX will run embedded and won?t register the > native menu. > But if I firstly initialize JavaFX, AWT won?t receive the openURL > events as it is running embedded and won?t register the appropriate > app delegate. > > My proposal is to add a notification listener to the Notification > Center that listens for events if running embedded (for the > implementation: https://github.com/pabulaner/jdk/tree/embedded-event). > Those events can be used to forward events not handled by other > applications (like JavaFX and openURL) to AWT to handle them on their > behalf. > This would allow JavaFX to call the AWT openURL method without adding > a direct dependency to it and would allow AWT to receive events, even > if it runs embedded and only if the application desires it. > > Please let me know what Your feedback is on that proposal and the > concrete implementation. > > Best Regards > Paul Hayder > > Github: https://github.com/pabulaner From kevin.rushforth at oracle.com Fri Mar 28 16:51:38 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Mar 2025 09:51:38 -0700 Subject: Adding embedded events to awt ApplicationDelegate on MacOS In-Reply-To: <2c8fd15a-a55f-4e38-ba54-406ba48d2a77@oracle.com> References: <2c8fd15a-a55f-4e38-ba54-406ba48d2a77@oracle.com> Message-ID: <525a89d7-a4d9-4ae6-afd0-d775fa03b6c5@oracle.com> That should be: client-libs-dev at openjdk.org On 3/28/2025 9:50 AM, Kevin Rushforth wrote: > Please direct your question to client-libs-dev at openjfx.org (you can > continue discussing the JavaFX part of your question on > openjfx-dev at openjdk.org) > > -- Kevin > > > On 3/28/2025 9:27 AM, Paul Hayder wrote: >> Dear developers, >> >> I am currently fixing a bug on the JavaFX side which also affects the >> JDK (for details: https://bugs.openjdk.org/browse/JDK-8332947). >> I need to handle openURL events for a MacOS native Java application, >> while also using the native menu bar from within JavaFX. >> The main issue is that for opening an URL, I rely on AWT. >> Now I have the problem when firstly registering the openURL event >> handler with AWT, JavaFX will run embedded and won?t register the >> native menu. >> But if I firstly initialize JavaFX, AWT won?t receive the openURL >> events as it is running embedded and won?t register the appropriate >> app delegate. >> >> My proposal is to add a notification listener to the Notification >> Center that listens for events if running embedded (for the >> implementation: https://github.com/pabulaner/jdk/tree/embedded-event). >> Those events can be used to forward events not handled by other >> applications (like JavaFX and openURL) to AWT to handle them on their >> behalf. >> This would allow JavaFX to call the AWT openURL method without adding >> a direct dependency to it and would allow AWT to receive events, even >> if it runs embedded and only if the application desires it. >> >> Please let me know what Your feedback is on that proposal and the >> concrete implementation. >> >> Best Regards >> Paul Hayder >> >> Github: https://github.com/pabulaner > From eirbjo at gmail.com Sat Mar 29 06:28:56 2025 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sat, 29 Mar 2025 07:28:56 +0100 Subject: Reducing "unrelated" requests to jdk-dev Message-ID: Hi, A good chunk of messages on this list are from newly signed up, non-author/committers posting questions/feature requests which then needs fielding to more appropriate lists. While there is nothing particularly harmful to this situation, it does introduce a bit of overhead for the poster, for the people doing the fielding and for all other subscribers to the list. Could something be done to help people find a more appropriate list before posting? The Mailman about page [1] initial paragraph is very inclusive, seems to invite any "technical" question and says nothing about process-related communications, like voting for new committers/reviewers. This list is for the discussion of general technical issues related to the > development of the current JDK main-line feature release. The second sentence is helpful, but maybe not super clear: Please use a more narrowly-focused list (e.g., core-libs-dev or > hotspot-dev) if appropriate. Maybe some tweaks to these sentences could make it more clear what this list is about and how to find a better list to ask questions. Thoughts? Eirik. [1] https://mail.openjdk.org/mailman/listinfo/jdk-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: