From tobias.hartmann at oracle.com Mon Jul 1 11:23:31 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Jul 2024 13:23:31 +0200 Subject: Result: New JDK Committer: Jasmine Karthikeyan Message-ID: Voting for Jasmine Karthikeyan [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Tobias [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009123.html From mark.reinhold at oracle.com Mon Jul 1 18:38:36 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 1 Jul 2024 18:38:36 +0000 Subject: Proposal: Require re-review before integration if the PR is modified In-Reply-To: References: Message-ID: <20240701143834.170657433@eggemoggin.niobe.net> 2024/6/18 12:00:00 -0400, iris.clark at oracle.com: > Every PR must be reviewed by at least one Reviewer [0] before it's integrated > into the main-line repository [1]. While we recommend that the PR contain the > final version of the change at creation time, this is not always feasible, > particularly for large or complex changes. The integrated version of the PR > may evolve significantly from when the review was done. Thus the final > commit's "Reviewed-by" field may give false confidence that the complete set > of changes has been reviewed before it was integrated into the repository. > This could, in the worst case, allow an adversary to commit malicious code. > > I propose that reviews be automatically marked as stale when the PR is > updated, and re-review be required before integration. Stale reviews do not > count towards the minimum number of reviews required for integration. The > final commit's "Reviewed-by" field will continue to list all reviewers, > regardless of whether they evaluated an older version of the PR. When a PR is > updated, instead of simply noting that the PR applies to a particular version, > the review will be noted as stale, indicating that the PR does not meet > integration requirements. This re-review requirement has been in effect for > the OpenJFX repos [2] since October 2019, when OpenJFX moved to GitHub using > the Skara tooling. > > I suggest that we adopt this policy two weeks hence, on Tue 3 July. > > Concerns? > > [0] https://openjdk.org/guide/#fixing-a-bug (step 12) > [1] https://github.com/openjdk/jdk > [2] https://github.com/openjdk/jfx Iris -- thanks for this proposal. To summarize the key points of the discussion: - This change will require a bit more work on the part of Reviewers when a re-review is required. They can minimize that work, however, by first looking at the diff of changes since their last review; if that diff is small (e.g., just a copyright-year update) then they need not re-review the entire PR [1]. - This change might motivate contributors to squash their commits together or push them in bulk so that Reviewers aren't prompted to re-review PRs too frequently [2]. - When a re-review is required then only the number of Reviewers required by Skara will need to re-review. The default number of Reviewers required is one, but for a particular PR this can be increased via the `/reviewers` command [3]. A Reviewer can later decrease that via the same command, so if a contributor commits a late but trivial change to a PR then the first Reviewer who examines it can use `/reviewers 1` to enable immediate integration [4]. On balance, the benefit of this change appears to justify the cost. Let?s adopt it effective tomorrow, as Iris proposed. If it proves more onerous than we expect then we?ll re-evaluate it. - Mark [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009139.html [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009143.html [3] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009146.html [4] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009156.html From pavel.rappo at oracle.com Wed Jul 3 15:36:01 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 3 Jul 2024 15:36:01 +0000 Subject: CFV: New JDK Reviewer: Chen Liang In-Reply-To: <44E0B997-FC0C-437A-8FB2-3D8B901D29E1@oracle.com> References: <44E0B997-FC0C-437A-8FB2-3D8B901D29E1@oracle.com> Message-ID: <77422731-88B9-420D-BBEF-0C5F26F9565F@oracle.com> Not a vote, but a friendly reminder to vote if you were planning to; thanks. -Pavel > On 26 Jun 2024, at 09:57, Pavel Rappo wrote: > > I hereby nominate Chen Liang (liach) to JDK Reviewer. > > Since 2021 Chen has co-authored 3 commits and authored 60 commits. Over that time Chen has reviewed 58 commits, most of which are in the java.lang {constant,invoke,reflect,runtime,util,}, classfile, jdk.compiler, and jdk.javadoc areas. > > While this nomination comes shortly after Chen's nomination to JDK Committer, it's not because the Reviewer CFV is premature, but because the Committer CFV was long overdue. > > Chen's comments as a de facto reviewer are substantial and helpful. Chen's activity in the openjdk/jdk repo can be gauged, for example, using links [1] and [2]. > > Votes are due by 2024-07-10 20:00 UTC. > > Only current JDK Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [4]. > > -Pavel > > [1] https://github.com/openjdk/jdk/pulls?q=author%3Aliach > [2] https://github.com/search?type=commits&q=liach+repo%3Aopenjdk%2Fjdk > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#reviewer-vote From mikael.vidstedt at oracle.com Wed Jul 3 18:17:26 2024 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 3 Jul 2024 18:17:26 +0000 Subject: CFV: New JDK Reviewer: Chen Liang In-Reply-To: <44E0B997-FC0C-437A-8FB2-3D8B901D29E1@oracle.com> References: <44E0B997-FC0C-437A-8FB2-3D8B901D29E1@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On Jun 26, 2024, at 1:57?AM, Pavel Rappo wrote: > > I hereby nominate Chen Liang (liach) to JDK Reviewer. > > Since 2021 Chen has co-authored 3 commits and authored 60 commits. Over that time Chen has reviewed 58 commits, most of which are in the java.lang {constant,invoke,reflect,runtime,util,}, classfile, jdk.compiler, and jdk.javadoc areas. > > While this nomination comes shortly after Chen's nomination to JDK Committer, it's not because the Reviewer CFV is premature, but because the Committer CFV was long overdue. > > Chen's comments as a de facto reviewer are substantial and helpful. Chen's activity in the openjdk/jdk repo can be gauged, for example, using links [1] and [2]. > > Votes are due by 2024-07-10 20:00 UTC. > > Only current JDK Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [4]. > > -Pavel > > [1] https://github.com/openjdk/jdk/pulls?q=author%3Aliach > [2] https://github.com/search?type=commits&q=liach+repo%3Aopenjdk%2Fjdk > [3] https://openjdk.org/census > [4] https://openjdk.org/projects/#reviewer-vote From thomas.stuefe at gmail.com Thu Jul 4 10:43:39 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 4 Jul 2024 12:43:39 +0200 Subject: Proposal: Require re-review before integration if the PR is modified In-Reply-To: <30089535-71fe-4c89-9a90-d3f4733da643@oracle.com> References: <671452e9-a6a7-4f0b-8ddb-d8d3978e162b@oracle.com> <30089535-71fe-4c89-9a90-d3f4733da643@oracle.com> Message-ID: Thanks, Jorn. Yeah, okay, but this seems rather cumbersome. And it leaves the reviewers guessing. As a Reviewer, I want to see a PR branch that is kept in sync with master, especially for longer-running PRs. Another thought, would it be possible for Skara to disregard changes that just fix the copyrights? I have many reviews ending with "LGTM, please fix copyrights before pushing". It would be nice not to need another review for those. Thanks, Thomas On Tue, Jun 25, 2024 at 1:14?PM Jorn Vernee wrote: > I'd like to also point out that: you are not required to push the merge to > your PR branch in order to have github actions run for it. The github > actions run for any branch that gets pushed to your fork (if you have them > enabled), the Skara bots just fetch that information when the branch is > used for a PR. > > So, in other words, you could create a new local branch from your PR > branch, do the merge on the new branch, and push that to your fork, > creating a new branch in your fork with the merge. Github actions would run > for the new branch, but this wouldn't modify the PR branch, so it wouldn't > require a re-review under the proposed change. > > Jorn > On 25-6-2024 11:19, erik.joelsson at oracle.com wrote: > > On 6/24/24 06:38, Thomas St?fe wrote: > > One question, do merges with master cause the Skara reviewer check to > fail? > > We try to encourage authors to merge often, especially before pushing. > Patches should be based on a reasonably fresh copy of master. I believe the > contribution guidelines state that too, and it is just good practice. > > Skara does not have a way to distinguish clean merges from the target > branch from other changes when determining if a review is stale. It simple > compares the hash the review was performed at with the current head hash of > the PR source branch. > > Implementing such a check may be possible in the future, but it's not > something we can promise to happen. > > /Erik > > Cheers, Thomas > > On Tue, Jun 18, 2024 at 6:00?PM Iris Clark wrote: > >> Hi. >> >> Every PR must be reviewed by at least one Reviewer [0] before it's >> integrated >> into the main-line repository [1]. While we recommend that the PR >> contain the >> final version of the change at creation time, this is not always feasible, >> particularly for large or complex changes. The integrated version of the >> PR >> may evolve significantly from when the review was done. Thus the final >> commit's "Reviewed-by" field may give false confidence that the complete >> set >> of changes has been reviewed before it was integrated into the repository. >> This could, in the worst case, allow an adversary to commit malicious >> code. >> >> I propose that reviews be automatically marked as stale when the PR is >> updated, and re-review be required before integration. Stale reviews do >> not >> count towards the minimum number of reviews required for integration. The >> final commit's "Reviewed-by" field will continue to list all reviewers, >> regardless of whether they evaluated an older version of the PR. When a >> PR is >> updated, instead of simply noting that the PR applies to a particular >> version, >> the review will be noted as stale, indicating that the PR does not meet >> integration requirements. This re-review requirement has been in effect >> for >> the OpenJFX repos [2] since October 2019, when OpenJFX moved to GitHub >> using >> the Skara tooling. >> >> I suggest that we adopt this policy two weeks hence, on Tue 3 July. >> >> Concerns? >> >> [0] https://openjdk.org/guide/#fixing-a-bug (step 12) >> [1] https://github.com/openjdk/jdk >> [2] https://github.com/openjdk/jfx >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Fri Jul 5 07:03:53 2024 From: tstuefe at redhat.com (Thomas Stuefe) Date: Fri, 5 Jul 2024 09:03:53 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles Message-ID: I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. Votes are due by July 22, 2024. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thomas Stuefe [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated [2] https://openjdk.org/census#jdk [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Jul 5 07:10:45 2024 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 05 Jul 2024 09:10:45 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <4fe1293078385400a0295350d79277fd3fabcc13.camel@redhat.com> Vote: yes On Fri, 2024-07-05 at 09:03 +0200, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote From volker.simonis at gmail.com Fri Jul 5 07:36:43 2024 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Jul 2024 09:36:43 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes On Fri, Jul 5, 2024 at 9:04?AM Thomas Stuefe wrote: > > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote From neugens.limasoftware at gmail.com Fri Jul 5 08:01:08 2024 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 5 Jul 2024 10:01:08 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <51617ceb-f125-421a-833c-a3bc4a0db23b@Canary> Vote: Yes Cheers, Mario -- Sent from Canary (https://canarymail.io) > On Friday, Jul 05, 2024 at 09:37, Volker Simonis wrote: > Vote: yes > > On Fri, Jul 5, 2024 at 9:04?AM Thomas Stuefe wrote: > > > > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. > > > > Votes are due by July 22, 2024. > > > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [3]. > > > > Thomas Stuefe > > > > > > [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > > [2] https://openjdk.org/census#jdk > > [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From Amit.Kumar220 at ibm.com Fri Jul 5 08:12:23 2024 From: Amit.Kumar220 at ibm.com (Amit Kumar) Date: Fri, 5 Jul 2024 08:12:23 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes Thanks, Amit From thomas.stuefe at gmail.com Fri Jul 5 08:50:02 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Jul 2024 10:50:02 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes On Fri, Jul 5, 2024 at 9:04?AM Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in > the past, more recently on OpenJDK proper, contributing 25 patches so far > [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Jul 5 08:58:10 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Jul 2024 10:58:10 +0200 Subject: CFV: New JDK Committer: Archie Cobbs In-Reply-To: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> References: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> Message-ID: Vote: yes On Wed, Jun 26, 2024 at 2:12?PM Vicente Romero wrote: > I hereby nominate Archie Cobbs (acobbs) [1] to JDK Committer. > > Usually would-be committers tackle simpler tasks at the beginning and > get to do more complex ones later on. Archie is a disruptor, he is the > owner and co-author of JEP 447: Statements before super(...) (Preview) > [2] which was successfully delivered in JDK 22 and of its continuation > JEP 482: Flexible Constructor Bodies (Second Preview) [3], delivered in > JDK 23. > > Apart from this Archie has worked on many other projects like: "'this' > escape analysis", and on a multitude of bugs on javac, core-libs, xml, > etc. Archie's activity in the openjdk/jdk repo can be gauged, for > example, using [4]. > > Votes are due by 2024-07-10 20:00 UTC. > > Only current JDK Reviewers [5] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [6]. > > -Vicente > > [1] https://openjdk.org/census#acobbs > [2] https://openjdk.org/jeps/447 > [3] https://openjdk.org/jeps/482 > [4] https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs > [5] https://openjdk.org/census > [6] https://openjdk.org/projects/#reviewer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.sjolen at oracle.com Fri Jul 5 08:58:30 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Fri, 5 Jul 2024 08:58:30 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes Cheers! ________________________________________ From: jdk-dev on behalf of Thomas Stuefe Sent: Friday, July 5, 2024 09:03 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Sonia Zaldana Calles I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. Votes are due by July 22, 2024. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thomas Stuefe [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated [2] https://openjdk.org/census#jdk [3] https://openjdk.org/projects/#committer-vote From rwestrel at redhat.com Fri Jul 5 12:12:04 2024 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 05 Jul 2024 14:12:04 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <87r0c8597v.fsf@redhat.com> Vote: yes Roland. From tobias.hartmann at oracle.com Fri Jul 5 13:18:16 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 5 Jul 2024 15:18:16 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <9350f63c-7137-4938-a5a7-9a3870834b2f@oracle.com> Vote: yes Best regards, Tobias On 05.07.24 09:03, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on > OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and > serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination.? Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote From coleen.phillimore at oracle.com Fri Jul 5 13:24:59 2024 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 5 Jul 2024 09:24:59 -0400 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <46d9fc0c-f06e-44b3-ae3d-f7819e776223@oracle.com> Vote: yes On 7/5/24 3:03 AM, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden > in the past, more recently on OpenJDK proper, contributing 25 patches > so far [1], mainly in hotspot runtime, platform porting, and > serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote From thihup at gmail.com Fri Jul 5 14:28:37 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Fri, 5 Jul 2024 11:28:37 -0300 Subject: Fwd: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: ---------- Forwarded message --------- De: Thiago Henrique Hupner Date: qua., 3 de jul. de 2024 ?s 07:26 Subject: Proposal: Option to ignore non-existent -javaagent To: Dear JDK developers, I'd like to propose adding an option that allows the JVM to ignore a non-existent -javaagent instead of aborting. Currently, if a -javaagent is specified but the agent jar file doesn't exist, the JVM aborts with an error. This can cause issues in environments where the same JVM arguments are used across different systems, but not all systems have the agent installed. The proposed option (e.g. -XX:+IgnoreNonExistentJavaAgent) would allow the JVM to continue starting up even if the specified agent jar is not found, simply skipping that agent. This could improve flexibility and ease deployment in heterogeneous environments. Potential considerations: 1. Security implications of silently ignoring a missing agent 2. Logging when an agent is skipped 3. Interaction with other agent-related options I'd appreciate your thoughts on this proposal. Is this something that would be valuable to the community? Are there any concerns or alternative approaches we should consider? Thank you for your time and consideration. Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Jul 5 21:19:20 2024 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 5 Jul 2024 21:19:20 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles Message-ID: Vote: yes From: jdk-dev on behalf of Thomas Stuefe Date: Friday, July 5, 2024 at 12:05?AM To: "jdk-dev at openjdk.org" Subject: CFV: New JDK Committer: Sonia Zaldana Calles I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. Votes are due by July 22, 2024. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thomas Stuefe [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated [2] https://openjdk.org/census#jdk [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jul 8 06:31:06 2024 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Jul 2024 16:31:06 +1000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes David On 5/07/2024 5:03 pm, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden > in the past, more recently on OpenJDK proper, contributing 25 patches so > far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote > From adam.sotona at oracle.com Mon Jul 8 08:40:29 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 8 Jul 2024 08:40:29 +0000 Subject: CFV: New JDK Committer: Archie Cobbs In-Reply-To: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> References: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> Message-ID: Vote: yes Adam From: jdk-dev on behalf of Vicente Romero Date: Wednesday, 26 June 2024 at 12:27 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Archie Cobbs I hereby nominate Archie Cobbs (acobbs) [1] to JDK Committer. Usually would-be committers tackle simpler tasks at the beginning and get to do more complex ones later on. Archie is a disruptor, he is the owner and co-author of JEP 447: Statements before super(...) (Preview) [2] which was successfully delivered in JDK 22 and of its continuation JEP 482: Flexible Constructor Bodies (Second Preview) [3], delivered in JDK 23. Apart from this Archie has worked on many other projects like: "'this' escape analysis", and on a multitude of bugs on javac, core-libs, xml, etc. Archie's activity in the openjdk/jdk repo can be gauged, for example, using [4]. Votes are due by 2024-07-10 20:00 UTC. Only current JDK Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [6]. -Vicente [1] https://openjdk.org/census#acobbs [2] https://openjdk.org/jeps/447 [3] https://openjdk.org/jeps/482 [4] https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs [5] https://openjdk.org/census [6] https://openjdk.org/projects/#reviewer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jul 8 10:57:06 2024 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 8 Jul 2024 10:57:06 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote:yes /Christoph From: jdk-dev On Behalf Of Thomas Stuefe Sent: Freitag, 5. Juli 2024 09:04 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Sonia Zaldana Calles Some people who received this message don't often get email from tstuefe at redhat.com. Learn why this is important I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. Votes are due by July 22, 2024. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thomas Stuefe [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated [2] https://openjdk.org/census#jdk [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jul 8 10:57:33 2024 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 8 Jul 2024 10:57:33 +0000 Subject: CFV: New JDK Committer: Archie Cobbs In-Reply-To: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> References: <712e7fcb-3934-4f9e-90f7-4d63eede28dd@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Vicente Romero > Sent: Mittwoch, 26. Juni 2024 12:27 > To: jdk-dev at openjdk.org > Subject: CFV: New JDK Committer: Archie Cobbs > > I hereby nominate Archie Cobbs (acobbs) [1] to JDK Committer. > > Usually would-be committers tackle simpler tasks at the beginning and get to > do more complex ones later on. Archie is a disruptor, he is the owner and co- > author of JEP 447: Statements before super(...) (Preview) [2] which was > successfully delivered in JDK 22 and of its continuation JEP 482: Flexible > Constructor Bodies (Second Preview) [3],?delivered in JDK 23. > > Apart from this Archie has worked on many other projects like: "'this' > escape analysis", and on a multitude of bugs on javac, core-libs, xml, etc. > Archie's activity in the openjdk/jdk repo can be gauged, for example, using [4]. > > Votes are due by 2024-07-10 20:00 UTC. > > Only current JDK Reviewers [5] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [6]. > > -Vicente > > [1] https://openjdk.org/census#acobbs > [2] https://openjdk.org/jeps/447 > [3] https://openjdk.org/jeps/482 > [4] https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs > [5] https://openjdk.org/census > [6] https://openjdk.org/projects/#reviewer-vote From adinn at redhat.com Mon Jul 8 11:11:30 2024 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 8 Jul 2024 12:11:30 +0100 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <04f5e7bd-659d-4d59-aaa1-ae772b236766@redhat.com> Vote: yes On 05/07/2024 08:03, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden > in the past, more recently on OpenJDK proper, contributing 25 patches so > far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] 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 kevin.rushforth at oracle.com Mon Jul 8 13:52:55 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 8 Jul 2024 06:52:55 -0700 Subject: Proposal: Require re-review before integration if the PR is modified In-Reply-To: References: <671452e9-a6a7-4f0b-8ddb-d8d3978e162b@oracle.com> <30089535-71fe-4c89-9a90-d3f4733da643@oracle.com> Message-ID: <45cda3d5-cb8b-4c39-bd88-37e70a1b138a@oracle.com> > Thanks, Jorn. Yeah, okay, but this seems rather cumbersome. And it > leaves the reviewers guessing. As a Reviewer, I want to see a PR > branch that is kept in sync with master, especially for longer-running > PRs. An enhancement was filed to not require re-review for a clean merge: https://bugs.openjdk.org/browse/SKARA-2312 It is being worked on, although there is no timeline for when it might be implemented. > Another thought, would it be possible for Skara to disregard changes > that just fix the copyrights? It might be possible, since Skara does this when comparing whether a backport is clean. I'm not sure how likely it is. -- Kevin On 7/4/2024 3:43 AM, Thomas St?fe wrote: > Thanks, Jorn. Yeah, okay, but this seems rather cumbersome. And it > leaves the reviewers guessing. As a Reviewer, I want to see a PR > branch that is kept in sync with master, especially for longer-running > PRs. > > Another thought, would it be possible for Skara to disregard changes > that just fix the copyrights? I have many reviews ending with "LGTM, > please fix copyrights before pushing". It would be nice not to need > another review for those. > > Thanks, Thomas > > On Tue, Jun 25, 2024 at 1:14?PM Jorn Vernee > wrote: > > I'd like to also point out that: you are not required to push the > merge to your PR branch in order to have github actions run for > it. The github actions run for any branch that gets pushed to your > fork (if you have them enabled), the Skara bots just fetch that > information when the branch is used for a PR. > > So, in other words, you could create a new local branch from your > PR branch, do the merge on the new branch, and push that to your > fork, creating a new branch in your fork with the merge. Github > actions would run for the new branch, but this wouldn't modify the > PR branch, so it wouldn't require a re-review under the proposed > change. > > Jorn > > On 25-6-2024 11:19, erik.joelsson at oracle.com wrote: >> On 6/24/24 06:38, Thomas St?fe wrote: >>> One question, do merges with master cause the Skara reviewer >>> check to fail? >>> >>> We try to encourage authors to merge often, especially before >>> pushing. Patches should be based on a reasonably fresh copy of >>> master. I believe the contribution guidelines state that too, >>> and it is just good practice. >>> >> Skara does not have a way to distinguish clean merges from the >> target branch from other changes when determining if a review is >> stale. It simple compares the hash the review was performed at >> with the current head hash of the PR source branch. >> >> Implementing such a check may be possible in the future, but it's >> not something we can promise to happen. >> >> /Erik >> >>> Cheers, Thomas >>> >>> On Tue, Jun 18, 2024 at 6:00?PM Iris Clark >>> wrote: >>> >>> Hi. >>> >>> Every PR must be reviewed by at least one Reviewer [0] >>> before it's integrated >>> into the main-line repository [1].? While we recommend that >>> the PR contain the >>> final version of the change at creation time, this is not >>> always feasible, >>> particularly for large or complex changes.? The integrated >>> version of the PR >>> may evolve significantly from when the review was done.? >>> Thus the final >>> commit's "Reviewed-by" field may give false confidence that >>> the complete set >>> of changes has been reviewed before it was integrated into >>> the repository. >>> This could, in the worst case, allow an adversary to commit >>> malicious code. >>> >>> I propose that reviews be automatically marked as stale when >>> the PR is >>> updated, and re-review be required before integration.? >>> Stale reviews do not >>> count towards the minimum number of reviews required for >>> integration.? The >>> final commit's "Reviewed-by" field will continue to list all >>> reviewers, >>> regardless of whether they evaluated an older version of the >>> PR.? When a PR is >>> updated, instead of simply noting that the PR applies to a >>> particular version, >>> the review will be noted as stale, indicating that the PR >>> does not meet >>> integration requirements.? This re-review requirement has >>> been in effect for >>> the OpenJFX repos [2] since October 2019, when OpenJFX moved >>> to GitHub using >>> the Skara tooling. >>> >>> I suggest that we adopt this policy two weeks hence, on Tue >>> 3 July. >>> >>> Concerns? >>> >>> [0] https://openjdk.org/guide/#fixing-a-bug (step 12) >>> [1] https://github.com/openjdk/jdk >>> [2] https://github.com/openjdk/jfx >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Jul 8 19:32:50 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 8 Jul 2024 19:32:50 +0000 Subject: JEP proposed to target JDK 24: 472: Prepare to Restrict the Use of JNI Message-ID: <20240708193248.3CAA573F5AB@eggemoggin.niobe.net> The following JEP is proposed to target JDK 24: 472: Prepare to Restrict the Use of JNI https://openjdk.org/jeps/472 Summary: Issue warnings about uses of the Java Native Interface (JNI) and adjust the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Application developers can avoid both current warnings and future restrictions by selectively enabling these interfaces where essential. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Monday, 15 July, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 24. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From shipilev at amazon.de Tue Jul 9 09:36:01 2024 From: shipilev at amazon.de (Aleksey Shipilev) Date: Tue, 9 Jul 2024 11:36:01 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: Hi all, TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for future maintainers, if any. Longer version: Due to historical reasons and my personal interest, I ended up being the formal maintainer for 32-bit x86 [1]. The actual maintenance work seems to be be handled by a very small group of people. Unfortunately, the cost/benefit for maintaining 32-bit x86 is much more of the "cost" rather than "benefit" today. Maintaining buildability for the port is somewhat simple, but maintaining parity with new features (Loom, FFM, Vector extensions, late GC barrier expansion, etc) is a major opportunity cost. The benefits for having 32-bit x86 port are: a) Allow OpenJDK to run on 32-bit x86 platforms. AFAICS, the x86 world has firmly moved into 64-bit realm. No new 32-bit-only x86 hardware is being manufactured. 32-bit x86 deployments are a rare sight, mostly in very old deployments. The industry support seems to dwindle down to match this reality. Windows 32-bit x86 support in OpenJDK had been already deprecated. b) Maintain and actively test at least some level of 32/64-bit cleanliness. This simplifies other 32-bit ports maintenance, where simple things would be caught by 32-bit x86 port builds and tests first. Notable port that is covered this way is ARM32. Current GHA builds ARM32 Hotspot, so we still have some level of coverage there. c) Actively test the fallback paths for JVM/JDK features that are not implemented fully on some architectures. Loom's 1:1 scheduler, FFM Fallback Linker are the examples of this. Without 32-bit x86 that we can run more or less easily on current x86 hosts, there would be less coverage for these in tests like GHA. d) Provide backport safety into releases that are still shipping 32-bit x86 binaries. I have a gut feeling that deployments for old platforms like 32-bit x86 are realistically still stuck on JDK 8. Which also means, since we don't backport lots of intrusive stuff to JDK 8, the chance of production breakage would be small as well. Backporting to more modern releases like JDK 11, 17, 21 would come with some headache for those vendors who still build 32-bit x86 there. I believe the sum of these benefits does not justify the maintenance cost, and that 32-bit x86 port has outlived its purpose. Therefore, I am stepping down as 32-bit x86 maintainer. Unless someone else steps in, this would leave the 32-bit x86 port effectively and formally unmaintained. We would still have 32-bit x86 Zero, which should still work like any other Zero implementation (slowly). Should no one take the reins for 32-bit x86 maintenance, I volunteer to do some cleanup tasks like disabling 32-bit x86 in GHA, amending build system with deprecation warnings, writing a formal deprecation JEP. Being mindful this is probably a vacation season, I would like to set a somewhat longer 4 weeks deadline for anyone to step in. To be specific, the deadline is August 9, 2024, 23:59 UTC. Thanks for reading, comments are welcome. -- -Aleksey [1] https://wiki.openjdk.org/display/HotSpot/Ports Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From adinn at redhat.com Tue Jul 9 09:42:24 2024 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 9 Jul 2024 10:42:24 +0100 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> On 09/07/2024 10:36, Aleksey Shipilev wrote: > TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for > future maintainers, if any. . . . > Thanks for reading, comments are welcome. Someone has to say it: Thank you for your heroic efforts! regards, Andrew Dinn ----------- From tanksherman27 at gmail.com Tue Jul 9 10:38:02 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 9 Jul 2024 18:38:02 +0800 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: Thanks for your efforts in maintaining the 32 bit x86 Ports! I would say sign me up since I don't like seeing supported platforms go down in flames, but I am not oblivious to the fact that maintaining an entire Port of Java (Not just with a different compiler from the usual one used to compile the JDK, which I already do for Windows) is highly likely to be far outside what I am capable of :( Just to be clear, we're talking about 32 bit Linux here? Windows 32 bit has already been deprecated and macOS doesn't seem like it had a 32 bit Port to begin with, at least from what I can see best regards, Julian From thomas.stuefe at gmail.com Tue Jul 9 10:47:49 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 9 Jul 2024 12:47:49 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> References: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> Message-ID: On Tue 9. Jul 2024 at 11:42, Andrew Dinn wrote: > On 09/07/2024 10:36, Aleksey Shipilev wrote: > > TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for > > future maintainers, if any. > . . . > > Thanks for reading, comments are welcome. > Someone has to say it: > > Thank you for your heroic efforts! > > regards, > > > Andrew Dinn > ----------- I absolutely agree. Thanks for all your work over the years. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens.limasoftware at gmail.com Tue Jul 9 11:03:27 2024 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 9 Jul 2024 13:03:27 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> Message-ID: <72437C3D-1539-4EC7-9A6F-36178E7D2213@gmail.com> > On 9. Jul 2024, at 12:47, Thomas St?fe wrote: > > > > On Tue 9. Jul 2024 at 11:42, Andrew Dinn wrote: > On 09/07/2024 10:36, Aleksey Shipilev wrote: > > TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for > > future maintainers, if any. > . . . > > Thanks for reading, comments are welcome. > Someone has to say it: > > Thank you for your heroic efforts! > > regards, > > > Andrew Dinn > ----------- > > I absolutely agree. Thanks for all your work over the years. > +1, well done Aleksey! Cheers, Mario From vladimir.kozlov at oracle.com Tue Jul 9 14:45:51 2024 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Jul 2024 07:45:51 -0700 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> References: <1920e64e-c0c2-4d88-bc6e-47c028ac1617@redhat.com> Message-ID: On 7/9/24 2:42 AM, Andrew Dinn wrote: > On 09/07/2024 10:36, Aleksey Shipilev wrote: >> TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for future maintainers, if any. > . . . >> Thanks for reading, comments are welcome. > Someone has to say it: > > Thank you for your heroic efforts! > > regards, > > > Andrew Dinn > ----------- I completely agree with Andrew. Thank you, Aleksey! Vladimir K From davidalayachew at gmail.com Wed Jul 10 01:02:03 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 9 Jul 2024 21:02:03 -0400 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: Hey, I posted this in reddit too, but I want to see what's required of someone to do this because I am genuinely considering stepping up too. I doubt that I am qualified, but if it is something that I can learn, I am willing to put in as much effort as my day job allows me. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jul 10 10:59:45 2024 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Jul 2024 06:59:45 -0400 Subject: Result: New JDK Committer: Archie Cobbs Message-ID: <17ece8ca-061d-472d-8030-e98d875a05ce@oracle.com> Voting for Archie Cobbs [1] has now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Three Vote Consensus [2], this is sufficient to approve the nomination. Best regards, Vicente [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009168.html [2] https://openjdk.java.net/projects/#committer-vote From shipilev at amazon.de Wed Jul 10 11:06:03 2024 From: shipilev at amazon.de (Aleksey Shipilev) Date: Wed, 10 Jul 2024 13:06:03 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: Hi David, On 10.07.24 03:02, David Alayachew wrote: > I posted this in reddit too, but I want to see what's required of someone to do this because I am > genuinely considering stepping up too. Noted. There are different facets of porting work. Off the top of my head, in order of growing complexity: 1. Running builds and fixing build failures. This is currently simplified by having GHA build the full Linux 32-bit builds. When the support for the port dwindles, I expect 32-bit builds to be retracted to just building Hotspot, not the full JDK. So maintainers would be exposed to more surprising failures. Speaking from before-GHA experience, I would say it takes a few hours a week to track and fix these. 2. Running tests and fixing test failures. This is currently simplified by having GHA run at least some basic tests. Quite some test failures are just tests misconfigured for 32-bit builds, like requesting too large heap size, asking for features that are not available, using flags that are not applicable to 32-bit VMs. From experience, this takes a few hours a week to maintain healthy test runs, assuming they expose no product bugs. 3. Fixing bugs. Most of the headache there are compiler/runtime parts that have arch-specific code. 32-bit x86 is a bit peculiar here, because it covers quite large spectrum of possible hardware configs. Back in the days when I was running the tests, the test configs covered UseSSE={0,1,2,3,4}, UseAVX={0,1,2,3}. x87 bugs (-XX:UseSSE=0) are the most fun. You may choose not to care, but it would also be odd to pass tests on EPYC servers with UseAVX=2, and then fail on the actual hardware in the field that does not even know what AVX is. Depending on the complexity, this can take anywhere from 1 day a week to full week of tinkering with things. There are some bugs that might take much longer to fully understand. 4. Porting features. This a major hurdle, which often requires in-depth knowledge of VM internals, and significant perseverance for working through the issues. Simple things (e.g. removing IC stubs) take a couple of hours. Complicated things (e.g. Loom ports, G1 barrier expansion) would take weeks to iron out the wrinkles. A saner path might be working out how to disable particular features on 32-bit x86 cleanly. Working on 32-bit x86 is both simpler than other arches, since there is usually an inspirational 64-bit x86 code to borrow from, and also more complicated than other arches, because it has peculiarities like not having a separate thread register, which causes massive headaches when porting low-level code. I would say properly maintaining the port at 1..3 level can take about 1 full-time engineer with prior Hotspot/JDK experience, less when you know where to cut the corners. So I would not recommend this as a starter project. For a reasonable probability of success, you need to have experience with Hotspot/JDK development, or have enough time to work it out as you go, or both. HTHS, -Aleksey Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From aph-open at littlepinkcloud.com Wed Jul 10 14:09:58 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 10 Jul 2024 15:09:58 +0100 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: On 7/10/24 12:06, Aleksey Shipilev wrote: > I would say properly maintaining the port at 1..3 level can take > about 1 full-time engineer with prior Hotspot/JDK experience, less > when you know where to cut the corners. So I would not recommend > this as a starter project. For a reasonable probability of success, > you need to have experience with Hotspot/JDK development, or have > enough time to work it out as you go, or both. One other thing that is important: 32-bit support is already broken in some ways, and especially the x86 ABI Linux is not compliant in that it calls native code with a misaligned stack pointer. This is surprisingly hard to fix. Having to keep everything working on 32-bit x86 is a drain on everyone. The back end contains 527 separate instances of #ifdef _LP64, and every one of these is a burden for maintainers. (I just had to add a few more.) It would be better for everyone to remove the 32-bit port, rather than have it half-maintained. IMHO, rather than keep 32-bit x86 going, it would make more sense to concentrate on trying to get the older 32-bit OpenJDK backport versions in good shape. I don't think that it's possible to do both without a lot of effort. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tanksherman27 at gmail.com Wed Jul 10 15:01:09 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 10 Jul 2024 23:01:09 +0800 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: You and I both don't like to see support for platforms go down, I suggest we both become maintainers of 32 bit x86 Linux and work together! :) In all seriousness, while it is sad to see another platform go, it is extremely difficult to argue against Andrew's point. The support required for a platform, especially one that has the same ISA but different "bitness" as another, is unfortunately not neatly packaged away inside platform specific files, but is spread out over the entirety of HotSpot, even in shared code. That means support for that platform ends up being everyone's responsibility, even if they aren't maintainers for that Port. This is sadly going to cause problems for everyone as a result. The only "platform" I can think of where most of the platform specific code is indeed restricted to platform specific files is Zero, actually best regards, Julian From pavel.rappo at oracle.com Wed Jul 10 22:14:50 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 10 Jul 2024 22:14:50 +0000 Subject: Result: New JDK Committer: Chen Liang Message-ID: <7EE187CD-3488-4D3C-826A-70BCAC56C5E8@oracle.com> Voting for Chen Liang [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. -Pavel [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009161.html From davidalayachew at gmail.com Wed Jul 10 22:19:57 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 10 Jul 2024 18:19:57 -0400 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: Hello all, Thanks for the responses. Yeah Julian, it crushes me to see it. I already hashed the reasons on reddit, so I won't bring them back up here. Of course, I have no shortage of motivation and perseverance. But, as a maintainer, there is a certain level of competence that is expected, and after seeing both Aleksey's and Andrew's comments, it's clear that I do not meet the bar. I guess one final question -- is there any other 32 bit port that will remain alive after this goes? Or does this mean that new versions of Java are no longer available to developers who are forcefully stuck on 32 bit machines? Thank you all for your time and help! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Wed Jul 10 22:23:35 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 10 Jul 2024 22:23:35 +0000 Subject: Result: New JDK Committer: Chen Liang In-Reply-To: <7EE187CD-3488-4D3C-826A-70BCAC56C5E8@oracle.com> References: <7EE187CD-3488-4D3C-826A-70BCAC56C5E8@oracle.com> Message-ID: Multiple people have pinged me about the typo "Committer"; it should've been "Reviewer". Sigh. It's too late for me probably. Let me resend that email with the correct subject line. Thanks. > On 10 Jul 2024, at 23:14, Pavel Rappo wrote: > > Voting for Chen Liang [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. > > -Pavel > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009161.html From pavel.rappo at oracle.com Wed Jul 10 22:26:53 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 10 Jul 2024 22:26:53 +0000 Subject: Result: New JDK Reviewer: Chen Liang Message-ID: Voting for Chen Liang [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. -Pavel [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009161.html From aph-open at littlepinkcloud.com Thu Jul 11 07:51:46 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 11 Jul 2024 08:51:46 +0100 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: <434a900c-e6e9-45d9-b4a9-1165f8c802ea@littlepinkcloud.com> On 7/10/24 23:19, David Alayachew wrote: > I guess one final question -- is there any other 32 bit port that will remain alive after this goes? Or does this mean that new versions of Java are no longer available to developers who are forcefully stuck on 32 bit machines? I think there's a stronger motivation to keep 32-bit Arm going. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu Jul 11 08:15:08 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 11 Jul 2024 10:15:08 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: <434a900c-e6e9-45d9-b4a9-1165f8c802ea@littlepinkcloud.com> References: <434a900c-e6e9-45d9-b4a9-1165f8c802ea@littlepinkcloud.com> Message-ID: On Thu, Jul 11, 2024 at 9:52?AM Andrew Haley wrote: > On 7/10/24 23:19, David Alayachew wrote: > > I guess one final question -- is there any other 32 bit port that will > remain alive after this goes? Or does this mean that new versions of Java > are no longer available to developers who are forcefully stuck on 32 bit > machines? > > I think there's a stronger motivation to keep 32-bit Arm going. > > I agree, it is widely used in embedded space. Question: would we keep zero x86 alive at least? Today, --with-target-bits=32 makes it very easy to quickly test 32-bit on our ubiquitous x64 machines. Taking that away will bitrot arm32 even more quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Jul 11 12:42:48 2024 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 11 Jul 2024 08:42:48 -0400 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: Hi, I wanted to add to what Andrew Haley wrote about the cost of maintaining the 32 bit x86 port.? A long time ago, we consolidated the template interpreter code so that there was only one source file to change when working on that code.? This required that we only use the 4 registers that the 32 bit port provided, with some conditionals for knowing r15 is the thread register for 64 bits. With new work coming in for Valhalla, restricting our use to only 4 registers is really difficult and results in poor code.? Internally, we've been talking about splitting out and moving all the 32 bit code to a new directory, which will result in almost immediate bit rot. It would be nicer to deprecate this code in favor of using the Zero based interpreter for the linux-x86 port.? We started on a JEP for that, even though it's awkward since we don't support this port at Oracle, but we want to move the code out of the way. Thanks, Coleen On 7/10/24 10:09 AM, Andrew Haley wrote: > On 7/10/24 12:06, Aleksey Shipilev wrote: > > > I would say properly maintaining the port at 1..3 level can take > > about 1 full-time engineer with prior Hotspot/JDK experience, less > > when you know where to cut the corners. So I would not recommend > > this as a starter project. For a reasonable probability of success, > > you need to have experience with Hotspot/JDK development, or have > > enough time to work it out as you go, or both. > > One other thing that is important: 32-bit support is already broken in > some ways, and especially the x86 ABI Linux is not compliant in that > it calls native code with a misaligned stack pointer. This is > surprisingly hard to fix. > > Having to keep everything working on 32-bit x86 is a drain on > everyone. The back end contains 527 separate instances of #ifdef > _LP64, and every one of these is a burden for maintainers. (I just had > to add a few more.) It would be better for everyone to remove the > 32-bit port, rather than have it half-maintained. > > IMHO, rather than keep 32-bit x86 going, it would make more sense to > concentrate on trying to get the older 32-bit OpenJDK backport > versions in good shape. I don't think that it's possible to do both > without a lot of effort. > From tanksherman27 at gmail.com Thu Jul 11 13:41:10 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 11 Jul 2024 21:41:10 +0800 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: I would imagine 32 bit x86 Zero wouldn't be that hard to maintain, and Aleksey also seems to imply that Zero for 32 bit x86 is also going to stay, quote: "We would still have 32-bit x86 Zero, which should still work like any other Zero implementation (slowly)." best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanksherman27 at gmail.com Thu Jul 11 13:56:06 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 11 Jul 2024 21:56:06 +0800 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer Message-ID: Wouldn't the removal of 32 bit Linux soon follow after deprecation? There wouldn't really be time to swap to using the Zero Interpreter on x86 if that happened best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jul 11 14:26:42 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 11 Jul 2024 16:26:42 +0200 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: Oh, good. So we keep gtests for simple tests then. On Thu, Jul 11, 2024 at 3:41?PM Julian Waters wrote: > I would imagine 32 bit x86 Zero wouldn't be that hard to maintain, and > Aleksey also seems to imply that Zero for 32 bit x86 is also going to stay, > quote: > > "We would still have 32-bit x86 Zero, which should still work like any > other Zero > implementation (slowly)." > > best regards, > Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Jul 11 16:04:16 2024 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 11 Jul 2024 12:04:16 -0400 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: On 7/11/24 9:56 AM, Julian Waters wrote: > Wouldn't the removal of 32 bit Linux soon follow after deprecation? > There wouldn't really be time to swap to using the Zero Interpreter on > x86 if that happened > We generally wait a release between deprecation and obsolescence (removal), which would give time to switch to Zero. Coleen > best regards, > Julian From tanksherman27 at gmail.com Fri Jul 12 00:49:23 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Fri, 12 Jul 2024 08:49:23 +0800 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: Ah, I see. Although, since the Port is going to be deprecated if no one steps up to maintain it anyway, the bitrot resulting from moving the Template Interpreter code into a different directory might not matter too much. Sounds to me like it might be less work than swapping to use a different Interpreter altogether. Keeping the Template Interpreter until the Port is removed might also help prevent 32 bit Linux Java from suddenly degrading in performance, in my opinion best regards, Julian On Fri, Jul 12, 2024 at 12:04?AM wrote: > > > On 7/11/24 9:56 AM, Julian Waters wrote: > > Wouldn't the removal of 32 bit Linux soon follow after deprecation? > > There wouldn't really be time to swap to using the Zero Interpreter on > > x86 if that happened > > > We generally wait a release between deprecation and obsolescence > (removal), which would give time to switch to Zero. > > Coleen > > > best regards, > > Julian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Jul 12 11:49:51 2024 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 12 Jul 2024 07:49:51 -0400 Subject: RFC: 32-bit x86 port maintenance, stepping down as maintainer In-Reply-To: References: Message-ID: We don't have a issue filed for moving the cpu/x86 code to cpu/x86_32 (say), but if you want to do it, it's not a difficult task. All of the code there should be copied and moved, including c1/c2 MacroAssembler code. Coleen On 7/11/24 8:49 PM, Julian Waters wrote: > Ah, I see. Although, since the Port is going to be deprecated if no > one steps up to maintain it anyway, the bitrot resulting from moving > the Template Interpreter code into a different directory might not > matter too much. Sounds to me like it might be less work than swapping > to use a different Interpreter altogether. Keeping the Template > Interpreter until the Port is removed might also help prevent 32 bit > Linux Java from suddenly degrading in performance, in my opinion > > best regards, > Julian > > On Fri, Jul 12, 2024 at 12:04?AM wrote: > > > > On 7/11/24 9:56 AM, Julian Waters wrote: > > Wouldn't the removal of 32 bit Linux soon follow after deprecation? > > There wouldn't really be time to swap to using the Zero > Interpreter on > > x86 if that happened > > > We generally wait a release between deprecation and obsolescence > (removal), which would give time to switch to Zero. > > Coleen > > > best regards, > > Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Fri Jul 12 12:13:27 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Fri, 12 Jul 2024 12:13:27 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <8751C30A-E436-471A-9F5C-6A67FA50A6C6@amazon.de> Vote: yes > On Jul 5, 2024, at 9:03?AM, Thomas Stuefe wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From mark.reinhold at oracle.com Tue Jul 16 12:52:07 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 16 Jul 2024 12:52:07 +0000 Subject: JEP proposed to target JDK 24: 472: Prepare to Restrict the Use of JNI In-Reply-To: <20240708193248.3CAA573F5AB@eggemoggin.niobe.net> References: <20240708193248.3CAA573F5AB@eggemoggin.niobe.net> Message-ID: <20240716085206.316496401@eggemoggin.niobe.net> 2024/7/8 15:32:50 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 24: > > 472: Prepare to Restrict the Use of JNI > https://openjdk.org/jeps/472 > > Summary: Issue warnings about uses of the Java Native Interface (JNI) > and adjust the Foreign Function & Memory (FFM) API to issue warnings > in a consistent manner. All such warnings aim to prepare developers > for a future release that ensures integrity by default by uniformly > restricting JNI and the FFM API. Application developers can avoid both > current warnings and future restrictions by selectively enabling these > interfaces where essential. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Monday, 15 July, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 24. Hearing no objections, I?ve targeted this JEP to JDK 24. - Mark From raffaello.giulietti at oracle.com Wed Jul 17 13:31:05 2024 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 17 Jul 2024 15:31:05 +0200 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes On 2024-07-05 09:03, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden > in the past, more recently on OpenJDK proper, contributing 25 patches so > far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] > https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote > From roger.riggs at oracle.com Wed Jul 17 13:50:36 2024 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 17 Jul 2024 09:50:36 -0400 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <7f62cd4e-76aa-4e80-9458-87f01edd5b6a@oracle.com> Vote: yes On 7/5/24 3:03 AM, Thomas Stuefe wrote: > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. From martin.doerr at sap.com Wed Jul 17 14:50:22 2024 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 17 Jul 2024 14:50:22 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Thomas Stuefe Datum: Freitag, 5. Juli 2024 um 09:04 An: jdk-dev at openjdk.org Betreff: CFV: New JDK Committer: Sonia Zaldana Calles Some people who received this message don't often get email from tstuefe at redhat.com. Learn why this is important I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. Votes are due by July 22, 2024. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thomas Stuefe [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated [2] https://openjdk.org/census#jdk [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Jul 18 16:00:05 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 18 Jul 2024 16:00:05 +0000 Subject: JDK 23 is now in Rampdown Phase Two Message-ID: <20240718160000.C0A48743BCB@eggemoggin.niobe.net> Per the JDK 23 schedule [1], we are now in Rampdown Phase Two. The overall feature set is frozen. No further JEPs will be targeted to this release. Per the JDK Release Process [2] we now turn our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval [4], but the bar is now extraordinarily high. If you?re responsible for any of the bugs on the RDP 2 candidate-bug list [5] or on the list of fixes not backported from the main line [6], then please see JEP 3 for guidance on how to handle them. - Mark [1] https://openjdk.org/projects/jdk/23/#Schedule [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process [5] https://j.mp/jdk-rdp-2 [6] https://bugs.openjdk.org/issues/?filter=44264 From kim.barrett at oracle.com Fri Jul 19 13:47:20 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Jul 2024 13:47:20 +0000 Subject: CFV: New JDK Committer: Sonia Zaldana Calles In-Reply-To: References: Message-ID: <8A1C509C-E250-4470-B4BE-BD1FC515B817@oracle.com> vote: yes > On Jul 5, 2024, at 3:03 AM, Thomas Stuefe wrote: > > I hereby nominate Sonia Zaldana Calles (szaldana) to JDK Committer. > > Sonia is part of the JVM team at Red Hat. She worked on project Leyden in the past, more recently on OpenJDK proper, contributing 25 patches so far [1], mainly in hotspot runtime, platform porting, and serviceability. > > Votes are due by July 22, 2024. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thomas Stuefe > > > [1] https://github.com/pulls?q=is%3Apr+repo%3Aopenjdk%2Fjdk+author%3ASoniaZaldana+archived%3Afalse+is%3Aclosed+label%3Aintegrated > [2] https://openjdk.org/census#jdk > [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From tstuefe at redhat.com Mon Jul 22 14:24:22 2024 From: tstuefe at redhat.com (Thomas Stuefe) Date: Mon, 22 Jul 2024 16:24:22 +0200 Subject: Result: New JDK Committer: Sonia Zaldana Calles Message-ID: Voting for Sonia Zaldana Calles [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Thomas Stuefe [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009203.html [2] https://openjdk.java.net/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.boothe at gmail.com Wed Jul 24 20:13:27 2024 From: andy.boothe at gmail.com (Andy Boothe) Date: Wed, 24 Jul 2024 15:13:27 -0500 Subject: Very long response headers and java.net.http.HttpClient? Message-ID: Hello, I'm documenting some guidelines for using java.net.http.HttpClient defensively for my team. For example: "Always set a request timeout", "Don't assume HTTP response entities are small and/or will fit in memory", etc. One guideline I'd like to document is "Set a maximum for HTTP response header size." However, I can't seem to find a way to set that limit, either in documentation or in OpenJDK code. I tried my best to search the archives for this mailing list for any mentions, but came up empty. To make sure my head is on straight and there isn't an undocumented limit set by default, I wrote the attached (very quick and dirty) client and server programs. LongResponseHeaderDemoServer opens a raw server socket and reads (what it assumes is) a well-formed HTTP request, and then prints an HTTP response which includes a response header of infinite length. LongResponseHeaderDemoHttpClient uses java.net.http.HttpClient to make a request and print the response body. When I run LongResponseHeaderDemoServer in one terminal and make a curl request to the server in another terminal, this is what curl spits out: $ curl -vvv -D - http://localhost:3000 * Host localhost:3000 was resolved. * IPv6: ::1 * IPv4: 127.0.0.1 * Trying [::1]:3000... * Connected to localhost (::1) port 3000 > GET / HTTP/1.1 > Host: localhost:3000 > User-Agent: curl/8.6.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Content-Type: text/plain Content-Type: text/plain < Connection: close Connection: close < Content-Length: 3 Content-Length: 3 * Closing connection curl: (100) A value or data field grew larger than allowed So curl detects the long response header and bails out. Safe and sane. However, when I run LongResponseHeaderDemoServer in one terminal and run LongResponseHeaderDemoHttpClient in another terminal, this is what happens: $ java LongResponseHeaderDemoHttpClient Exception in thread "main" java.io.IOException: Requested array size exceeds VM limit at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:966) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) at LongResponseHeaderDemoHttpClient.main(LongResponseHeaderDemoHttpClient .java:13) Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.base/java.util.Arrays.copyOf(Arrays.java:3541) at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:242) at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:806) at java.base/java.lang.StringBuilder.append(StringBuilder.java:246) at java.net.http/jdk.internal.net.http.Http1HeaderParser.readResumeHeader(Http1HeaderParser.java:250) at java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:605) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:536) at java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:527) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:583) at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:233) at java.net.http/jdk.internal.net.http.Http1AsyncReceiver$$Lambda/0x00000008010dbd50.run(Unknown Source) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.runWith(Thread.java:1596) at java.base/java.lang.Thread.run(Thread.java:1583) Ostensibly, HttpClient just keeps on reading the never-ending header until it OOMs. This seems to confirm that there is no default limit to header size. It also seems like A Very Bad Thing to me. This suggests that any time a program makes an HTTP request to an untrusted source using HttpClient, for example when crawling the web, they are at risk of an OOM. For grins, I also wrote an application LongResponseHeaderDemoHttpURLConnection that does the same thing as LongResponseHeaderDemoHttpClient, just using HttpURLConnection instead of HttpClient. When I run LongResponseHeaderDemoServer in one terminal and LongResponseHeaderDemoHttpURLConnection in another terminal, this is what happens: $ java LongResponseHeaderDemoHttpURLConnection Exception in thread "main" java.lang.NegativeArraySizeException: -1610612736 at java.base/sun.net.www.MessageHeader.mergeHeader(MessageHeader.java:526) at java.base/sun.net.www.MessageHeader.parseHeader(MessageHeader.java:481) at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:804) at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:726) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1688) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) at java.base/java.net.URL.openStream(URL.java:1161) at LongResponseHeaderDemoHttpURLConnection.main( LongResponseHeaderDemoHttpURLConnection.java:12) So HttpURLConnection doesn't handle things gracefully either, but at least it doesn't OOM. That seems like a bug, too, but perhaps less severe. For reference, here's my java version: $ java -version openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Corretto-21.0.2.13.1 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Corretto-21.0.2.13.1 (build 21.0.2+13-LTS, mixed mode, sharing) Can anyone check my work, and maybe reproduce? And ideally, can someone with more knowledge than me about java.net.http.HttpClient and/or java.net.HttpURLConnection please comment? Is this real, or have I made a mistake somewhere along the way? If it's real, what's next? A bug report? Andy Boothe *Email*: andy.boothe at gmail.com *Mobile*: (979) 574-1089 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoHttpClient.java Type: application/octet-stream Size: 587 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoHttpURLConnection.java Type: application/octet-stream Size: 508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoServer.java Type: application/octet-stream Size: 1687 bytes Desc: not available URL: From pavel.rappo at oracle.com Wed Jul 24 21:30:44 2024 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 24 Jul 2024 21:30:44 +0000 Subject: Very long response headers and java.net.http.HttpClient? In-Reply-To: References: Message-ID: <5621CDEA-6AFD-4C0B-8ED7-FC400D8E19EB@oracle.com> A proper list would be net-dev at openjdk.java.net. > On 24 Jul 2024, at 21:13, Andy Boothe wrote: > > Hello, > > I'm documenting some guidelines for using java.net.http.HttpClient defensively for my team. For example: "Always set a request timeout", "Don't assume HTTP response entities are small and/or will fit in memory", etc. > > One guideline I'd like to document is "Set a maximum for HTTP response header size." However, I can't seem to find a way to set that limit, either in documentation or in OpenJDK code. > > I tried my best to search the archives for this mailing list for any mentions, but came up empty. > > To make sure my head is on straight and there isn't an undocumented limit set by default, I wrote the attached (very quick and dirty) client and server programs. LongResponseHeaderDemoServer opens a raw server socket and reads (what it assumes is) a well-formed HTTP request, and then prints an HTTP response which includes a response header of infinite length. LongResponseHeaderDemoHttpClient uses java.net.http.HttpClient to make a request and print the response body. > > When I run LongResponseHeaderDemoServer in one terminal and make a curl request to the server in another terminal, this is what curl spits out: > > $ curl -vvv -D - http://localhost:3000 > * Host localhost:3000 was resolved. > * IPv6: ::1 > * IPv4: 127.0.0.1 > * Trying [::1]:3000... > * Connected to localhost (::1) port 3000 > > GET / HTTP/1.1 > > Host: localhost:3000 > > User-Agent: curl/8.6.0 > > Accept: */* > > > < HTTP/1.1 200 OK > HTTP/1.1 200 OK > < Content-Type: text/plain > Content-Type: text/plain > < Connection: close > Connection: close > < Content-Length: 3 > Content-Length: 3 > * Closing connection > curl: (100) A value or data field grew larger than allowed > > So curl detects the long response header and bails out. Safe and sane. > > However, when I run LongResponseHeaderDemoServer in one terminal and run LongResponseHeaderDemoHttpClient in another terminal, this is what happens: > > $ java LongResponseHeaderDemoHttpClient > Exception in thread "main" java.io.IOException: Requested array size exceeds VM limit > at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:966) > at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) > at LongResponseHeaderDemoHttpClient.main(LongResponseHeaderDemoHttpClient.java:13) > Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM limit > at java.base/java.util.Arrays.copyOf(Arrays.java:3541) > at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:242) > at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:806) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:246) > at java.net.http/jdk.internal.net.http.Http1HeaderParser.readResumeHeader(Http1HeaderParser.java:250) > at java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:605) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:536) > at java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:527) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:583) > at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:233) > at java.net.http/jdk.internal.net.http.Http1AsyncReceiver$$Lambda/0x00000008010dbd50.run(Unknown Source) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > at java.base/java.lang.Thread.runWith(Thread.java:1596) > at java.base/java.lang.Thread.run(Thread.java:1583) > > Ostensibly, HttpClient just keeps on reading the never-ending header until it OOMs. This seems to confirm that there is no default limit to header size. It also seems like A Very Bad Thing to me. This suggests that any time a program makes an HTTP request to an untrusted source using HttpClient, for example when crawling the web, they are at risk of an OOM. > > For grins, I also wrote an application LongResponseHeaderDemoHttpURLConnection that does the same thing as LongResponseHeaderDemoHttpClient, just using HttpURLConnection instead of HttpClient. When I run LongResponseHeaderDemoServer in one terminal and LongResponseHeaderDemoHttpURLConnection in another terminal, this is what happens: > > $ java LongResponseHeaderDemoHttpURLConnection > Exception in thread "main" java.lang.NegativeArraySizeException: -1610612736 > at java.base/sun.net.www.MessageHeader.mergeHeader(MessageHeader.java:526) > at java.base/sun.net.www.MessageHeader.parseHeader(MessageHeader.java:481) > at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:804) > at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:726) > at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1688) > at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > at java.base/java.net.URL.openStream(URL.java:1161) > at LongResponseHeaderDemoHttpURLConnection.main(LongResponseHeaderDemoHttpURLConnection.java:12) > > So HttpURLConnection doesn't handle things gracefully either, but at least it doesn't OOM. That seems like a bug, too, but perhaps less severe. > > For reference, here's my java version: > > $ java -version > openjdk version "21.0.2" 2024-01-16 LTS > OpenJDK Runtime Environment Corretto-21.0.2.13.1 (build 21.0.2+13-LTS) > OpenJDK 64-Bit Server VM Corretto-21.0.2.13.1 (build 21.0.2+13-LTS, mixed mode, sharing) > > Can anyone check my work, and maybe reproduce? And ideally, can someone with more knowledge than me about java.net.http.HttpClient and/or java.net.HttpURLConnection please comment? Is this real, or have I made a mistake somewhere along the way? If it's real, what's next? A bug report? > > Andy Boothe > Email: andy.boothe at gmail.com > Mobile: (979) 574-1089 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoHttpClient.java Type: application/octet-stream Size: 605 bytes Desc: LongResponseHeaderDemoHttpClient.java URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoHttpURLConnection.java Type: application/octet-stream Size: 526 bytes Desc: LongResponseHeaderDemoHttpURLConnection.java URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LongResponseHeaderDemoServer.java Type: application/octet-stream Size: 1744 bytes Desc: LongResponseHeaderDemoServer.java URL: From andy.boothe at gmail.com Wed Jul 24 21:34:01 2024 From: andy.boothe at gmail.com (Andy Boothe) Date: Wed, 24 Jul 2024 16:34:01 -0500 Subject: Very long response headers and java.net.http.HttpClient? In-Reply-To: <5621CDEA-6AFD-4C0B-8ED7-FC400D8E19EB@oracle.com> References: <5621CDEA-6AFD-4C0B-8ED7-FC400D8E19EB@oracle.com> Message-ID: Ah! Right! Thanks for that. Moving now? Andy Boothe *Email*: andy.boothe at gmail.com *Mobile*: (979) 574-1089 On Wed, Jul 24, 2024 at 4:30?PM Pavel Rappo wrote: > A proper list would be net-dev at openjdk.java.net. > > > > On 24 Jul 2024, at 21:13, Andy Boothe wrote: > > > > Hello, > > > > I'm documenting some guidelines for using java.net.http.HttpClient > defensively for my team. For example: "Always set a request timeout", > "Don't assume HTTP response entities are small and/or will fit in memory", > etc. > > > > One guideline I'd like to document is "Set a maximum for HTTP response > header size." However, I can't seem to find a way to set that limit, either > in documentation or in OpenJDK code. > > > > I tried my best to search the archives for this mailing list for any > mentions, but came up empty. > > > > To make sure my head is on straight and there isn't an undocumented > limit set by default, I wrote the attached (very quick and dirty) client > and server programs. LongResponseHeaderDemoServer opens a raw server socket > and reads (what it assumes is) a well-formed HTTP request, and then prints > an HTTP response which includes a response header of infinite length. > LongResponseHeaderDemoHttpClient uses java.net.http.HttpClient to make a > request and print the response body. > > > > When I run LongResponseHeaderDemoServer in one terminal and make a curl > request to the server in another terminal, this is what curl spits out: > > > > $ curl -vvv -D - http://localhost:3000 > > * Host localhost:3000 was resolved. > > * IPv6: ::1 > > * IPv4: 127.0.0.1 > > * Trying [::1]:3000... > > * Connected to localhost (::1) port 3000 > > > GET / HTTP/1.1 > > > Host: localhost:3000 > > > User-Agent: curl/8.6.0 > > > Accept: */* > > > > > < HTTP/1.1 200 OK > > HTTP/1.1 200 OK > > < Content-Type: text/plain > > Content-Type: text/plain > > < Connection: close > > Connection: close > > < Content-Length: 3 > > Content-Length: 3 > > * Closing connection > > curl: (100) A value or data field grew larger than allowed > > > > So curl detects the long response header and bails out. Safe and sane. > > > > However, when I run LongResponseHeaderDemoServer in one terminal and run > LongResponseHeaderDemoHttpClient in another terminal, this is what happens: > > > > $ java LongResponseHeaderDemoHttpClient > > Exception in thread "main" java.io.IOException: Requested array size > exceeds VM limit > > at > java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:966) > > at > java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) > > at > LongResponseHeaderDemoHttpClient.main(LongResponseHeaderDemoHttpClient.java:13) > > Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM > limit > > at java.base/java.util.Arrays.copyOf(Arrays.java:3541) > > at > java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:242) > > at > java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:806) > > at java.base/java.lang.StringBuilder.append(StringBuilder.java:246) > > at > java.net.http/jdk.internal.net.http.Http1HeaderParser.readResumeHeader(Http1HeaderParser.java:250) > > at > java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) > > at > java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:605) > > at > java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:536) > > at > java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:527) > > at > java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:583) > > at > java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:233) > > at > java.net.http/jdk.internal.net.http.Http1AsyncReceiver$$Lambda/0x00000008010dbd50.run(Unknown > Source) > > at > java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182) > > at > java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149) > > at > java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207) > > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > > at java.base/java.lang.Thread.runWith(Thread.java:1596) > > at java.base/java.lang.Thread.run(Thread.java:1583) > > > > Ostensibly, HttpClient just keeps on reading the never-ending header > until it OOMs. This seems to confirm that there is no default limit to > header size. It also seems like A Very Bad Thing to me. This suggests that > any time a program makes an HTTP request to an untrusted source using > HttpClient, for example when crawling the web, they are at risk of an OOM. > > > > For grins, I also wrote an application > LongResponseHeaderDemoHttpURLConnection that does the same thing as > LongResponseHeaderDemoHttpClient, just using HttpURLConnection instead of > HttpClient. When I run LongResponseHeaderDemoServer in one terminal and > LongResponseHeaderDemoHttpURLConnection in another terminal, this is what > happens: > > > > $ java LongResponseHeaderDemoHttpURLConnection > > Exception in thread "main" java.lang.NegativeArraySizeException: > -1610612736 > > at > java.base/sun.net.www.MessageHeader.mergeHeader(MessageHeader.java:526) > > at > java.base/sun.net.www.MessageHeader.parseHeader(MessageHeader.java:481) > > at > java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:804) > > at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:726) > > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1688) > > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > > at java.base/java.net.URL.openStream(URL.java:1161) > > at > LongResponseHeaderDemoHttpURLConnection.main(LongResponseHeaderDemoHttpURLConnection.java:12) > > > > So HttpURLConnection doesn't handle things gracefully either, but at > least it doesn't OOM. That seems like a bug, too, but perhaps less severe. > > > > For reference, here's my java version: > > > > $ java -version > > openjdk version "21.0.2" 2024-01-16 LTS > > OpenJDK Runtime Environment Corretto-21.0.2.13.1 (build 21.0.2+13-LTS) > > OpenJDK 64-Bit Server VM Corretto-21.0.2.13.1 (build 21.0.2+13-LTS, > mixed mode, sharing) > > > > Can anyone check my work, and maybe reproduce? And ideally, can someone > with more knowledge than me about java.net.http.HttpClient and/or > java.net.HttpURLConnection please comment? Is this real, or have I made a > mistake somewhere along the way? If it's real, what's next? A bug report? > > > > Andy Boothe > > Email: andy.boothe at gmail.com > > Mobile: (979) 574-1089 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From badalov.turxan at gmail.com Thu Jul 25 09:58:56 2024 From: badalov.turxan at gmail.com (Turkhan Badalov) Date: Thu, 25 Jul 2024 13:58:56 +0400 Subject: Should the documentation state peekFirst() as equivalent to Stack's peek()? Message-ID: Here is the table "Comparison of Stack and Deque methods" that lists equivalent Deque methods compared to Stack methods: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html At the moment, getFirst() is said to be equivalent to peek(). Since peek() doesn't throw an exception when the queue/stack is empty, peekFirst() could be a better equivalent because getFirst() throws. In fact, the documentation of the peek() method itself says that this method is equivalent to peekFirst(): https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html#peek() . If this should be posted somewhere else, please let me know. I am still new to using mailing lists. Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenshanghe at outlook.com Thu Jul 25 15:54:16 2024 From: chenshanghe at outlook.com (shanghe chen) Date: Thu, 25 Jul 2024 15:54:16 +0000 Subject: large size of [Ljdk.internal.vm.FillerElement in jmap histo Message-ID: Hi in a web service with openjdk 21.0.3 using G1GC with heap size 26GB, we recently sometimes observed a huge jump up of the oldgen like from 9GB to 20GB in about 3 minutes and then slowly returned to 9GB (which is the normal size) in about 30 minutes, checking jmap histo we found: num #instances #bytes class name (module) ------------------------------------------------------- 1: 6328181 16406573984 [Ljdk.internal.vm.FillerElement; (java.base at 21.0.3) 2: 18920559 1233399640 [Ljava.lang.Object; (java.base at 21.0.3) 3: 18813814 848534768 [B (java.base at 21.0.3) 4: 5939383 771222984 [I (java.base at 21.0.3) 5: 3093810 654462640 [J (java.base at 21.0.3) 6: 15519103 496611296 java.util.HashMap$Node (java.base at 21.0.3) 7: 17985808 431659392 java.util.Date (java.base at 21.0.3) 8: 17415598 417974352 java.util.ArrayList (java.base at 21.0.3) 9: 16857329 404575896 java.lang.String (java.base at 21.0.3) 10: 9743073 389722920 java.math.BigDecimal (java.base at 21.0.3) 11: 4410896 281417160 [Ljava.util.HashMap$Node; (java.base at 21.0.3) Any idea for why the class jdk.internal.vm.FillerElement has so large size? There seems to be less document for this class. Thanks in advanced! The jdk vendor we using is openjdk version "21.0.3" 2024-04-16 LTS OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing) And the gc otpionwe using is -Xms26g -Xmx26g -Xss300k -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=16 -XX:ConcGCThreads=8 -XX:InitiatingHeapOccupancyPercent=30 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shipilev at amazon.de Thu Jul 25 15:56:37 2024 From: shipilev at amazon.de (Aleksey Shipilev) Date: Thu, 25 Jul 2024 17:56:37 +0200 Subject: large size of [Ljdk.internal.vm.FillerElement in jmap histo In-Reply-To: References: Message-ID: On 25.07.24 17:54, shanghe chen wrote: > Hi in a web service with openjdk 21.0.3 using G1GC with heap size 26GB, we recently sometimes > observed a huge jump up of the oldgen like from 9GB to 20GB in about 3 minutes and then slowly > returned to 9GB (which is the normal size) in about 30 minutes, checking jmap histo we found: > > ?num ? ? #instances ? ? ? ? #bytes ?class name (module) > ------------------------------------------------------- > ? ?1: ? ? ? 6328181 ? ?16406573984 ?[Ljdk.internal.vm.FillerElement; (java.base at 21.0.3) > ? ?2: ? ? ?18920559 ? ? 1233399640 ?[Ljava.lang.Object; (java.base at 21.0.3) > ? ?3: ? ? ?18813814 ? ? ?848534768 ?[B (java.base at 21.0.3) > ? ?4: ? ? ? 5939383 ? ? ?771222984 ?[I (java.base at 21.0.3) > ? ?5: ? ? ? 3093810 ? ? ?654462640 ?[J (java.base at 21.0.3) > ? ?6: ? ? ?15519103 ? ? ?496611296 ?java.util.HashMap$Node (java.base at 21.0.3) > ? ?7: ? ? ?17985808 ? ? ?431659392 ?java.util.Date (java.base at 21.0.3) > ? ?8: ? ? ?17415598 ? ? ?417974352 ?java.util.ArrayList (java.base at 21.0.3) > ? ?9: ? ? ?16857329 ? ? ?404575896 ?java.lang.String (java.base at 21.0.3) > ? 10: ? ? ? 9743073 ? ? ?389722920 ?java.math.BigDecimal (java.base at 21.0.3) > ? 11: ? ? ? 4410896 ? ? ?281417160 ?[Ljava.util.HashMap$Node; (java.base at 21.0.3) > > Any idea for why the class jdk.internal.vm.FillerElement has so large size? There seems to be less > document for this class. Thanks in advanced! Those are filler arrays, they are not "real" reachable objects. See more here: https://shipilev.net/jvm/anatomy-quarks/5-tlabs-and-heap-parsability/ -Aleksey Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From chenshanghe at outlook.com Thu Jul 25 16:10:07 2024 From: chenshanghe at outlook.com (shanghe chen) Date: Thu, 25 Jul 2024 16:10:07 +0000 Subject: large size of [Ljdk.internal.vm.FillerElement in jmap histo In-Reply-To: References: Message-ID: Thanks for the helpful infomation! Yeah I am trying to understand this. it seems after jdk21 the int[] is turned to FillerArray (or FillerElement?) and I am not sure if it count into the JMX bean for monitoring the Oldgen size of G1GC or not though. ________________________________ From: Aleksey Shipilev Sent: Thursday, July 25, 2024 23:56 To: shanghe chen ; jdk-dev at openjdk.org Subject: Re: large size of [Ljdk.internal.vm.FillerElement in jmap histo On 25.07.24 17:54, shanghe chen wrote: > Hi in a web service with openjdk 21.0.3 using G1GC with heap size 26GB, we recently sometimes > observed a huge jump up of the oldgen like from 9GB to 20GB in about 3 minutes and then slowly > returned to 9GB (which is the normal size) in about 30 minutes, checking jmap histo we found: > > num #instances #bytes class name (module) > ------------------------------------------------------- > 1: 6328181 16406573984 [Ljdk.internal.vm.FillerElement; (java.base at 21.0.3) > 2: 18920559 1233399640 [Ljava.lang.Object; (java.base at 21.0.3) > 3: 18813814 848534768 [B (java.base at 21.0.3) > 4: 5939383 771222984 [I (java.base at 21.0.3) > 5: 3093810 654462640 [J (java.base at 21.0.3) > 6: 15519103 496611296 java.util.HashMap$Node (java.base at 21.0.3) > 7: 17985808 431659392 java.util.Date (java.base at 21.0.3) > 8: 17415598 417974352 java.util.ArrayList (java.base at 21.0.3) > 9: 16857329 404575896 java.lang.String (java.base at 21.0.3) > 10: 9743073 389722920 java.math.BigDecimal (java.base at 21.0.3) > 11: 4410896 281417160 [Ljava.util.HashMap$Node; (java.base at 21.0.3) > > Any idea for why the class jdk.internal.vm.FillerElement has so large size? There seems to be less > document for this class. Thanks in advanced! Those are filler arrays, they are not "real" reachable objects. See more here: https://shipilev.net/jvm/anatomy-quarks/5-tlabs-and-heap-parsability/ -Aleksey Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Jul 26 08:08:16 2024 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Jul 2024 10:08:16 +0200 Subject: large size of [Ljdk.internal.vm.FillerElement in jmap histo In-Reply-To: References: Message-ID: Hi, On 25.07.24 18:10, shanghe chen wrote: > Thanks for the helpful infomation! Yeah I am trying to understand this. > it seems after jdk21 the int[] is turned to FillerArray (or > FillerElement?) and I am not sure if it count into the JMX bean for > monitoring the Oldgen size of G1GC or not though. more information about the rationale for their introduction: https://tschatzl.github.io/2022/09/26/jdk-vm-internal-fillerarray.html Answering your question, they represent dead objects/free space within regions. However since they are not allocatable into by the application and only drive reclamation heuristics, they are considered as part of "used" in MemoryMXBeans. This is the same behavior as the previous int[] arrays. Hth, Thomas From philip.race at oracle.com Mon Jul 29 21:13:43 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 29 Jul 2024 14:13:43 -0700 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) Message-ID: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> I hereby nominate Abhishek Kumar (abhiscxk [1]) to the role of JDK Project Reviewer. Abhishek is currently a JDK committer, and has been a member of the Java client team at Oracle for little over 2 years, contributing fixes mainly in the Swing UI libraries and related Accessibility code. Abhishek has made 68 contributions [2] to JDK and has already been very active in reviewing changes in the client libs area. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 22:00 UTC on 12th August 2024 -Phil. [1] https://openjdk.org/census#abhiscxk [2] $ git log --author 'abhiscxk at openjdk.org' --format='%h %s' 2fc7eb44a01 8155030: The Menu Mnemonics are always displayed for GTK LAF 9ef86da5f8e 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 301bd708565 8311110: multichar warning in WinAccessBridge.cpp 054362abe04 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location 5dcb7a627e1 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F fb45bab8e15 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F 8298153: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194 b9a142a2243 8226990: GTK & Nimbus LAF: Tabbed pane's background color is not expected one when change the opaque checkbox. eb60822a45e 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+ 528efe206d5 8328484: Convert and Opensource few JFileChooser applet test to main 38e3cda4420 8328670: Automate and open source few closed manual applet test 256d48b1969 8327980: Convert javax/swing/JToggleButton/4128979/bug4128979.java applet test to main 65d9f119c40 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main 5f2a92d954c 8328244: Convert javax/swing/JSlider/6742358/bug6742358.java applet test to main c01095c0c9d 8328262: Convert javax/swing/JSplitPane/8132123/bug8132123.java applet test to main 86f17447362 8328248: Convert javax/swing/JSlider/6587742/bug6587742.java applet test to main 5249cc0a79f 8328087: Automate javax/swing/JTable/TAB/TAB.java applet test f6390e5f801 8328089: Automate javax/swing/JTable/4222153/bug4222153.java applet test 49ce85fae9f 8327874: Convert javax/swing/JTree/4314199/bug4314199.java applet test to main a4a5196351a 8327872: Convert javax/swing/JToolTip/4644444/bug4644444.java applet test to main 96bfe613c31 8326458: Menu mnemonics don't toggle in Windows LAF when F10 is pressed 82a63a03c01 8258979: The image didn't show correctly with GTK LAF 4ef24e25963 8319938: TestFileChooserSingleDirectorySelection.java fails with "getSelectedFiles returned empty array" ed5b8c3a7bb 8225220: When the Tab Policy is checked,the scroll button direction displayed incorrectly. cb95e393b63 8224261: JProgressBar always with border painted around it de51aa19d6a 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox 24bc5bd104b 8318104: macOS 10.13 check in TabButtonAccessibility.m can be removed 9f5d2b947f7 8316285: Opensource JButton manual tests bfbc41c1f17 8315741: Open source few swing JFormattedTextField and JPopupMenu tests 0775bf2f037 8316106: Open source few swing JInternalFrame and JMenuBar tests fecd2fd8f26 8315898: Open source swing JMenu tests bb6b3f2486b 8315761: Open source few swing JList and JMenuBar tests fe5ef5f20dc 8315677: Open source few swing JFileChooser and other tests 56b8db11c35 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF c1f4595e64b 8311160: [macOS, Accessibility] VoiceOver: No announcements on JRadioButtonMenuItem and JCheckBoxMenuItem 73491fa452e 8306996: Open source Swing MenuItem related tests 82a8e91ef7c 8306489: Open source AWT List related tests 41ba05e450e 8306850: Open source AWT Model related tests 732179ca84e 8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests ed1ebd242a4 8306652: Open source AWT MenuItem related tests 0ec3d2e3636 7124527: [macosx] SwingSet2, label is not read by VoiceOver when focus is on textfield for Internalframe and Table demo. ecec611af6c 8283404: [macos] a11y : Screen magnifier does not show JMenu name 97649489d07 8273986: JEditorPane HTML Demo - Accessibility issues eefbaa29567 8283400: [macos] a11y : Screen magnifier does not reflect JRadioButton value change 07d57531726 8300168: Typo in AccessibleJTableHeaderEntry javadoc 0abb87a488e 8299227: host `exif.org` not found in link in doc comment c4449224bbb 8218474: JComboBox display issue with GTKLookAndFeel 578c287a68f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF 2ee34f14880 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native ce048e7cb55 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. 20844511939 8078471: Backspace does not work in JFileChooser with GTK L&F 5795c760db5 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug 4a68210d9f6 6972078: Can not select single directory with GTKLookAndFeel $ git log --author 'abhishek.cx.kumar at oracle.com' --format='%h %s' 3b3438752cb 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB 9d0009e92b7 6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea. 5652030f168 8292376: A few Swing methods use inheritDoc on exceptions which are not inherited b920d2999fe 8271328: User is able to choose the color after disabling the color chooser. 9d6b0285f53 8234315: GTK LAF does not gray out disabled JMenu a92c1ff7009 8287912: GTK L&F : Background of tree icons are red 3677b55b457 6391806: JLabel and AbstractButton's imageUpdate method should be better specified b0db33333a9 8288528: broken links in java.desktop [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From philip.race at oracle.com Mon Jul 29 21:17:04 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 29 Jul 2024 14:17:04 -0700 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) In-Reply-To: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> References: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> Message-ID: <358ed9c2-2af3-4727-b399-153fc603e45f@oracle.com> Vote: yes -phil. From jayathirth.d.v at oracle.com Tue Jul 30 02:54:47 2024 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Tue, 30 Jul 2024 02:54:47 +0000 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) In-Reply-To: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> References: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> Message-ID: Vote : Yes From: jdk-dev on behalf of Philip Race Date: Tuesday, 30 July 2024 at 2:44?AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) I hereby nominate Abhishek Kumar (abhiscxk [1]) to the role of JDK Project Reviewer. Abhishek is currently a JDK committer, and has been a member of the Java client team at Oracle for little over 2 years, contributing fixes mainly in the Swing UI libraries and related Accessibility code. Abhishek has made 68 contributions [2] to JDK and has already been very active in reviewing changes in the client libs area. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 22:00 UTC on 12th August 2024 -Phil. [1] https://openjdk.org/census#abhiscxk [2] $ git log --author 'abhiscxk at openjdk.org' --format='%h %s' 2fc7eb44a01 8155030: The Menu Mnemonics are always displayed for GTK LAF 9ef86da5f8e 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 301bd708565 8311110: multichar warning in WinAccessBridge.cpp 054362abe04 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location 5dcb7a627e1 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F fb45bab8e15 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F 8298153: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194 b9a142a2243 8226990: GTK & Nimbus LAF: Tabbed pane's background color is not expected one when change the opaque checkbox. eb60822a45e 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+ 528efe206d5 8328484: Convert and Opensource few JFileChooser applet test to main 38e3cda4420 8328670: Automate and open source few closed manual applet test 256d48b1969 8327980: Convert javax/swing/JToggleButton/4128979/bug4128979.java applet test to main 65d9f119c40 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main 5f2a92d954c 8328244: Convert javax/swing/JSlider/6742358/bug6742358.java applet test to main c01095c0c9d 8328262: Convert javax/swing/JSplitPane/8132123/bug8132123.java applet test to main 86f17447362 8328248: Convert javax/swing/JSlider/6587742/bug6587742.java applet test to main 5249cc0a79f 8328087: Automate javax/swing/JTable/TAB/TAB.java applet test f6390e5f801 8328089: Automate javax/swing/JTable/4222153/bug4222153.java applet test 49ce85fae9f 8327874: Convert javax/swing/JTree/4314199/bug4314199.java applet test to main a4a5196351a 8327872: Convert javax/swing/JToolTip/4644444/bug4644444.java applet test to main 96bfe613c31 8326458: Menu mnemonics don't toggle in Windows LAF when F10 is pressed 82a63a03c01 8258979: The image didn't show correctly with GTK LAF 4ef24e25963 8319938: TestFileChooserSingleDirectorySelection.java fails with "getSelectedFiles returned empty array" ed5b8c3a7bb 8225220: When the Tab Policy is checked,the scroll button direction displayed incorrectly. cb95e393b63 8224261: JProgressBar always with border painted around it de51aa19d6a 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox 24bc5bd104b 8318104: macOS 10.13 check in TabButtonAccessibility.m can be removed 9f5d2b947f7 8316285: Opensource JButton manual tests bfbc41c1f17 8315741: Open source few swing JFormattedTextField and JPopupMenu tests 0775bf2f037 8316106: Open source few swing JInternalFrame and JMenuBar tests fecd2fd8f26 8315898: Open source swing JMenu tests bb6b3f2486b 8315761: Open source few swing JList and JMenuBar tests fe5ef5f20dc 8315677: Open source few swing JFileChooser and other tests 56b8db11c35 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF c1f4595e64b 8311160: [macOS, Accessibility] VoiceOver: No announcements on JRadioButtonMenuItem and JCheckBoxMenuItem 73491fa452e 8306996: Open source Swing MenuItem related tests 82a8e91ef7c 8306489: Open source AWT List related tests 41ba05e450e 8306850: Open source AWT Model related tests 732179ca84e 8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests ed1ebd242a4 8306652: Open source AWT MenuItem related tests 0ec3d2e3636 7124527: [macosx] SwingSet2, label is not read by VoiceOver when focus is on textfield for Internalframe and Table demo. ecec611af6c 8283404: [macos] a11y : Screen magnifier does not show JMenu name 97649489d07 8273986: JEditorPane HTML Demo - Accessibility issues eefbaa29567 8283400: [macos] a11y : Screen magnifier does not reflect JRadioButton value change 07d57531726 8300168: Typo in AccessibleJTableHeaderEntry javadoc 0abb87a488e 8299227: host `exif.org` not found in link in doc comment c4449224bbb 8218474: JComboBox display issue with GTKLookAndFeel 578c287a68f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF 2ee34f14880 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native ce048e7cb55 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. 20844511939 8078471: Backspace does not work in JFileChooser with GTK L&F 5795c760db5 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug 4a68210d9f6 6972078: Can not select single directory with GTKLookAndFeel $ git log --author 'abhishek.cx.kumar at oracle.com' --format='%h %s' 3b3438752cb 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB 9d0009e92b7 6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea. 5652030f168 8292376: A few Swing methods use inheritDoc on exceptions which are not inherited b920d2999fe 8271328: User is able to choose the color after disabling the color chooser. 9d6b0285f53 8234315: GTK LAF does not gray out disabled JMenu a92c1ff7009 8287912: GTK L&F : Background of tree icons are red 3677b55b457 6391806: JLabel and AbstractButton's imageUpdate method should be better specified b0db33333a9 8288528: broken links in java.desktop [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jul 30 03:06:17 2024 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 30 Jul 2024 08:36:17 +0530 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) In-Reply-To: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> References: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> Message-ID: <9de15a00-e565-408e-898d-c0de83b9f5fc@oracle.com> Vote: yes Regards Prasanta On 30-07-2024 02:43, Philip Race wrote: > I hereby nominate Abhishek Kumar (abhiscxk [1]) to the role of JDK > Project Reviewer. > > Abhishek is currently a JDK committer, and has been a member of the > Java client team at Oracle for little over 2 years, > contributing fixes mainly in the Swing UI libraries and related > Accessibility code. > > Abhishek has made 68 contributions [2] to JDK and has already been > very active in reviewing changes in the client libs area. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 22:00 UTC on 12th August 2024 > > -Phil. > > > [1] https://openjdk.org/census#abhiscxk > > [2] > $ git log --author 'abhiscxk at openjdk.org' --format='%h %s' > 2fc7eb44a01 8155030: The Menu Mnemonics are always displayed for GTK LAF > 9ef86da5f8e 8334170: bug6492108.java test failed with exception Image > comparison failed at (0, 0) for image 4 > 301bd708565 8311110: multichar warning in WinAccessBridge.cpp > 054362abe04 8332550: [macos] Voice Over: > java.awt.IllegalComponentStateException: component must be showing on > the screen to determine its location > 5dcb7a627e1 8160755: bug6492108.java test fails with exception Image > comparison failed at (0, 0) for image 4 in GTK L&F > fb45bab8e15 8075917: The regression-swing case failed as the text on > label is not painted red with the GTK L&F 8298153: Colored text is not > shown on disabled checkbox and radio button with GTK LAF for bug4314194 > b9a142a2243 8226990: GTK & Nimbus LAF: Tabbed pane's background color > is not expected one when change the opaque checkbox. > eb60822a45e 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled > and disabled ComboBox does not match in these LAFs: GTK+ > 528efe206d5 8328484: Convert and Opensource few JFileChooser applet > test to main > 38e3cda4420 8328670: Automate and open source few closed manual applet > test > 256d48b1969 8327980: Convert > javax/swing/JToggleButton/4128979/bug4128979.java applet test to main > 65d9f119c40 8328328: Convert > javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main > 5f2a92d954c 8328244: Convert > javax/swing/JSlider/6742358/bug6742358.java applet test to main > c01095c0c9d 8328262: Convert > javax/swing/JSplitPane/8132123/bug8132123.java applet test to main > 86f17447362 8328248: Convert > javax/swing/JSlider/6587742/bug6587742.java applet test to main > 5249cc0a79f 8328087: Automate javax/swing/JTable/TAB/TAB.java applet test > f6390e5f801 8328089: Automate > javax/swing/JTable/4222153/bug4222153.java applet test > 49ce85fae9f 8327874: Convert javax/swing/JTree/4314199/bug4314199.java > applet test to main > a4a5196351a 8327872: Convert > javax/swing/JToolTip/4644444/bug4644444.java applet test to main > 96bfe613c31 8326458: Menu mnemonics don't toggle in Windows LAF when > F10 is pressed > 82a63a03c01 8258979: The image didn't show correctly with GTK LAF > 4ef24e25963 8319938: TestFileChooserSingleDirectorySelection.java > fails with "getSelectedFiles returned empty array" > ed5b8c3a7bb 8225220: When the Tab Policy is checked,the scroll button > direction displayed incorrectly. > cb95e393b63 8224261: JProgressBar always with border painted around it > de51aa19d6a 8283214: [macos] Screen magnifier does not show the > magnified text for JcomboBox > 24bc5bd104b 8318104: macOS 10.13 check in TabButtonAccessibility.m can > be removed > 9f5d2b947f7 8316285: Opensource JButton manual tests > bfbc41c1f17 8315741: Open source few swing JFormattedTextField and > JPopupMenu tests > 0775bf2f037 8316106: Open source few swing JInternalFrame and JMenuBar > tests > fecd2fd8f26 8315898: Open source swing JMenu tests > bb6b3f2486b 8315761: Open source few swing JList and JMenuBar tests > fe5ef5f20dc 8315677: Open source few swing JFileChooser and other tests > 56b8db11c35 8258970: Disabled JPasswordField foreground color is wrong > with GTK LAF > c1f4595e64b 8311160: [macOS, Accessibility] VoiceOver: No > announcements on JRadioButtonMenuItem and JCheckBoxMenuItem > 73491fa452e 8306996: Open source Swing MenuItem related tests > 82a8e91ef7c 8306489: Open source AWT List related tests > 41ba05e450e 8306850: Open source AWT Model related tests > 732179ca84e 8306409: Open source AWT KeyBoardFocusManger, > LightWeightComponent related tests > ed1ebd242a4 8306652: Open source AWT MenuItem related tests > 0ec3d2e3636 7124527: [macosx] SwingSet2, label is not read by > VoiceOver when focus is on textfield for Internalframe and Table demo. > ecec611af6c 8283404: [macos] a11y : Screen magnifier does not show > JMenu name > 97649489d07 8273986: JEditorPane HTML Demo - Accessibility issues > eefbaa29567 8283400: [macos] a11y : Screen magnifier does not reflect > JRadioButton value change > 07d57531726 8300168: Typo in AccessibleJTableHeaderEntry javadoc > 0abb87a488e 8299227: host `exif.org` not found in link in doc comment > c4449224bbb 8218474: JComboBox display issue with GTKLookAndFeel > 578c287a68f 8081507: Open or Save button in JFileChooser has OK title > in GTK LaF > 2ee34f14880 4912623: GTK L&F: Folder list of the JFileChooser is > allowing multiple selection unlike native > ce048e7cb55 8295006: Colored text is not shown on disabled checkbox > and radio button with GTK LAF for bug4314194. > 20844511939 8078471: Backspace does not work in JFileChooser with GTK L&F > 5795c760db5 8296222: SwingEventMonitor - installListeners(Component , > int ) - CELLEDITOR - bug > 4a68210d9f6 6972078: Can not select single directory with GTKLookAndFeel > > $ git log --author 'abhishek.cx.kumar at oracle.com' --format='%h %s' > 3b3438752cb 8288882: JFileChooser - empty (0 bytes) file is displayed > as 1 KB > 9d0009e92b7 6777156: GTK L&F: JFileChooser can jump beyond root > directory in combobox and selection textarea. > 5652030f168 8292376: A few Swing methods use inheritDoc on exceptions > which are not inherited > b920d2999fe 8271328: User is able to choose the color after disabling > the color chooser. > 9d6b0285f53 8234315: GTK LAF does not gray out disabled JMenu > a92c1ff7009 8287912: GTK L&F : Background of tree icons are red > 3677b55b457 6391806: JLabel and AbstractButton's imageUpdate method > should be better specified > b0db33333a9 8288528: broken links in java.desktop > > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#reviewer-vote > From tejesh.r at oracle.com Tue Jul 30 04:15:28 2024 From: tejesh.r at oracle.com (Tejesh R) Date: Tue, 30 Jul 2024 04:15:28 +0000 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) In-Reply-To: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> References: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> Message-ID: Vote: Yes -----Original Message----- From: jdk-dev On Behalf Of Philip Race Sent: 30 July 2024 02:44 To: jdk-dev at openjdk.org Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) I hereby nominate Abhishek Kumar (abhiscxk [1]) to the role of JDK Project Reviewer. Abhishek is currently a JDK committer, and has been a member of the Java client team at Oracle for little over 2 years, contributing fixes mainly in the Swing UI libraries and related Accessibility code. Abhishek has made 68 contributions [2] to JDK and has already been very active in reviewing changes in the client libs area. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 22:00 UTC on 12th August 2024 -Phil. [1] https://openjdk.org/census#abhiscxk [2] $ git log --author 'abhiscxk at openjdk.org' --format='%h %s' 2fc7eb44a01 8155030: The Menu Mnemonics are always displayed for GTK LAF 9ef86da5f8e 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 301bd708565 8311110: multichar warning in WinAccessBridge.cpp 054362abe04 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location 5dcb7a627e1 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F fb45bab8e15 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F 8298153: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194 b9a142a2243 8226990: GTK & Nimbus LAF: Tabbed pane's background color is not expected one when change the opaque checkbox. eb60822a45e 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+ 528efe206d5 8328484: Convert and Opensource few JFileChooser applet test to main 38e3cda4420 8328670: Automate and open source few closed manual applet test 256d48b1969 8327980: Convert javax/swing/JToggleButton/4128979/bug4128979.java applet test to main 65d9f119c40 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main 5f2a92d954c 8328244: Convert javax/swing/JSlider/6742358/bug6742358.java applet test to main c01095c0c9d 8328262: Convert javax/swing/JSplitPane/8132123/bug8132123.java applet test to main 86f17447362 8328248: Convert javax/swing/JSlider/6587742/bug6587742.java applet test to main 5249cc0a79f 8328087: Automate javax/swing/JTable/TAB/TAB.java applet test f6390e5f801 8328089: Automate javax/swing/JTable/4222153/bug4222153.java applet test 49ce85fae9f 8327874: Convert javax/swing/JTree/4314199/bug4314199.java applet test to main a4a5196351a 8327872: Convert javax/swing/JToolTip/4644444/bug4644444.java applet test to main 96bfe613c31 8326458: Menu mnemonics don't toggle in Windows LAF when F10 is pressed 82a63a03c01 8258979: The image didn't show correctly with GTK LAF 4ef24e25963 8319938: TestFileChooserSingleDirectorySelection.java fails with "getSelectedFiles returned empty array" ed5b8c3a7bb 8225220: When the Tab Policy is checked,the scroll button direction displayed incorrectly. cb95e393b63 8224261: JProgressBar always with border painted around it de51aa19d6a 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox 24bc5bd104b 8318104: macOS 10.13 check in TabButtonAccessibility.m can be removed 9f5d2b947f7 8316285: Opensource JButton manual tests bfbc41c1f17 8315741: Open source few swing JFormattedTextField and JPopupMenu tests 0775bf2f037 8316106: Open source few swing JInternalFrame and JMenuBar tests fecd2fd8f26 8315898: Open source swing JMenu tests bb6b3f2486b 8315761: Open source few swing JList and JMenuBar tests fe5ef5f20dc 8315677: Open source few swing JFileChooser and other tests 56b8db11c35 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF c1f4595e64b 8311160: [macOS, Accessibility] VoiceOver: No announcements on JRadioButtonMenuItem and JCheckBoxMenuItem 73491fa452e 8306996: Open source Swing MenuItem related tests 82a8e91ef7c 8306489: Open source AWT List related tests 41ba05e450e 8306850: Open source AWT Model related tests 732179ca84e 8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests ed1ebd242a4 8306652: Open source AWT MenuItem related tests 0ec3d2e3636 7124527: [macosx] SwingSet2, label is not read by VoiceOver when focus is on textfield for Internalframe and Table demo. ecec611af6c 8283404: [macos] a11y : Screen magnifier does not show JMenu name 97649489d07 8273986: JEditorPane HTML Demo - Accessibility issues eefbaa29567 8283400: [macos] a11y : Screen magnifier does not reflect JRadioButton value change 07d57531726 8300168: Typo in AccessibleJTableHeaderEntry javadoc 0abb87a488e 8299227: host `exif.org` not found in link in doc comment c4449224bbb 8218474: JComboBox display issue with GTKLookAndFeel 578c287a68f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF 2ee34f14880 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native ce048e7cb55 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. 20844511939 8078471: Backspace does not work in JFileChooser with GTK L&F 5795c760db5 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug 4a68210d9f6 6972078: Can not select single directory with GTKLookAndFeel $ git log --author 'abhishek.cx.kumar at oracle.com' --format='%h %s' 3b3438752cb 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB 9d0009e92b7 6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea. 5652030f168 8292376: A few Swing methods use inheritDoc on exceptions which are not inherited b920d2999fe 8271328: User is able to choose the color after disabling the color chooser. 9d6b0285f53 8234315: GTK LAF does not gray out disabled JMenu a92c1ff7009 8287912: GTK L&F : Background of tree icons are red 3677b55b457 6391806: JLabel and AbstractButton's imageUpdate method should be better specified b0db33333a9 8288528: broken links in java.desktop [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From omniprof at gmail.com Tue Jul 30 15:35:58 2024 From: omniprof at gmail.com (omniprof at gmail.com) Date: Tue, 30 Jul 2024 11:35:58 -0400 Subject: JEL 477 Issue Message-ID: <009e01dae296$2ced4550$86c7cff0$@gmail.com> I apologize for posting what is likely a trivial question that may be inappropriate for this list but I cannot find anywhere in my searches to explain what is going wrong. Simply put JEP 477 does not work in the pre-release version of Java 23 on a Windows 11 PC. There is a lot written that all show a similar example. >> Here is the program import module java.base; main() { println("Moose"); } >> Here is the version of Java I am running C:\dev\Onramptesting\OnRamptest\src>java --version openjdk 23-ea 2024-09-17 OpenJDK Runtime Environment (build 23-ea+34-2361) OpenJDK 64-Bit Server VM (build 23-ea+34-2361, mixed mode, sharing) >> Here I run the code with all the required switches. The errors are the same with or without Xlint C:\dev\Onramptesting\OnRamptest\src>javac --enable-preview --source 23 -Xlint:preview Main.java Main.java:1: warning: [preview] module imports are a preview feature and may be removed in a future release. import module java.base; ^ Main.java:3: error: class, interface, enum, or record expected main() { ^ Main.java:5: error: class, interface, enum, or record expected } ^ 2 errors 1 warning Note that I get the same results for -source 23 and -release 23 Trying single file: java -enable-preview Main.java does not work as well. Same result using Console or PowerShell in Windows. What am I doing wrong? Ken Fogel omniprof at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Tue Jul 30 15:43:34 2024 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 30 Jul 2024 21:13:34 +0530 Subject: JEL 477 Issue In-Reply-To: <009e01dae296$2ced4550$86c7cff0$@gmail.com> References: <009e01dae296$2ced4550$86c7cff0$@gmail.com> Message-ID: > import module java.base; > > main() { > >??? println("Moose"); > >} It appears that you are missing a "void" return type before the main() method name. As noted in the JEP-477, it should be: import module java.base; void main() { ??? println("Moose"); } -Jaikiran On 30/07/24 9:05 pm, omniprof at gmail.com wrote: > > I apologize for posting what is likely a trivial question that may be > inappropriate for this list but I cannot find anywhere in my searches > to explain what is going wrong. Simply put JEP 477 does not work in > the pre-release version of Java 23 on a Windows 11 PC. There is a lot > written that all show a similar example. > > ** > > *>> Here is the program* > > import module java.base; > > main() { > > ??? println("Moose"); > > } > > *>> Here is the version of Java I am running* > > C:\dev\Onramptesting\OnRamptest\src>java --version > > openjdk 23-ea 2024-09-17 > > OpenJDK Runtime Environment (build 23-ea+34-2361) > > OpenJDK 64-Bit Server VM (build 23-ea+34-2361, mixed mode, sharing) > > *>> Here I run the code with all the required switches. The errors are > the same with or without Xlint* > > C:\dev\Onramptesting\OnRamptest\src>javac --enable-preview --source 23 > -Xlint:preview Main.java > > Main.java:1: warning: [preview] module imports are a preview feature > and may be removed in a future release. > > import module java.base; > > ?????? ^ > > Main.java:3: error: class, interface, enum, or record expected > > main() { > > ^ > > Main.java:5: error: class, interface, enum, or record expected > > } > > ^ > > 2 errors > > 1 warning > > Note that I get the same results for ?source 23 and ?release 23 > > Trying single file: > > java ?enable-preview Main.java > > does not work as well. > > Same result using Console or PowerShell in Windows. > > What am I doing wrong? > > Ken Fogel > > omniprof at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jul 30 16:57:15 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 30 Jul 2024 18:57:15 +0200 (CEST) Subject: JEL 477 Issue In-Reply-To: References: <009e01dae296$2ced4550$86c7cff0$@gmail.com> Message-ID: <307277874.15318487.1722358635456.JavaMail.zimbra@univ-eiffel.fr> > From: "Jaikiran Pai" > To: "jdk-dev" > Sent: Tuesday, July 30, 2024 5:43:34 PM > Subject: Re: JEL 477 Issue > > import module java.base; > > main() { > > println("Moose"); > >} > It appears that you are missing a "void" return type before the main() method > name. As noted in the JEP-477, it should be: > import module java.base; > void main() { > println("Moose"); > } that said, if we want beginners to be able to use that syntax, the error message should be changed because the current message is misleading and not very helpfull (javac should recognize "main" and have a tailored error message). @Ken, you do not need to import module java.base, it's done by default and --source 23 is not needed anymore since 23. > -Jaikiran regards, R?mi > On 30/07/24 9:05 pm, [ mailto:omniprof at gmail.com | omniprof at gmail.com ] wrote: >> I apologize for posting what is likely a trivial question that may be >> inappropriate for this list but I cannot find anywhere in my searches to >> explain what is going wrong. Simply put JEP 477 does not work in the >> pre-release version of Java 23 on a Windows 11 PC. There is a lot written that >> all show a similar example. >> >> Here is the program >> import module java.base; >> main() { >> println("Moose"); >> } >> >> Here is the version of Java I am running >> C:\dev\Onramptesting\OnRamptest\src>java --version >> openjdk 23-ea 2024-09-17 >> OpenJDK Runtime Environment (build 23-ea+34-2361) >> OpenJDK 64-Bit Server VM (build 23-ea+34-2361, mixed mode, sharing) >>>> Here I run the code with all the required switches. The errors are the same with >> >> or without Xlint >> C:\dev\Onramptesting\OnRamptest\src>javac --enable-preview --source 23 >> -Xlint:preview Main.java >> Main.java:1: warning: [preview] module imports are a preview feature and may be >> removed in a future release. >> import module java.base; >> ^ >> Main.java:3: error: class, interface, enum, or record expected >> main() { >> ^ >> Main.java:5: error: class, interface, enum, or record expected >> } >> ^ >> 2 errors >> 1 warning >> Note that I get the same results for ?source 23 and ?release 23 >> Trying single file: >> java ?enable-preview Main.java >> does not work as well. >> Same result using Console or PowerShell in Windows. >> What am I doing wrong? >> Ken Fogel >> [ mailto:omniprof at gmail.com | omniprof at gmail.com ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jul 30 17:43:06 2024 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 30 Jul 2024 10:43:06 -0700 Subject: JEL 477 Issue In-Reply-To: <307277874.15318487.1722358635456.JavaMail.zimbra@univ-eiffel.fr> References: <009e01dae296$2ced4550$86c7cff0$@gmail.com> <307277874.15318487.1722358635456.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <695aa99d-84cb-4329-8687-708f630cd2c8@oracle.com> Even without special-casing `main`, the error message is misleading because it says `class, interface, enum, or record expected` and does not admit the possibility of `void` in this particular circumstance. -- Jon On 7/30/24 9:57 AM, Remi Forax wrote: > > > ------------------------------------------------------------------------ > > *From: *"Jaikiran Pai" > *To: *"jdk-dev" > *Sent: *Tuesday, July 30, 2024 5:43:34 PM > *Subject: *Re: JEL 477 Issue > > > import module java.base; > > > > main() { > > > >??? println("Moose"); > > > >} > > It appears that you are missing a "void" return type before the > main() method name. As noted in the JEP-477, it should be: > > import module java.base; > void main() { > ??? println("Moose"); > } > > > that said, if we want beginners to be able to use that syntax, the > error message should be changed because the current message is > misleading and not very helpfull (javac should recognize "main" and > have a tailored error message). > > @Ken, you do not need to import module java.base, it's done by default > and --source 23 is not needed anymore since 23. > > > -Jaikiran > > > regards, > R?mi > > > On 30/07/24 9:05 pm, omniprof at gmail.com wrote: > > I apologize for posting what is likely a trivial question that > may be inappropriate for this list but I cannot find anywhere > in my searches to explain what is going wrong. Simply put JEP > 477 does not work in the pre-release version of Java 23 on a > Windows 11 PC. There is a lot written that all show a similar > example. > > *>> Here is the program* > > import module java.base; > > main() { > > ??? println("Moose"); > > } > > *>> Here is the version of Java I am running* > > C:\dev\Onramptesting\OnRamptest\src>java --version > > openjdk 23-ea 2024-09-17 > > OpenJDK Runtime Environment (build 23-ea+34-2361) > > OpenJDK 64-Bit Server VM (build 23-ea+34-2361, mixed mode, > sharing) > > *>> Here I run the code with all the required switches. The > errors are the same with or without Xlint* > > C:\dev\Onramptesting\OnRamptest\src>javac --enable-preview > --source 23 -Xlint:preview Main.java > > Main.java:1: warning: [preview] module imports are a preview > feature and may be removed in a future release. > > import module java.base; > > ?????? ^ > > Main.java:3: error: class, interface, enum, or record expected > > main() { > > ^ > > Main.java:5: error: class, interface, enum, or record expected > > } > > ^ > > 2 errors > > 1 warning > > Note that I get the same results for ?source 23 and ?release 23 > > Trying single file: > > java ?enable-preview Main.java > > does not work as well. > > Same result using Console or PowerShell in Windows. > > What am I doing wrong? > > Ken Fogel > > omniprof at gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jul 31 13:34:12 2024 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Jul 2024 09:34:12 -0400 Subject: CFV: New JDK Committer: Ben Perez Message-ID: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> I hereby nominate Ben Perez to JDK Committer. Ben is a member of the Security Libraries team at Oracle and has contributed 16 fixes to the JDK Project [3]. He is also working on an ML-DSA implementation for Post-Quantum Cryptography [4]. Votes are due by August 14, 2024, 14:00 UTC. 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]. Sean Mullan [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=blperez01 [4] https://bugs.openjdk.org/browse/JDK-8298387 From sean.mullan at oracle.com Wed Jul 31 13:52:41 2024 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Jul 2024 09:52:41 -0400 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: <2fdb7560-32f7-4bfd-9fe7-8595fa1bc11a@oracle.com> Vote: yes On 7/31/24 9:34 AM, Sean Mullan wrote: > I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has > contributed 16 fixes to the JDK Project [3]. He is also working on an > ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387 From sean.coffey at oracle.com Wed Jul 31 14:35:26 2024 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=) Date: Wed, 31 Jul 2024 15:35:26 +0100 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <2fdb7560-32f7-4bfd-9fe7-8595fa1bc11a@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> <2fdb7560-32f7-4bfd-9fe7-8595fa1bc11a@oracle.com> Message-ID: <601fe8b2-0a41-4456-aeeb-7a0328982b07@oracle.com> Vote: yes regards, Sean. On 31/07/2024 14:52, Sean Mullan wrote: > Vote: yes > > On 7/31/24 9:34 AM, Sean Mullan wrote: >> I hereby nominate Ben Perez to JDK Committer. From eric.caspole at oracle.com Wed Jul 31 14:49:08 2024 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 31 Jul 2024 10:49:08 -0400 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: <7fd37bfb-bb29-4733-b001-893601f621ce@oracle.com> Vote: yes Eric On 7/31/24 9:34 AM, Sean Mullan wrote: > I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has > contributed 16 fixes to the JDK Project [3]. He is also working on an > ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387 From weijun.wang at oracle.com Wed Jul 31 15:19:12 2024 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 31 Jul 2024 15:19:12 +0000 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: <43F998E8-5E66-4BFF-8CA5-9B88F3A0F108@oracle.com> Vote: yes --weijun > On Jul 31, 2024, at 9:34?AM, Sean Mullan wrote: > > I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has contributed 16 fixes to the JDK Project [3]. He is also working on an ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387 From huizhe.wang at oracle.com Wed Jul 31 16:31:57 2024 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Jul 2024 09:31:57 -0700 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: <6d1e91a8-0b23-4810-b2e2-1d560d9b899a@oracle.com> Vote: yes Joe (joehw) On 7/31/24 6:34 AM, Sean Mullan wrote: > I hereby nominate Ben Perez to JDK Committer. From jamil.j.nimeh at oracle.com Wed Jul 31 16:52:16 2024 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 31 Jul 2024 09:52:16 -0700 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: <1854e416-8022-4d9e-891d-529dcee7d98e@oracle.com> Vote: yes On 7/31/2024 6:34 AM, Sean Mullan wrote: > I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has > contributed 16 fixes to the JDK Project [3]. He is also working on an > ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387 From ajit.ghaisas at oracle.com Wed Jul 31 16:56:12 2024 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 31 Jul 2024 16:56:12 +0000 Subject: CFV: New JDK Reviewer: Abhishek Kumar (abhiscxk) In-Reply-To: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> References: <2be3297e-edd2-4712-b381-e22fc2e9759a@oracle.com> Message-ID: <720BA916-850B-49E1-A1DE-59F0A350CE2A@oracle.com> Vote : Yes Regards, Ajit > On 30 Jul 2024, at 2:43?AM, Philip Race wrote: > > I hereby nominate Abhishek Kumar (abhiscxk [1]) to the role of JDK Project Reviewer. > > Abhishek is currently a JDK committer, and has been a member of the Java client team at Oracle for little over 2 years, > contributing fixes mainly in the Swing UI libraries and related Accessibility code. > > Abhishek has made 68 contributions [2] to JDK and has already been very active in reviewing changes in the client libs area. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 22:00 UTC on 12th August 2024 > > -Phil. > > > [1] https://openjdk.org/census#abhiscxk > > [2] > $ git log --author 'abhiscxk at openjdk.org' --format='%h %s' > 2fc7eb44a01 8155030: The Menu Mnemonics are always displayed for GTK LAF > 9ef86da5f8e 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 > 301bd708565 8311110: multichar warning in WinAccessBridge.cpp > 054362abe04 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location > 5dcb7a627e1 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F > fb45bab8e15 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F 8298153: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194 > b9a142a2243 8226990: GTK & Nimbus LAF: Tabbed pane's background color is not expected one when change the opaque checkbox. > eb60822a45e 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+ > 528efe206d5 8328484: Convert and Opensource few JFileChooser applet test to main > 38e3cda4420 8328670: Automate and open source few closed manual applet test > 256d48b1969 8327980: Convert javax/swing/JToggleButton/4128979/bug4128979.java applet test to main > 65d9f119c40 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main > 5f2a92d954c 8328244: Convert javax/swing/JSlider/6742358/bug6742358.java applet test to main > c01095c0c9d 8328262: Convert javax/swing/JSplitPane/8132123/bug8132123.java applet test to main > 86f17447362 8328248: Convert javax/swing/JSlider/6587742/bug6587742.java applet test to main > 5249cc0a79f 8328087: Automate javax/swing/JTable/TAB/TAB.java applet test > f6390e5f801 8328089: Automate javax/swing/JTable/4222153/bug4222153.java applet test > 49ce85fae9f 8327874: Convert javax/swing/JTree/4314199/bug4314199.java applet test to main > a4a5196351a 8327872: Convert javax/swing/JToolTip/4644444/bug4644444.java applet test to main > 96bfe613c31 8326458: Menu mnemonics don't toggle in Windows LAF when F10 is pressed > 82a63a03c01 8258979: The image didn't show correctly with GTK LAF > 4ef24e25963 8319938: TestFileChooserSingleDirectorySelection.java fails with "getSelectedFiles returned empty array" > ed5b8c3a7bb 8225220: When the Tab Policy is checked,the scroll button direction displayed incorrectly. > cb95e393b63 8224261: JProgressBar always with border painted around it > de51aa19d6a 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox > 24bc5bd104b 8318104: macOS 10.13 check in TabButtonAccessibility.m can be removed > 9f5d2b947f7 8316285: Opensource JButton manual tests > bfbc41c1f17 8315741: Open source few swing JFormattedTextField and JPopupMenu tests > 0775bf2f037 8316106: Open source few swing JInternalFrame and JMenuBar tests > fecd2fd8f26 8315898: Open source swing JMenu tests > bb6b3f2486b 8315761: Open source few swing JList and JMenuBar tests > fe5ef5f20dc 8315677: Open source few swing JFileChooser and other tests > 56b8db11c35 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF > c1f4595e64b 8311160: [macOS, Accessibility] VoiceOver: No announcements on JRadioButtonMenuItem and JCheckBoxMenuItem > 73491fa452e 8306996: Open source Swing MenuItem related tests > 82a8e91ef7c 8306489: Open source AWT List related tests > 41ba05e450e 8306850: Open source AWT Model related tests > 732179ca84e 8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests > ed1ebd242a4 8306652: Open source AWT MenuItem related tests > 0ec3d2e3636 7124527: [macosx] SwingSet2, label is not read by VoiceOver when focus is on textfield for Internalframe and Table demo. > ecec611af6c 8283404: [macos] a11y : Screen magnifier does not show JMenu name > 97649489d07 8273986: JEditorPane HTML Demo - Accessibility issues > eefbaa29567 8283400: [macos] a11y : Screen magnifier does not reflect JRadioButton value change > 07d57531726 8300168: Typo in AccessibleJTableHeaderEntry javadoc > 0abb87a488e 8299227: host `exif.org` not found in link in doc comment > c4449224bbb 8218474: JComboBox display issue with GTKLookAndFeel > 578c287a68f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF > 2ee34f14880 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native > ce048e7cb55 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. > 20844511939 8078471: Backspace does not work in JFileChooser with GTK L&F > 5795c760db5 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug > 4a68210d9f6 6972078: Can not select single directory with GTKLookAndFeel > > $ git log --author 'abhishek.cx.kumar at oracle.com' --format='%h %s' > 3b3438752cb 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB > 9d0009e92b7 6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea. > 5652030f168 8292376: A few Swing methods use inheritDoc on exceptions which are not inherited > b920d2999fe 8271328: User is able to choose the color after disabling the color chooser. > 9d6b0285f53 8234315: GTK LAF does not gray out disabled JMenu > a92c1ff7009 8287912: GTK L&F : Background of tree icons are red > 3677b55b457 6391806: JLabel and AbstractButton's imageUpdate method should be better specified > b0db33333a9 8288528: broken links in java.desktop > > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#reviewer-vote > From anthony.scarpino at oracle.com Wed Jul 31 22:13:54 2024 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 31 Jul 2024 22:13:54 +0000 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: Vote: yes > On Jul 31, 2024, at 6:34?AM, Sean Mullan wrote: > > ?I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has contributed 16 fixes to the JDK Project [3]. He is also working on an ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387 From bradford.wetmore at oracle.com Wed Jul 31 22:30:03 2024 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 31 Jul 2024 15:30:03 -0700 Subject: CFV: New JDK Committer: Ben Perez In-Reply-To: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> References: <8b8768ab-2231-45d8-8ae1-2b6d31901686@oracle.com> Message-ID: Vote:? Yes On 7/31/2024 6:34 AM, Sean Mullan wrote: > I hereby nominate Ben Perez to JDK Committer. > > Ben is a member of the Security Libraries team at Oracle and has > contributed 16 fixes to the JDK Project [3]. He is also working on an > ML-DSA implementation for Post-Quantum Cryptography [4]. > > Votes are due by August 14, 2024, 14:00 UTC. > > 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]. > > Sean Mullan > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/jdk/commits?author=blperez01 > [4] https://bugs.openjdk.org/browse/JDK-8298387