From jai.forums2013 at gmail.com Mon Jun 2 09:30:44 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 2 Jun 2025 15:00:44 +0530 Subject: =?UTF-8?Q?Result=3A_New_JDK_Committer=3A_Volkan_Yaz=C4=B1c=C4=B1?= Message-ID: Voting for Volkan Yaz?c? [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010083.html -Jaikiran From magnus.ihse.bursie at oracle.com Wed Jun 4 07:03:56 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 09:03:56 +0200 Subject: Anyone still using CommentChecker and DirDiff? Message-ID: Hi, There are two tools in src/utils/src/build/tools, CommentChecker.java and DirDiff.java. As far as I am aware, these are abandoned and could be removed. I propose to do this in JDK-8358543. If anyone is still using any of these tools, now is the time to say so. /Magnus From mark.reinhold at oracle.com Wed Jun 4 17:37:19 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 4 Jun 2025 17:37:19 +0000 Subject: JEP proposed to target JDK 25: 509: JFR CPU-Time Profiling (Experimental) In-Reply-To: <20250528162247.7CB628174E4@eggemoggin.niobe.net> References: <20250528162247.7CB628174E4@eggemoggin.niobe.net> Message-ID: <20250604133717.999000045@eggemoggin.niobe.net> 2025/5/28 12:22:48 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 25: > > 509: JFR CPU-Time Profiling (Experimental) > https://openjdk.org/jeps/509 > > Summary: Enhance the JDK Flight Recorder (JFR) to capture CPU-time > profiling information on Linux. This is an experimental feature. > > 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 17:00 UTC on Wednesday, 4 June, 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 alexey.ivanov at oracle.com Wed Jun 4 18:03:19 2025 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 4 Jun 2025 19:03:19 +0100 Subject: CFV: New JDK Committer: Daniel Gredler (dgredler) In-Reply-To: References: Message-ID: Vote: yes On 26/05/2025 21:38, Philip Race wrote: > I hereby nominate: Daniel Gredler (dgredler) [1] to JDK Committer. -- Alexey From 333alaamo at gmail.com Wed Jun 4 20:46:42 2025 From: 333alaamo at gmail.com (Alaa Mohamed) Date: Wed, 4 Jun 2025 23:46:42 +0300 Subject: "Scoped Mutable Variables" In-Reply-To: References: Message-ID: Thank you for your feedback. On Thu, 22 May 2025, 6:57 pm Chen Liang, wrote: > Hello, I don't think this proposal "reduce unintended side effects caused > by variable mutations in nested blocks". This massively decreases the > readability of code. Your purposed problem can be solved by declaring new > non-final local variables in the nested scopes and making the main local > variable final, and there is no proof that your proposed problem actually > happens in development. You can search for Static Single-Assignment form > for more efficient usages of variables that is both more human and machine > friendly. Also on a side note, Java Language feature discussions usually > happen on compiler-dev list. > > Regards, Chen Liang > ------------------------------ > *From:* jdk-dev on behalf of Alaa Mohamed < > 333alaamo at gmail.com> > *Sent:* Wednesday, May 21, 2025 8:54 PM > *To:* jdk-dev at openjdk.java.net > *Subject:* "Scoped Mutable Variables" > > > Dear OpenJDK Reviewers and Community, > > I hope this message finds you well. > > Please find attached my draft Java Enhancement Proposal (JEP) titled > "Scoped Mutable Variables" (JEP XXXX), which introduces a new variable > declaration modifier scoped. This modifier allows variables to be mutable > exclusively within a limited lexical scope (such as inside if, for, or > while blocks) without affecting the variable?s value in the enclosing or > global scope. > > This proposal aims to reduce unintended side effects caused by variable > mutations in nested blocks, thereby improving code safety and readability > in large-scale Java projects. > > I would appreciate any feedback or suggestions you may have on the design, > naming, integration approach, or any other aspect of the proposal. > > Please find the full proposal text attached (or below). > > Thank you very much for your time and consideration. > > Best regards, > Alaa Mohamed > [Your email] > [ GitHub - alaa-333/scoped-variable-jep > ] > > [ LinkedIn : > https://www.linkedin.com/in/alaa-mohamed-1468a3304?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BOH8SwytOQoO2HCH0VxvdBA%3D%3D > ] > Also for more details : Java Enhancement Proposal (JEP) (1).pdf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu Jun 5 14:30:32 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 5 Jun 2025 16:30:32 +0200 Subject: =?UTF-8?Q?Result=3A_New_JDK_Committer=3A_Manuel_H=C3=A4ssig?= Message-ID: <5ac2d992-18a3-48b1-982a-c3afb9d464f6@oracle.com> Voting [1] for Manuel H?ssig [2] is now closed. Yes: 19 Veto: 0 Abstain: 0 According to the bylaw's definition of Lazy Consensus [3], this is sufficient to approve the nomination. Thanks, Tobias [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010136.html [2] https://openjdk.org/census#mhaessig [3] https://openjdk.org/bylaws#lazy-consensus From mark.reinhold at oracle.com Thu Jun 5 17:20:51 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 5 Jun 2025 17:20:51 +0000 Subject: JDK 25 is now in Rampdown Phase One Message-ID: <20250605172049.C8E94818632@eggemoggin.niobe.net> Per the JDK 25 schedule [1], we are now in Rampdown Phase One. The overall feature set [2] is frozen. No further JEPs will be targeted to this release. We?ve branched the main line of development, in the master branch, to create the jdk25 stabilization branch: https://github.com/openjdk/jdk/tree/jdk25 Any changes pushed to the master branch are now bound for JDK 26, as noted previously [3]. Since the repository contains multiple active branches, Reviewers and Committers should carefully verify the target branch of every pull request. The stabilization branch is open for select bug fixes and, with approval, late enhancements per JEP 3, the JDK Release Process [4]. If you?re responsible for any of the bugs on the RDP 1 candidate-bug list [5] then please see JEP 3 for guidance on how to handle them. We will integrate most stabilization changes via backports, as we have since JDK 22 [6]: - Most fixes and enhancements intended for the stabilization branch will also be applicable to the main line, in the master branch. Integrate such a change into the master branch first. Then, after you obtain any required approvals, backport it to the stabilization branch using the Skara `/backport` command [7] or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash. (The Developers? Guide has guidance on working with branches [8] and backports [9].) - Some fixes will be specific to the stabilization branch and not applicable to the main line. Integrate such fixes directly into the stabilization branch. In order to make sure that no backports are missed, prior to the RDP 2 and RC phases we will remind JDK Contributors to review changes that have been integrated into the main line but not backported to the stabilization branch. These JBS queries can be useful: - Changes not backported from the main line https://bugs.openjdk.org/issues/?filter=44264 - My changes not backported from the main line https://bugs.openjdk.org/issues/?filter=44268 - Mark [1] https://openjdk.org/projects/jdk/25/#Schedule [2] https://openjdk.org/projects/jdk/25/#Features [3] https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010184.html [4] https://openjdk.org/jeps/3 [5] https://openjdk.org/s/jdk-rdp-1 [6] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [7] https://wiki.openjdk.org/display/SKARA/Backports [8] https://openjdk.org/guide/#working-with-git-branches [9] https://openjdk.org/guide/#working-with-backports-in-jbs From christian.s.stein at oracle.com Thu Jun 5 17:44:05 2025 From: christian.s.stein at oracle.com (Christian Stein) Date: Thu, 5 Jun 2025 17:44:05 +0000 Subject: jtreg 7.5.2 is here In-Reply-To: References: Message-ID: The integration of jtreg 7.5.2 in JDK 26-ea was done via https://github.com/openjdk/jdk/commit/fe3be498b83e70a9f4739ddad6642c3aa04a97d3 Happy testing! ________________________________________ From: Christian Stein Sent: Monday, May 19, 2025 18:38 To: jdk-dev at openjdk.org Subject: Coming soon: jtreg 7.5.2 JDK folk, This is a general heads-up that jtreg 7.5.2 is ready for use and that we should soon update JDK to use it. The most significant changes in jtreg 7.5.2 are minor improvements. It also contains a few new features and some bug fixes. Find a listing of all noteworthy changes at [1]. The plan is to make jtreg 7.5.2 the default version for JDK 25-ea by end of May 2025. Thanks to everyone who has helped thus far! [1] https://github.com/openjdk/jtreg/blob/jtreg-7.5.2+1/CHANGELOG.md From raffaello.giulietti at oracle.com Mon Jun 9 21:00:54 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 9 Jun 2025 23:00:54 +0200 Subject: CFV: New JDK Committer: Daniel Gredler (dgredler) In-Reply-To: References: Message-ID: Vote: yes On 2025-05-26 22:38, Philip Race wrote: > I hereby nominate: Daniel Gredler (dgredler) [1] to JDK Committer. > > Daniel has authored 16 changes [2], [3] to the OpenJDK JDK repository as > listed below. > > 8356814: LineBreakMeasurer.nextLayout() slower than necessary when no > break needed > 8356966: java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails > on Linux after JDK-8350203 > 8350203: [macos] Newlines and tabs are not ignored when drawing text to > a Graphics2D object 8353187: Test TextLayout/TestControls fails on > macOS: width of 0x9, 0xa, 0xd isn't zero > 8353002: Remove unnecessary Windows version check in WTaskbarPeer > 8352970: Remove unnecessary Windows version check in > Win32ShellFolderManager2 > 8352890: Remove unnecessary Windows version check in FileFontStrike > 8270265: LineBreakMeasurer calculates incorrect line breaks with zero- > width characters > 8349932: PSPrinterJob sometimes generates unnecessary PostScript commands > 6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063 > 8208377: Soft hyphens render if not using TextLayout > 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/ > PrintTextTest.java on Linux and Windows > 8344668: Unnecessary array allocations and copying in TextLine > 8283664: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ > PrintTextTest.java > 8339974: Graphics2D.drawString doesn't always work with Font derived > from AffineTransform > 8337681: PNGImageWriter uses much more memory than necessary > 8272878: JEP 381 cleanup: Remove unused Solaris code in > sun.font.TrueTypeGlyphMapper > > Votes are due by 21:00 UTC Monday 9th June 2025. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] https://openjdk.org/census#dgredler > [2] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author- > name%3A%22Daniel+Gredler%22&type=commits > [3] git log --author="Daniel Gredler" --format='%h %s' > [4] https://openjdk.org/census > [5] https://openjdk.org/bylaws#lazy-consensus From alexander.zuev at oracle.com Mon Jun 9 23:22:54 2025 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 9 Jun 2025 23:22:54 +0000 Subject: CFV: New JDK Committer: Daniel Gredler (dgredler) In-Reply-To: References: Message-ID: Vote: yes /Alex From daniel.fuchs at oracle.com Tue Jun 10 15:45:48 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 10 Jun 2025 16:45:48 +0100 Subject: CFV: New JDK Committer: Daniel Gredler (dgredler) In-Reply-To: References: Message-ID: <1c067430-2f9c-458d-a6f5-96c93d64aa15@oracle.com> Vote: yes best regards, -- daniel On 26/05/2025 21:38, Philip Race wrote: > I hereby nominate: Daniel Gredler (dgredler) [1] to JDK Committer. From philip.race at oracle.com Tue Jun 10 17:28:53 2025 From: philip.race at oracle.com (Philip Race) Date: Tue, 10 Jun 2025 10:28:53 -0700 Subject: Result: New JDK Committer: Daniel Gredler (dgredler) Message-ID: <8ad53443-4032-438a-a3e3-f338d40a0a9b@oracle.com> Voting for Daniel Gredler [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Phil PS, two late votes were not counted. [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010169.html From volker.simonis at gmail.com Fri Jun 13 14:32:17 2025 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Jun 2025 16:32:17 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) Message-ID: Hello OpenJDK Contributors, It's now more than a year that we we've switched from GitHub forks to branches for stabilization releases [1]. Overall, the transition was smooth and successful, but I think there are a few minor follow-ups which still need to be completed: 1. "JEP 3: JDK Release Process" [2] still described the old, forking workflow (i.e. "We fork the main-line repository into a stabilization repository, jdk/jdk$N"). This should be corrected. 2. The new stabilization branches have the same, unmodified README.md file like the main branch which is a little confusing. I propose that every time we create a new stabilization branch the first change in that new branch should update the README.md file (similar to what the community updates repositories are already doing [5]) with at least the following changes: - "Welcome to the JDK!" -> "Welcome to the JDK !" - Add a link to the corresponding release page (i.e. https://openjdk.org/projects/jdk//) - The links to the build instructions should be changed to point to the build instructions in the corresponding branch otherwise they might eventually point to a newer, incompatible version 3. The last one is more of a usability issue and I currently don't know how to solve it, but maybe someone else has an idea? Recently, GitHub changed the sorting order of branches in the pull-down menu for selecting a branch on their web page from alphabetical to "last recently used" [3]. This now makes it almost impossible to find the stabilization branches because they are buried somewhere in the middle of a ton of "pr/xxxx" branches. Finally I CC this message to jdk-updates-dev at openjdk.org as a reminder that the time might be ripe now to consider branching instead of forking for the update projects as well? Maybe we can start slowly by first getting rid of the "jdkNNu-dev" forks and use branches for this in the existing "jdkNNu" repositories as Oracle already does for the first two updates they do (e.g. [4]) Best regards, Volker [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-March/008834.html [2] https://openjdk.org/jeps/3#Overview [3] https://github.com/orgs/community/discussions/161489 [4] https://github.com/openjdk/jdk21u/tree/jdk21.0.1 [5] https://github.com/openjdk/jdk21u/commit/22d5e0d1f8849410abe40165b58f45f5e4293884 From magnus.ihse.bursie at oracle.com Mon Jun 16 10:07:14 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Jun 2025 12:07:14 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: References: Message-ID: On 2025-06-13 16:32, Volker Simonis wrote: > 2. The new stabilization branches have the same, unmodified README.md > file like the main branch which is a little confusing. I propose that > every time we create a new stabilization branch the first change in > that new branch should update the README.md file (similar to what the > community updates repositories are already doing [5]) with at least > the following changes: > - "Welcome to the JDK!" -> "Welcome to the JDK !" > - Add a link to the corresponding release page (i.e. > https://openjdk.org/projects/jdk//) That sounds like a very good idea. In fact, I think we should add even more, like a text saying that this branch will be frozen after GA, that mainline development will happen on the master branch, and that further development on JDK NN will happen within the JDK Updates project. > - The links to the build instructions should be changed to point to > the build instructions in the corresponding branch otherwise they > might eventually point to a newer, incompatible version What links are you referring to? > 3. The last one is more of a usability issue and I currently don't > know how to solve it, but maybe someone else has an idea? Recently, > GitHub changed the sorting order of branches in the pull-down menu for > selecting a branch on their web page from alphabetical to "last > recently used" [3]. This now makes it almost impossible to find the > stabilization branches because they are buried somewhere in the middle > of a ton of "pr/xxxx" branches. There is a search box in the drop down menu (at least for me, it might be some A/B testing change?). Typing "jdk" there filters out just the release branches. Not ideal, perhaps, but good enough. Let's hope GitHub adds some way to "favorite" branches to have them always show up first in the future. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Jun 16 16:35:00 2025 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Jun 2025 18:35:00 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: References: Message-ID: On Mon, Jun 16, 2025 at 12:07?PM Magnus Ihse Bursie wrote: > > On 2025-06-13 16:32, Volker Simonis wrote: > > 2. The new stabilization branches have the same, unmodified README.md > file like the main branch which is a little confusing. I propose that > every time we create a new stabilization branch the first change in > that new branch should update the README.md file (similar to what the > community updates repositories are already doing [5]) with at least > the following changes: > - "Welcome to the JDK!" -> "Welcome to the JDK !" > - Add a link to the corresponding release page (i.e. > https://openjdk.org/projects/jdk//) > > That sounds like a very good idea. In fact, I think we should add even more, like a text saying that this branch will be frozen after GA, that mainline development will happen on the master branch, and that further development on JDK NN will happen within the JDK Updates project. > > - The links to the build instructions should be changed to point to > the build instructions in the corresponding branch otherwise they > might eventually point to a newer, incompatible version > > What links are you referring to? Sorry for the confusion. I just realized that the links to `doc/building.{md,html}` are relative links and therefor already pointing to the correct files. However, the link to the `online documentation` is pointing to `https://openjdk.org/groups/build/doc/building.html` which isn't even at GitHub but on openjkd.org and I don't know when and how that is updated (in any case, it's currently just a single, static file for all JDK versions). Instead, I propose to replace the link by something like https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/jdk25/doc/building.html which will serve the current file as HTML and make it always up-to-date. Actually, once we have that, we could even remove the link to `https://github.com/openjdk/jdk/blob/jdk25/doc/building.html` because looking at a raw HTML file is pretty inconvenient if you're searching for build information. > > 3. The last one is more of a usability issue and I currently don't > know how to solve it, but maybe someone else has an idea? Recently, > GitHub changed the sorting order of branches in the pull-down menu for > selecting a branch on their web page from alphabetical to "last > recently used" [3]. This now makes it almost impossible to find the > stabilization branches because they are buried somewhere in the middle > of a ton of "pr/xxxx" branches. > > There is a search box in the drop down menu (at least for me, it might be some A/B testing change?). Typing "jdk" there filters out just the release branches. Not ideal, perhaps, but good enough. Let's hope GitHub adds some way to "favorite" branches to have them always show up first in the future. I have that too, but you need to know what you're searching for (i.e. "jdk...") in order to make it useful. But as I said, I don't have a better solution either. > > /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 17 14:21:28 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Jun 2025 16:21:28 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: References: Message-ID: On 2025-06-16 18:35, Volker Simonis wrote: > On Mon, Jun 16, 2025 at 12:07?PM Magnus Ihse Bursie > wrote: >> What links are you referring to? > Sorry for the confusion. I just realized that the links to > `doc/building.{md,html}` are relative links and therefor already > pointing to the correct files. > > However, the link to the `online documentation` is pointing to > `https://openjdk.org/groups/build/doc/building.html` which isn't even > at GitHub but on openjkd.org and I don't know when and how that is > updated (in any case, it's currently just a single, static file for > all JDK versions). Instead, I propose to replace the link by something > like https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/jdk25/doc/building.html > which will serve the current file as HTML and make it always > up-to-date. Actually, once we have that, we could even remove the link > to `https://github.com/openjdk/jdk/blob/jdk25/doc/building.html` > because looking at a raw HTML file is pretty inconvenient if you're > searching for build information. Well, that is just what https://openjdk.org/groups/build/doc/building.html is. It is not a static page, it is a stable and comprehensible URL that gets the build README directly from Github (but presented as text/html from the server, which is something Github does not do). It is by purpose under openjdk.org, instead of pointing to Github, in the same vein as git.openjdk.org is used, instead of github.com, in official links. As for the update branches, just having a relative path to the markdown file seems fine, and sufficient. (Long term, I want to remove the checked-in html versions and just keep the markdown versions, but there are some issues with markdown differences between GitHub and pandoc that needs to be resolved first, and this has not been a priority for me.) /Magnus From volker.simonis at gmail.com Wed Jun 18 13:51:31 2025 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Jun 2025 15:51:31 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: References: Message-ID: On Tue, Jun 17, 2025 at 4:21?PM Magnus Ihse Bursie wrote: > > > On 2025-06-16 18:35, Volker Simonis wrote: > > On Mon, Jun 16, 2025 at 12:07?PM Magnus Ihse Bursie > > wrote: > >> What links are you referring to? > > Sorry for the confusion. I just realized that the links to > > `doc/building.{md,html}` are relative links and therefor already > > pointing to the correct files. > > > > However, the link to the `online documentation` is pointing to > > `https://openjdk.org/groups/build/doc/building.html` which isn't even > > at GitHub but on openjkd.org and I don't know when and how that is > > updated (in any case, it's currently just a single, static file for > > all JDK versions). Instead, I propose to replace the link by something > > like https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/jdk25/doc/building.html > > which will serve the current file as HTML and make it always > > up-to-date. Actually, once we have that, we could even remove the link > > to `https://github.com/openjdk/jdk/blob/jdk25/doc/building.html` > > because looking at a raw HTML file is pretty inconvenient if you're > > searching for build information. > > Well, that is just what > https://openjdk.org/groups/build/doc/building.html is. It is not a > static page, it is a stable and comprehensible URL that gets the build > README directly from Github (but presented as text/html from the server, > which is something Github does not do). OK, I see now, https://openjdk.org/groups/build/doc/building.html uses iframe magic and https://htmlpreview.github.io under the hood to serve the actual file as HTML. But this only the correct build.html file for the master branch and not for the older release branches.So why do we need this indirection through https://openjdk.org/groups/build/doc/building.html and can not place the link to https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html right into the README.md file as I proposed? This would allow us to point to the correct build.html in a branch while currently e.g. the link in https://github.com/openjdk/jdk/blob/jdk23/README.md will show us https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html instead of the correct (and different) https://raw.githubusercontent.com/openjdk/jdk/jdk23/doc/building.html. > It is by purpose under > openjdk.org, instead of pointing to Github, in the same vein as > git.openjdk.org is used, instead of github.com, in official links. > > As for the update branches, just having a relative path to the markdown > file seems fine, and sufficient. (Long term, I want to remove the > checked-in html versions and just keep the markdown versions, but there > are some issues with markdown differences between GitHub and pandoc that > needs to be resolved first, and this has not been a priority for me.) > > /Magnus > > From brent.christian at oracle.com Wed Jun 18 21:27:12 2025 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 18 Jun 2025 14:27:12 -0700 Subject: CFV: New JDK Committer: Daniel Gredler (dgredler) In-Reply-To: References: Message-ID: Vote: Yes On 5/26/25 1:38 PM, Philip Race wrote: > I hereby nominate: Daniel Gredler (dgredler) [1] to JDK Committer. > From johan.sjolen at oracle.com Thu Jun 19 12:57:55 2025 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Thu, 19 Jun 2025 12:57:55 +0000 Subject: CFV: New JDK Committer: Casper Norrbin In-Reply-To: References: Message-ID: Hi, I sent the e-mail concluding the voting for Casper Norrbin to the wrong address (jdk-dev-retn instead of jdk-dev). It has, however, been sent correctly to the registrar and recorded. Below is that e-mail. Cheers. ________________________________________ From: Johan Sjolen Sent: Thursday, June 5, 2025 13:40 To: jdk-dev Cc: registrar at openjdk.org Subject: Re: CFV: New JDK Committer: Casper Norrbin Voting for Casper Norrbin [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Johan Sj?l?n [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010124.html ( with information regarding commits in: https://mail.openjdk.org/pipermail/jdk-dev/2025-May/010126.html ) ________________________________________ From: Johan Sjolen Sent: Thursday, May 22, 2025 10:20 To: jdk-dev Subject: CFV: New JDK Committer: Casper Norrbin I hereby nominate Casper Norrbin (cnorrbin) to JDK Committer. Casper is a member of the runtime team at Oracle and has to date contributed 12 changes to the JDK project. He has, among other things, contributed improvements to the string table, a red-black tree implementation and done various bug fixes. He is currently working on removing PerfData sampling via StatSampler and improving the JDK's container support. Votes are due by 2025-06-05 11:00 GMT+2. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Johan Sj?l?n [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote From magnus.ihse.bursie at oracle.com Thu Jun 19 13:22:40 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Jun 2025 15:22:40 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: References: Message-ID: <0d76353a-2310-4d19-bb4b-4ae4d5d5b007@oracle.com> On 2025-06-18 15:51, Volker Simonis wrote: > On Tue, Jun 17, 2025 at 4:21?PM Magnus Ihse Bursie > wrote: >> >> On 2025-06-16 18:35, Volker Simonis wrote: >>> On Mon, Jun 16, 2025 at 12:07?PM Magnus Ihse Bursie >>> wrote: >>>> What links are you referring to? >>> Sorry for the confusion. I just realized that the links to >>> `doc/building.{md,html}` are relative links and therefor already >>> pointing to the correct files. >>> >>> However, the link to the `online documentation` is pointing to >>> `https://openjdk.org/groups/build/doc/building.html` which isn't even >>> at GitHub but on openjkd.org and I don't know when and how that is >>> updated (in any case, it's currently just a single, static file for >>> all JDK versions). Instead, I propose to replace the link by something >>> like https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/jdk25/doc/building.html >>> which will serve the current file as HTML and make it always >>> up-to-date. Actually, once we have that, we could even remove the link >>> to `https://github.com/openjdk/jdk/blob/jdk25/doc/building.html` >>> because looking at a raw HTML file is pretty inconvenient if you're >>> searching for build information. >> Well, that is just what >> https://openjdk.org/groups/build/doc/building.html is. It is not a >> static page, it is a stable and comprehensible URL that gets the build >> README directly from Github (but presented as text/html from the server, >> which is something Github does not do). > OK, I see now, https://openjdk.org/groups/build/doc/building.html uses > iframe magic and https://htmlpreview.github.io under the hood to serve > the actual file as HTML. But this only the correct build.html file for > the master branch and not for the older release branches.So why do we > need this indirection through > https://openjdk.org/groups/build/doc/building.html and can not place > the link to https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html > right into the README.md file as I proposed? This would allow us to > point to the correct build.html in a branch while currently e.g. the > link in https://github.com/openjdk/jdk/blob/jdk23/README.md will show > us https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html > instead of the correct (and different) > https://raw.githubusercontent.com/openjdk/jdk/jdk23/doc/building.html. I don't think it is proper to point official URLs to non-openjdk.org resources. As I said, I think it would be enough to point to just the markdown file, and it resides in the current repo and thus needs just a local link. The point is that people are not really supposed to build the frozen GA versions, so we should not really go overboard with linking to a build README... As for the update releases, that is a question for the JDK Updates project. /Magnus From volker.simonis at gmail.com Sun Jun 22 14:16:04 2025 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 22 Jun 2025 16:16:04 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: <0d76353a-2310-4d19-bb4b-4ae4d5d5b007@oracle.com> References: <0d76353a-2310-4d19-bb4b-4ae4d5d5b007@oracle.com> Message-ID: Magnus Ihse Bursie schrieb am Do., 19. Juni 2025, 15:22: > On 2025-06-18 15:51, Volker Simonis wrote: > > > On Tue, Jun 17, 2025 at 4:21?PM Magnus Ihse Bursie > > wrote: > >> > >> On 2025-06-16 18:35, Volker Simonis wrote: > >>> On Mon, Jun 16, 2025 at 12:07?PM Magnus Ihse Bursie > >>> wrote: > >>>> What links are you referring to? > >>> Sorry for the confusion. I just realized that the links to > >>> `doc/building.{md,html}` are relative links and therefor already > >>> pointing to the correct files. > >>> > >>> However, the link to the `online documentation` is pointing to > >>> `https://openjdk.org/groups/build/doc/building.html` > which isn't even > >>> at GitHub but on openjkd.org and I don't know when and how that is > >>> updated (in any case, it's currently just a single, static file for > >>> all JDK versions). Instead, I propose to replace the link by something > >>> like > https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/jdk25/doc/building.html > >>> which will serve the current file as HTML and make it always > >>> up-to-date. Actually, once we have that, we could even remove the link > >>> to `https://github.com/openjdk/jdk/blob/jdk25/doc/building.html` > > >>> because looking at a raw HTML file is pretty inconvenient if you're > >>> searching for build information. > >> Well, that is just what > >> https://openjdk.org/groups/build/doc/building.html is. It is not a > >> static page, it is a stable and comprehensible URL that gets the build > >> README directly from Github (but presented as text/html from the server, > >> which is something Github does not do). > > OK, I see now, https://openjdk.org/groups/build/doc/building.html uses > > iframe magic and https://htmlpreview.github.io under the hood to serve > > the actual file as HTML. But this only the correct build.html file for > > the master branch and not for the older release branches.So why do we > > need this indirection through > > https://openjdk.org/groups/build/doc/building.html and can not place > > the link to > https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html > > right into the README.md file as I proposed? This would allow us to > > point to the correct build.html in a branch while currently e.g. the > > link in https://github.com/openjdk/jdk/blob/jdk23/README.md will show > > us > https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html > > instead of the correct (and different) > > https://raw.githubusercontent.com/openjdk/jdk/jdk23/doc/building.html. > > I don't think it is proper to point official URLs to non-openjdk.org > resources. Saying that pointing to non openjdk.org resources is "not proper" and instead pointing to another openjdk.org resource which injects the non openjdk.org content in an iframe is obviously lying to oneself. As I said, I think it would be enough to point to just the > markdown file, and it resides in the current repo and thus needs just a > local link. > That's fine for me. > The point is that people are not really supposed to build the frozen GA > versions, so we should not really go overboard with linking to a build > README... > > As for the update releases, that is a question for the JDK Updates project. > > /Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Mon Jun 23 10:02:48 2025 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 23 Jun 2025 12:02:48 +0200 Subject: Follow-up: Branch github.com/openjdk/jdk for stabilization (instead of fork) In-Reply-To: (Volker Simonis's message of "Sun, 22 Jun 2025 16:16:04 +0200") References: <0d76353a-2310-4d19-bb4b-4ae4d5d5b007@oracle.com> Message-ID: * Volker Simonis: > Saying that pointing to non openjdk.org resources is "not proper" and > instead pointing to another openjdk.org resource which injects the non > openjdk.org content in an iframe is obviously lying to oneself. But the URL is much likely to be copied around because it does not show up in the address bar. This way, the project retains the ability to make available or adjust content under the URL as long as it exists. With links provided by third-party repository services, that is not necessarily the case. Thanks, Florian