From honkar at openjdk.org  Sat Mar  1 00:00:06 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 1 Mar 2025 00:00:06 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <nWAFGMzONh6Lfnaad0xecXvVqxmLiGPLXguX7WkyEXE=.adadf8bb-6fd2-47aa-90d7-aa7152a69dcd@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
 <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
 <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA
 28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
 <pXJAY4trqd22WdLY8VkkXdyWOxPfEi546DwMN0dxBhA=.90e3dad5-7932-4a47-9ff9-8cc21e692c7e@github.com>
 <nWAFGMzONh6Lfnaad0xecXvVqxmLiGPLXguX7WkyEXE=.adadf8bb-6fd2-47aa-90d7-aa7152a69dcd@github.com>
Message-ID: <6PnbLDirNcSftNJ_AznDnKTS29aVw2E1vKYiRZw2_DA=.d50ac6fe-06cd-4847-9761-67c9c38b6143@github.com>

On Fri, 28 Feb 2025 23:44:40 GMT, Phil Race <prr at openjdk.org> wrote:

>>> Yes, there are. Does any other way create a built-in profile? No, it doesn't as far as I can see.
>> 
>> Yes, currently ProfileDeferralInfo  is the only way to create built-in profile.
>> 
>>> Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but ICC_Profile(ProfileDeferralInfo) constructor.
>> 
>> As of now we don't need the flexibility but not sure if that is something that we may require or need to consider in future. @prrace Your suggestion ?
>
> So in fact Harshitha had prototyped the constructor mechanism - but it was passing a parameter so wasn't as small a diff as the most recent alternate, because I think it rippled into changing the sub-class constructors as well, which made it less desirable.
> Another particular concern was that it was equating ProfileDeferralInfo to meaning isBuiltIn == true, which is the case today, but it is not a fundamental truth.
> And the proposal here is more direct and you don't have to go follow the bread crumbs to see exactly which profiles have this set to true.  So that is why the PR is as it is.
> Neither is "wrong" - they are just different choices based on different perceptions.
> 
> But if we can do this with changes to *just this class*, then may be .. and since I see the sub-class constructors (for RGB and Gray) call the same signature super-class constructors, then I think this should work, and it will be OK.
> I tried it on a local repo, and came up with the same changes as suggested and it least builds .. 
> So we can do it that way too, but there should be a comment somewhere that ProfileDeferralInfo is only for built-in profiles - and that in fact all built-in profiles should use it.

Thanks for the update on this discussion Phil. I'll update the code to set built-in flag in the constructor and add a comment stating - ProfileDeferralInfo to be used only for built-in profiles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1976131267

From vdyakov at openjdk.org  Sat Mar  1 00:50:53 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Sat, 1 Mar 2025 00:50:53 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
Message-ID: <Ag8iDPW0V_P2KVvfQn8dNG32SC6asa8YeUyDa-D6IW8=.d06a90fd-868f-4aee-9e85-293e9db29bfd@github.com>

On Fri, 28 Feb 2025 12:37:35 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space fix
>  - whitespace fix
>  - Copyright year update and manual test case added

@azuev-java please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2691787090

From honkar at openjdk.org  Sat Mar  1 00:52:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 1 Mar 2025 00:52:28 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v10]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <ar_gXOMLjRiLguZSqrlsB2I4_opYqO2NS_hh69aGamM=.53b09f70-bcf5-4744-85fa-e7986e4e4c7d@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  builtIn flag moved to constructor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/559fb749..483cda0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=08-09

  Stats: 34 lines in 1 file changed: 4 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Sat Mar  1 00:52:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 1 Mar 2025 00:52:28 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
 <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
 <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA
 28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
Message-ID: <uEjphDTxO8l9d7KW7_19LXPb6TM8cTV7JD0KF0dtguU=.dd254152-a08e-4a2b-9986-75b55a3ef072@github.com>

On Mon, 24 Feb 2025 19:17:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> There are other way to create a profile - directly loading it from a file (serialization)
>> `ICC_Profile.getInstance(<path to sRGB.pf or any custom profiles>); `or using the byte array representation of the profile. So the main intention here was not to tie ProfileDeferralInfo with isBuiltIn.
>
>> There are other way to create a profile - directly loading it form a file (serialization) `ICC_Profile.getInstance(<path to sRGB.pf or any custom profiles>); `or using the byte array representation of the profile. So the main intention here was not to tie ProfileDeferralInfo with isBuiltIn.
> 
> Yes, there are. Does any other way create a **built-in profile**? No, it doesn't as far as I can see.
> 
> Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but `ICC_Profile(ProfileDeferralInfo)` constructor.

@aivanov-jdk Updated the code and moved `builtIn` flag to be set in the constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1976182029

From honkar at openjdk.org  Sat Mar  1 00:52:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 1 Mar 2025 00:52:28 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <1wfT2PtTYMvOaP0wr4oAPo_gDneqo4fGch1zapRcYdw=.39f099a1-7ade-4318-ac28-38bfe1ca4ea1@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
 <1wfT2PtTYMvOaP0wr4oAPo_gDneqo4fGch1zapRcYdw=.39f099a1-7ade-4318-ac28-38bfe1ca4ea1@github.com>
Message-ID: <sK1yr8XjDm-VWYC1LTktsbzKXrfWxUE9Rw9zWtHLH5k=.108e4ca2-7f12-4b0a-a6f0-3ce2dcb0a5ba@github.com>

On Fri, 28 Feb 2025 23:45:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1170:
>> 
>>> 1168:      * @throws IllegalArgumentException if {@code tagSignature} is not a
>>> 1169:      *         signature as defined in the ICC specification.
>>> 1170:      * @throws IllegalArgumentException if a content of the {@code tagData}
>> 
>> This is an existing issue, if it's an issue: should the text say *?**the** content?* instead of *?**a** content?*? @prrace
>
> Yes.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1976182378

From honkar at openjdk.org  Sat Mar  1 01:11:45 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 1 Mar 2025 01:11:45 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  doc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/483cda0f..b6fffacf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=09-10

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From dnguyen at openjdk.org  Sat Mar  1 01:13:01 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Sat, 1 Mar 2025 01:13:01 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <L7h5gxuNr_8i1hkXUqzFmH3dI0yFuOaE3JeSeCcbOBw=.22a4b90d-382d-49e0-acda-a97af1db9bd8@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Changes requested by dnguyen (Committer).

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 57:

> 55:         SwingUtilities.invokeAndWait(() -> {
> 56:             createAndShowGUI();
> 57:         });

Suggestion:

        SwingUtilities.invokeAndWait(() -> createAndShowGUI());

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 74:

> 72:         JButton button = new JButton("Test");
> 73:         frame.getContentPane().add("South", button);
> 74:         frame.setSize(400, 400);

Is this the best frame size? I see the text area has text to output, but the full sentence isn't even shown and there's no word wrap. Can change the text to anything else, especially since the TextArea text exceeds the line char limit. There's also a lot of empty space in this test frame. So, this can be changed in a variety of ways.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 119:

> 117:                 }
> 118:             });
> 119:             if(bFlag)

Can also fix the for-loop above into:

for (int i = 0; i < 10; i++) {


And can make a lambda expression by using:

    menuitem.addActionListener(e -> {
                throw new RuntimeException(
                        "Failed: Mnemonic activated");
            });

-------------

PR Review: https://git.openjdk.org/jdk/pull/23837#pullrequestreview-2652064257
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1976192726
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1976193985
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1976190116

From duke at openjdk.org  Sat Mar  1 17:48:54 2025
From: duke at openjdk.org (Harald Kuhr)
Date: Sat, 1 Mar 2025 17:48:54 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
Message-ID: <OCgXbBy8bcQJwSfLYZbk9z8yhcmB57f7Ig2DOzAawbc=.af3707b9-5e4c-4475-8534-cb735c209ae5@github.com>

On Wed, 26 Feb 2025 09:23:47 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: trying to placate PR script
>   
>   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 182:

> 180:                 // file shows it can also sometimes be 0x60000. I've also observed it to be
> 181:                 // undefined, 0x0007, or several variations of 0x????0006. Similarly the same
> 182:                 // tag should be 0x0001 for TIFFs, but I also observed a case where it as 0x10000.

Isn't this ( 0x0001/0x0006 vs 0x1000/0x6000) just a matter of endianness in the TIFF structure? Some odd writers may also use LONG/32 bit values, even though the TiFF and Exif specs only mention SHORT/16 bit values for the compression tag. 

Compression 7 "New JPEG"  is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1976464426

From duke at openjdk.org  Sat Mar  1 18:01:05 2025
From: duke at openjdk.org (Jeremy)
Date: Sat, 1 Mar 2025 18:01:05 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <OCgXbBy8bcQJwSfLYZbk9z8yhcmB57f7Ig2DOzAawbc=.af3707b9-5e4c-4475-8534-cb735c209ae5@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
 <OCgXbBy8bcQJwSfLYZbk9z8yhcmB57f7Ig2DOzAawbc=.af3707b9-5e4c-4475-8534-cb735c209ae5@github.com>
Message-ID: <Gi2z-GJbaYd1BUPsyBt-ZbaNCrx5q8XjHIR_6oD04HI=.8771cec2-0813-4d01-8f73-7dfb38156fdd@github.com>

On Sat, 1 Mar 2025 17:46:10 GMT, Harald Kuhr <duke at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: trying to placate PR script
>>   
>>   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 182:
> 
>> 180:                 // file shows it can also sometimes be 0x60000. I've also observed it to be
>> 181:                 // undefined, 0x0007, or several variations of 0x????0006. Similarly the same
>> 182:                 // tag should be 0x0001 for TIFFs, but I also observed a case where it as 0x10000.
> 
> Isn't this ( 0x0001/0x0006 vs 0x1000/0x6000) just a matter of endianness in the TIFF structure? Some odd writers may also use LONG/32 bit values, even though the TiFF and Exif specs only mention SHORT/16 bit values for the compression tag. 
> 
> Compression 7 "New JPEG"  is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.

Yes, it probably is endianness, or endianness-related. My first design question is: should we care? Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields. If we strictly rely on the compression tag (250) instead: is that better/desirable? (That is: we could just throw an IOException in the rare case this field is missing/broken.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1976466185

From duke at openjdk.org  Sun Mar  2 00:54:12 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Sun, 2 Mar 2025 00:54:12 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails on
 CI with Compilation error
Message-ID: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>

Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.

Test passes on Linux amd64 so far:

TIME=`date +%s`;
mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/

Test results: passed: 15

-------------

Commit messages:
 - HeadlessMalfunctionTest from objectweb.asm to classfile api

Changes: https://git.openjdk.org/jdk/pull/23852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349099
  Stats: 39 lines in 2 files changed: 3 ins; 12 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23852/head:pull/23852

PR: https://git.openjdk.org/jdk/pull/23852

From duke at openjdk.org  Sun Mar  2 00:54:12 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Sun, 2 Mar 2025 00:54:12 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <6Z0hUCpb1LcLz0LxMWKSVMYRxscG1IB3GvViUmOyIt0=.d1514d6c-57d3-4a96-9318-03a7874b0d6f@github.com>

On Sun, 2 Mar 2025 00:50:30 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

@jerboaa FYI

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2692494591

From duke at openjdk.org  Sun Mar  2 14:21:45 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Sun, 2 Mar 2025 14:21:45 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:

  Removes HeadlessMalfunctionTest from ProblemList.txt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23852/files
  - new: https://git.openjdk.org/jdk/pull/23852/files/d67d632b..c6be9f4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23852/head:pull/23852

PR: https://git.openjdk.org/jdk/pull/23852

From asemenov at openjdk.org  Sun Mar  2 14:40:52 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 2 Mar 2025 14:40:52 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
Message-ID: <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>

On Fri, 28 Feb 2025 12:37:35 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space fix
>  - whitespace fix
>  - Copyright year update and manual test case added

> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.

Hello.
Was this problem observed on Windows before your changes?
If this error affects only macOS, try looking for a solution somewhere in ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m```.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2692761806

From sgehwolf at openjdk.org  Sun Mar  2 19:26:59 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Sun, 2 Mar 2025 19:26:59 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
Message-ID: <kpT7L-nO23mXbyb3FqjcLhgHvLQoepFH4rLy5OOi1sQ=.5edfe2b1-ab89-4fa4-85d3-64c9bf2d781f@github.com>

On Sun, 2 Mar 2025 14:21:45 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes HeadlessMalfunctionTest from ProblemList.txt

I can confirm the test compiles and runs fine. I've reverted [JDK-8336382](https://bugs.openjdk.org/browse/JDK-8336382) locally - product code only - and verified the test fails as expected. So +1 on the fix.

There is pre-existing code in the test harness, which can get removed now `--add-opens java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23852#pullrequestreview-2652798011

From prr at openjdk.org  Sun Mar  2 22:07:58 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 2 Mar 2025 22:07:58 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
Message-ID: <Oj-DJDFo3WuPbcFebAlS3pEU7EOS7xktycowhX40qLo=.ceafe06b-6b06-49ef-a1b7-fd9e08a92583@github.com>

On Sun, 2 Mar 2025 14:21:45 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes HeadlessMalfunctionTest from ProblemList.txt

Once bitten and all that .. I'd like to run this through our internal test system before it is pushed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2692931015

From duke at openjdk.org  Sun Mar  2 22:50:59 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Sun, 2 Mar 2025 22:50:59 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
Message-ID: <ZiMvHv4U7k_xwmgnAPhFTt_ZJZ3J0kwt9E-1zLk9Mxg=.794e8638-1708-47ff-952d-e5e621e19382@github.com>

On Sun, 2 Mar 2025 14:21:45 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes HeadlessMalfunctionTest from ProblemList.txt

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2692949207

From prr at openjdk.org  Mon Mar  3 00:33:52 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 00:33:52 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
Message-ID: <O4I64O8QjCkwnprjqFzghW_FzeeD_hSkk9AYNJCH8ss=.e369bd65-1bba-442f-9042-d5e37c844f56@github.com>

On Sun, 2 Mar 2025 14:21:45 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes HeadlessMalfunctionTest from ProblemList.txt

The test fails on Windows and macOS. In other words it passes only on Linux.

 stdout: [Transforming java.awt.GraphicsEnvironment.
isHeadless removed from java.awt.GraphicsEnvironment.
];
 stderr: [WARNING: package jdk.internal.org.objectweb.asm not in java.base
Exception in thread "main" java.lang.NoSuchMethodError: 'boolean java.awt.GraphicsEnvironment.isHeadless()'
	at java.desktop/sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:155)
	at java.desktop/sun.awt.PlatformGraphicsInfo.createToolkit(PlatformGraphicsInfo.java:43)
	at java.desktop/java.awt.Toolkit.getDefaultToolkit(Toolkit.java:580)
	at java.desktop/sun.awt.CGraphicsEnvironment.<clinit>(CGraphicsEnvironment.java:72)
	at java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:39)
	at java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:89)
	at java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:80)
	at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:102)
	at HeadlessMalfunctionTest$Runner.main(HeadlessMalfunctionTest.java:69)
]
 exitValue = 1

java.lang.RuntimeException: 'FATAL ERROR in native method: GetStaticMethodID isHeadless failed' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
	at HeadlessMalfunctionTest.main(HeadlessMalfunctionTest.java:62)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 'FATAL ERROR in native method: GetStaticMethodID isHeadless failed' missing from stdout/stderr
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'FATAL ERROR in native method: GetStaticMethodID isHeadless failed' missing from stdout/stderr

I see you did not remove the add-opens for "java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2693002591

From prr at openjdk.org  Mon Mar  3 06:02:45 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 06:02:45 GMT
Subject: RFR: 8347321: [ubsan] CGGlyphImages.m:553:30: runtime error: nan is
 outside the range of representable values of type 'unsigned long'
Message-ID: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>

The font tests that fail use non-finite or NaN float values.
In such cases, no visible rendering is expected and the NaNTransform test does pass with empty shapes, but we can filter out these invalid floats before they get to native.
The macOS class that handles the font strike can check for these and replace them.
Since you can't observe a difference unless you can get ubsan to work (not easy) and that is a build option, so not something we can use in testing, there' s no regression test update here.

-------------

Commit messages:
 - 8347321

Changes: https://git.openjdk.org/jdk/pull/23855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347321
  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23855/head:pull/23855

PR: https://git.openjdk.org/jdk/pull/23855

From psadhukhan at openjdk.org  Mon Mar  3 08:20:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 3 Mar 2025 08:20:40 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23837/files
  - new: https://git.openjdk.org/jdk/pull/23837/files/411d0461..840f59ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=00-01

  Stats: 26 lines in 1 file changed: 7 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23837/head:pull/23837

PR: https://git.openjdk.org/jdk/pull/23837

From psadhukhan at openjdk.org  Mon Mar  3 08:20:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 3 Mar 2025 08:20:40 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <lu045UcpfUD5pfDNVTmsSsFifyWJ1SUAoqzkIc6Su7I=.b897d5a0-e153-45b4-97f4-860c18281d9c@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Fix w.r.t review comments..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23837#issuecomment-2693587257

From abhiscxk at openjdk.org  Mon Mar  3 09:52:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Mar 2025 09:52:53 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <RvpMJ6hArtFzLTe9SdAU2jKztCCbof_NlxIOITPsgtg=.f1c2808d-5513-4916-b103-b999c330d628@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <RvpMJ6hArtFzLTe9SdAU2jKztCCbof_NlxIOITPsgtg=.f1c2808d-5513-4916-b103-b999c330d628@github.com>
Message-ID: <GOcqZPRO4LLflI2NGzwZGWC1EbfN2h3z7CIq5-jwNvI=.fc045342-27b0-46fb-acfe-92993daa23b2@github.com>

On Fri, 28 Feb 2025 18:35:33 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Tested the fix on macOS 15.3.1. The fix works intermittently for me. It announces percentage most of the time and then suddenly just a number.

Ohh.. that's strange. For me, the announcement is always in percentage.
I agree it should be consistent but should be ok as long as it announce the correct value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2693813039

From abhiscxk at openjdk.org  Mon Mar  3 10:02:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Mar 2025 10:02:52 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>
Message-ID: <DKISt9HQf09fylSelhvsHEasGanNAMhTQoyfuUPJgOE=.bcc1bc89-a8c8-421b-b3a0-ea554fef7201@github.com>

On Sun, 2 Mar 2025 14:37:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
> 
> Hello. Was this problem observed on Windows before your changes? 

No, this issue observed only on macOS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2693840800

From abhiscxk at openjdk.org  Mon Mar  3 10:05:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Mar 2025 10:05:51 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
Message-ID: <u8FrUVmOP1Pl8dypk9BS-2Ju664rL-o9oZ2s1Dc0WHk=.4d3a551b-fe1c-4241-a27d-8b44ef620f5a@github.com>

On Fri, 28 Feb 2025 12:37:35 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space fix
>  - whitespace fix
>  - Copyright year update and manual test case added

> > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
> 
> If this error affects only macOS, try looking for a solution somewhere in `src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m`.

Probable fix is related to the `Text Component` of a spinner and I didn't get any fix in SpinboxAccessibility.m. I can try to push the fix to macOS related class (which won't impact the Windows announcements).
Will update the PR after testing it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2693848852

From asemenov at openjdk.org  Mon Mar  3 10:18:58 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 3 Mar 2025 10:18:58 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <DKISt9HQf09fylSelhvsHEasGanNAMhTQoyfuUPJgOE=.bcc1bc89-a8c8-421b-b3a0-ea554fef7201@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>
 <DKISt9HQf09fylSelhvsHEasGanNAMhTQoyfuUPJgOE=.bcc1bc89-a8c8-421b-b3a0-ea554fef7201@github.com>
Message-ID: <kcToSub8SbQv5WhnNr49Xa5wR45ZvBuHiKq6AsyE32M=.67409fe5-d416-4592-8017-9baef06fb10e@github.com>

On Mon, 3 Mar 2025 10:00:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
> > 
> > 
> > Hello. Was this problem observed on Windows before your changes?
> 
> No, this issue observed only on macOS.

Then try to modify the solution so that it also affects only macOS?
Try to debug the native implementation of NSAccessibilityElements? The error might be somewhere there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2693883161

From asemenov at openjdk.org  Mon Mar  3 10:22:52 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 3 Mar 2025 10:22:52 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <u8FrUVmOP1Pl8dypk9BS-2Ju664rL-o9oZ2s1Dc0WHk=.4d3a551b-fe1c-4241-a27d-8b44ef620f5a@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <u8FrUVmOP1Pl8dypk9BS-2Ju664rL-o9oZ2s1Dc0WHk=.4d3a551b-fe1c-4241-a27d-8b44ef620f5a@github.com>
Message-ID: <FYnUvgcpibUJqAhetmIKUTESBvSxVjq0kKMomdoiSLs=.0aa946fa-570c-4ef4-a2af-cfa3efc9a3c2@github.com>

On Mon, 3 Mar 2025 10:03:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
> > 
> > 
> > If this error affects only macOS, try looking for a solution somewhere in `src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m`.
> 
> Probable fix is related to the `Text Component` of a spinner and I didn't get any fix in SpinboxAccessibility.m. I can try to push the fix to macOS related class (which won't impact the Windows announcements). Will update the PR after testing it.

Many accessibility elements in macOS have native implementations? while others are implemented using a single universal component

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2693893260

From abhiscxk at openjdk.org  Mon Mar  3 12:11:30 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Mar 2025 12:11:30 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
Message-ID: <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>

> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
> 
> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
> Manual test case is added to verify the fix.
> 
> CI pipeline testing is ok for the proposed fix.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Fix pushed to mac os specific class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23841/files
  - new: https://git.openjdk.org/jdk/pull/23841/files/dec1c007..fa581c2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23841&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23841&range=01-02

  Stats: 14 lines in 3 files changed: 5 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23841/head:pull/23841

PR: https://git.openjdk.org/jdk/pull/23841

From abhiscxk at openjdk.org  Mon Mar  3 12:11:31 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Mar 2025 12:11:31 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <FYnUvgcpibUJqAhetmIKUTESBvSxVjq0kKMomdoiSLs=.0aa946fa-570c-4ef4-a2af-cfa3efc9a3c2@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <u8FrUVmOP1Pl8dypk9BS-2Ju664rL-o9oZ2s1Dc0WHk=.4d3a551b-fe1c-4241-a27d-8b44ef620f5a@github.com>
 <FYnUvgcpibUJqAhetmIKUTESBvSxVjq0kKMomdoiSLs=.0aa946fa-570c-4ef4-a2af-cfa3efc9a3c2@github.com>
Message-ID: <cKWdSbS6tG-AIvH5XlK27yCID5BsWpY05AfKYHh7kvw=.43897753-3736-448a-b845-93f331f965ff@github.com>

On Mon, 3 Mar 2025 10:19:53 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> > > > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
> > > 
> > > 
> > > If this error affects only macOS, try looking for a solution somewhere in `src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m`.
> > 
> > 
> > Probable fix is related to the `Text Component` of a spinner and I didn't get any fix in SpinboxAccessibility.m. I can try to push the fix to macOS related class (which won't impact the Windows announcements). Will update the PR after testing it.
> 
> Many accessibility elements in macOS have native implementations? while others are implemented using a single universal component

Pushed fix to `src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java` to have no impact on windows. VO announcements seems correct with the latest changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2694112910

From asemenov at openjdk.org  Mon Mar  3 14:21:53 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 3 Mar 2025 14:21:53 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
Message-ID: <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>

On Mon, 3 Mar 2025 12:11:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pushed to mac os specific class

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 127:

> 125:                     AccessibleContext thisAC = accessible.getAccessibleContext();
> 126:                     Accessible parentAccessible = thisAC.getAccessibleParent();
> 127:                     if (!(parentAccessible instanceof JSpinner.NumberEditor)) {

Why do you need all this if the spinner has an accessible role?
```jdk-21.0.6+7/src/java.desktop/share/classes/javax/swing/JSpinner.java```

        public AccessibleRole getAccessibleRole() {
            return AccessibleRole.SPIN_BOX;
        }

Also, there is already getting an a11y parent lower in the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1977592083

From azvegint at openjdk.org  Mon Mar  3 14:36:32 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Mar 2025 14:36:32 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v2]
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <aFJFmgEQhkqPbWvEBU0AhmPLgnmH5Tioc0gHRpoNsYw=.8fc701b5-36f9-4f71-8dc7-3f9d91af583e@github.com>

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  return CACHE.get(signature);

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23845/files
  - new: https://git.openjdk.org/jdk/pull/23845/files/36546eb6..e6f0f433

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23845&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23845&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23845/head:pull/23845

PR: https://git.openjdk.org/jdk/pull/23845

From azvegint at openjdk.org  Mon Mar  3 14:36:32 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Mar 2025 14:36:32 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v2]
In-Reply-To: <V65o9P-Vwogy5EjgsJhMIRUtBb3dfpheq9Ditlp2nLQ=.f430a3f5-65e9-478b-9215-134de58decac@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>
 <_HAbLsDWyXBG68JmdP65CDcuha-P0vi3u83HmyPsKNw=.141ba8d0-4082-45ea-bbd3-ab50768ff90e@github.com>
 <eL-exxZ4t3XdI6om8WUcahoKp-TBlEcrySh3wKEFLu0=.2edce9f0-f75f-4543-a1bd-8a54f7443ea4@github.com>
 <V65o9P-Vwogy5EjgsJhMIRUtBb3dfpheq9Ditlp2nLQ=.f430a3f5-65e9-478b-9215-134de58decac@github.com>
Message-ID: <wBOS9evDq6Zzkpul8DDKX6XSKBgfvPijT9INFn8pPNM=.752540e7-7a38-4148-892e-e9d02b3c7a40@github.com>

On Fri, 28 Feb 2025 18:49:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sorry for my last premature comment.
>> 
>> I have looked at `Cache`, and believe `create` should be made protected to indicate it is not intended to be called, but only overridden.
>> 
>> The preexisting code called `create` to reuse the creation mechanism without going through the cache - such usage is dubious. Per my experience, similar conditional caches are better implemented by enclosing the logic into the cache structure and use a common endpoint to access, so we have one universal site to determine the conditionality of caching. In this case, such a condition is better included in the `Cache` class itself, and the `create` method should not be publicly exposed.
>
> Yes, I'd prefer `CACHE.get(signature)`.
> 
> At the same time, I've got doubts that Alexander has?
> 
> Although, strictly speaking, it is not ?implementation dependent? because the `Cache` class is part of OpenJDK, and I think it's reasonable to depend on its implementation.

At this point I changed it to `return CACHE.get(signature)` to fix an obvious bug and go back to the execution path that has been around for years to regain the former performance

The thread safety issue and the get/create logic will be dealt with separately in [JDK-8351043](https://bugs.openjdk.org/browse/JDK-8351043)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1977621067

From aivanov at openjdk.org  Mon Mar  3 16:24:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 16:24:03 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v2]
In-Reply-To: <aFJFmgEQhkqPbWvEBU0AhmPLgnmH5Tioc0gHRpoNsYw=.8fc701b5-36f9-4f71-8dc7-3f9d91af583e@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <aFJFmgEQhkqPbWvEBU0AhmPLgnmH5Tioc0gHRpoNsYw=.8fc701b5-36f9-4f71-8dc7-3f9d91af583e@github.com>
Message-ID: <CLKRa-z-vNZT1W_bI3strdRXOQ_Hj7TIe26K7IAaNXk=.aa8aff2e-f637-4540-b65b-932a65829b45@github.com>

On Mon, 3 Mar 2025 14:36:32 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return CACHE.get(signature);

Looks good to me.

I agree it's better to handle other issues under a separate bug or bugs.

src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 1:

> 1: /*

Could you update the copyright year?

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23845#pullrequestreview-2654619166
PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1977805251

From azvegint at openjdk.org  Mon Mar  3 16:52:04 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Mar 2025 16:52:04 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23845/files
  - new: https://git.openjdk.org/jdk/pull/23845/files/e6f0f433..2afb11ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23845&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23845&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23845/head:pull/23845

PR: https://git.openjdk.org/jdk/pull/23845

From aivanov at openjdk.org  Mon Mar  3 16:52:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 16:52:04 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
Message-ID: <HNzqckPsx826BwO2vm_-JJs0oQEX-WyJdg7PmEh95QU=.4c875da9-8fd7-4cff-a9a0-8eea65c0a520@github.com>

On Mon, 3 Mar 2025 16:48:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year update

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23845#pullrequestreview-2654686345

From azvegint at openjdk.org  Mon Mar  3 16:52:06 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Mar 2025 16:52:06 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v2]
In-Reply-To: <CLKRa-z-vNZT1W_bI3strdRXOQ_Hj7TIe26K7IAaNXk=.aa8aff2e-f637-4540-b65b-932a65829b45@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <aFJFmgEQhkqPbWvEBU0AhmPLgnmH5Tioc0gHRpoNsYw=.8fc701b5-36f9-4f71-8dc7-3f9d91af583e@github.com>
 <CLKRa-z-vNZT1W_bI3strdRXOQ_Hj7TIe26K7IAaNXk=.aa8aff2e-f637-4540-b65b-932a65829b45@github.com>
Message-ID: <8eUPLMlMNTnV_UVAy1AQWOBmvEirAS4ojEtPpb7ubf0=.9ba7480e-4f2b-4368-a797-69536418db47@github.com>

On Mon, 3 Mar 2025 16:21:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   return CACHE.get(signature);
>
> src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 1:
> 
>> 1: /*
> 
> Could you update the copyright year?

Sure

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1977843018

From serb at openjdk.org  Mon Mar  3 16:53:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 16:53:53 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <RYCwacfI8ze0K_ZrTgH_jdxoQLSz2Q3mVoMGKQVOeLk=.75fdfed5-b6b6-4c10-b863-e7666defedd5@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

Is it possible that this is some kind of deadlock between WToolkit.shutdown, WToolkit.eventLoop, and ApplicationShutdownHooks.runHooks?

The ApplicationShutdownHooks.runHooks waits when the WToolkit.shutdown will be completed, the WToolkit.shutdown waits when the message will be handled and toolkit disposed,  WToolkit.eventLoop, for some reason cannot handle that message.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2694996189

From aivanov at openjdk.org  Mon Mar  3 17:07:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 17:07:56 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <RYCwacfI8ze0K_ZrTgH_jdxoQLSz2Q3mVoMGKQVOeLk=.75fdfed5-b6b6-4c10-b863-e7666defedd5@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
 <RYCwacfI8ze0K_ZrTgH_jdxoQLSz2Q3mVoMGKQVOeLk=.75fdfed5-b6b6-4c10-b863-e7666defedd5@github.com>
Message-ID: <bXcI6XJhThtphpUg-QKA2z_97h-rDfhf09knvm0c7d4=.6eebcbea-74f8-4bbf-95c9-cb49e6a6336b@github.com>

On Mon, 3 Mar 2025 16:51:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible that this is some kind of deadlock between WToolkit.shutdown, WToolkit.eventLoop, and ApplicationShutdownHooks.runHooks?

I can't see any AWT related threads in the thread dump of the hung process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695033387

From serb at openjdk.org  Mon Mar  3 17:07:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 17:07:56 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>

On Wed, 26 Feb 2025 22:26:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

src/java.desktop/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java line 93:

> 91:             }
> 92: 
> 93:             long maximumHeapSize = Runtime.getRuntime().maxMemory() -

The test program does not contain any "real" large data, so it should not run into an OutOfMemoryError from the start.

Note that after the current patch, the code may still allocate a huge chunk of memory on large systems just by processing a small soundbank which is not good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1977872436

From kizune at openjdk.org  Mon Mar  3 17:14:59 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 17:14:59 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
Message-ID: <dQVSkRPA0gMmcTRqgankIAzRzYvg8ncjIBIDaLMfUAQ=.28c7fcbf-21e6-4c9a-943b-d58b3b24a772@github.com>

On Mon, 3 Mar 2025 12:11:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pushed to mac os specific class

The latest version looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23841#pullrequestreview-2654750633

From aivanov at openjdk.org  Mon Mar  3 17:14:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 17:14:59 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
Message-ID: <pExX6yxqhffmW4cUsEscFFRjRlW04ZPH1uhrSv2RZII=.db1c86a1-c823-467d-9aeb-5a565bceb113@github.com>

On Sat, 1 Mar 2025 01:11:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc update

@mrserb You may want to take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23606#issuecomment-2695049023

From prr at openjdk.org  Mon Mar  3 17:28:52 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 17:28:52 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <ZWEQgkm9R8RBL1Ml_zLkIUcjjcOdbV8fcnZ5BqZWI7k=.4e37e2f5-47fa-42ed-a6c2-faa7bc3c97f7@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>Drag mouse for a short while.

Why does this help ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695080463

From serb at openjdk.org  Mon Mar  3 17:33:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 17:33:51 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <YQBrG4xZCd9slM1fwat-fOCO1F57RnJhB9ZjhMHwOqI=.8b134c34-b04e-4d57-b585-9f5214a95857@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

That is from the description of the bug:

jib > at java.lang.ApplicationShutdownHooks.runHooks([java.base at 13-internal](mailto:java.base at 13-internal)/ApplicationShutdownHooks.java:107)
jib > at java.lang.ApplicationShutdownHooks$1.run([java.base at 13-internal](mailto:java.base at 13-internal)/ApplicationShutdownHooks.java:46)
jib > at java.lang.Shutdown.runHooks([java.base at 13-internal](mailto:java.base at 13-internal)/Shutdown.java:130)
jib > at java.lang.Shutdown.exit([java.base at 13-internal](mailto:java.base at 13-internal)/Shutdown.java:174)
jib > - locked <0x00000000ebc91040> (a java.lang.Class for java.lang.Shutdown)
jib > at java.lang.Runtime.exit([java.base at 13-internal](mailto:java.base at 13-internal)/Runtime.java:113)
jib > at java.lang.System.exit([java.base at 13-internal](mailto:java.base at 13-internal)/System.java:1781)
jib > at com.sun.javatest.regtest.agent.AStatus.exit(AStatus.java:199)
jib > at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:84)



ib > "AWT-Windows" #17 daemon prio=6 os_prio=0 cpu=119281.25ms elapsed=119.91s tid=0x000001ba2f2e7000 nid=0x1ff0 runnable [0x0000002df5fff000]
jib > java.lang.Thread.State: RUNNABLE
jib > at sun.awt.windows.WToolkit.eventLoop([java.desktop at 13-internal](mailto:java.desktop at 13-internal)/Native Method)
jib > at sun.awt.windows.WToolkit.run([java.desktop at 13-internal](mailto:java.desktop at 13-internal)/WToolkit.java:312)
jib > at java.lang.Thread.run([java.base at 13-internal](mailto:java.base at 13-internal)/Thread.java:830)



jib > "ToolkitShutdown" #18 daemon prio=6 os_prio=0 cpu=0.00ms elapsed=119.24s tid=0x000001ba33531000 nid=0x29ec runnable [0x0000002df71fe000]
jib > java.lang.Thread.State: RUNNABLE
jib > at sun.awt.windows.WToolkit.shutdown([java.desktop at 13-internal](mailto:java.desktop at 13-internal)/Native Method)
jib > at sun.awt.windows.WToolkit$$Lambda$27/0x0000000800bc0840.run([java.desktop at 13-internal](mailto:java.desktop at 13-internal)/Unknown Source)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695092486

From kizune at openjdk.org  Mon Mar  3 17:43:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 17:43:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
Message-ID: <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>

On Mon, 3 Mar 2025 17:04:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> src/java.desktop/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java line 93:
> 
>> 91:             }
>> 92: 
>> 93:             long maximumHeapSize = Runtime.getRuntime().maxMemory() -
> 
> The test program does not contain any "real" large data, so it should not run into an OutOfMemoryError from the start.
> 
> Note that after the current patch, the code may still allocate a huge chunk of memory on large systems just by processing a small soundbank which is not good.

Well, it does contain a valid MIDI sequence that produces 1.9GB sound file - you can try to render it with any MIDI sequencer and will get the same result - the uncompressed WAV file generated with Apple GarageBand is about 2.1GB. That's just how MIDI work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1977921357

From serb at openjdk.org  Mon Mar  3 17:44:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 17:44:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
Message-ID: <Lu687FHowUdyJlsfHC33iCKlHoABEYYyS7EjqQJQrSw=.5117a499-414d-4605-886b-9e6c8ab688fd@github.com>

On Sat, 1 Mar 2025 01:11:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc update

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 138:

> 136: 
> 137:         ICC_Profile PYCC = new ICC_Profile(new ProfileDeferralInfo(
> 138:                 "PYCC.pf", ColorSpace.TYPE_3CLR, 3, CLASS_COLORSPACECONVERSION));

The change in this block will exceed 80 characters per line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977923363

From aivanov at openjdk.org  Mon Mar  3 17:50:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 17:50:52 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <D_r51XqXpctECgSDZ9y4APVnM1gdHULUb8AN6No7v-w=.afcbe809-4930-4d0c-b26e-a449492e06b5@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

[JDK-8224968](https://bugs.openjdk.org/browse/JDK-8224968) was filed in 2019. I can't reproduce the same failure that's in description. Over these 6 years many things have changed, so the original problem may be unreproducible any more.

I ran the `javax/swing/JColorChooser/Test6827032.java` test, and it hung. I got the stack traces from the hung process, and there were no AWT threads.

The test isn't problem-listed in LTS releases, that's how I ended up looking at the failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695130155

From serb at openjdk.org  Mon Mar  3 17:50:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 17:50:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
Message-ID: <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>

On Sat, 1 Mar 2025 01:11:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc update

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 784:

> 782:      * Note: {@code ProfileDeferralInfo} is used for only built-in profile
> 783:      * creation and all built-in profiles should be constructed using it.
> 784:      * </p>

</p> is not necessary here.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1156:

> 1154:      * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
> 1155:      * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
> 1156:      * {@link ColorSpace#CS_CIEXYZ}.

The standard profile could be acquired by the application via serialization as well, but I'm not sure if we should mention it.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1169:

> 1167:      * @throws IllegalArgumentException if this is a built-in profile for one
> 1168:      *         of the pre-defined ColorSpaces, i.e. those which can be obtained
> 1169:      *         by calling {@code ICC_Profile.getInstance(int colorSpaceID)}

can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977924842
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977928295
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977930093

From serb at openjdk.org  Mon Mar  3 17:53:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 17:53:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
Message-ID: <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>

On Mon, 3 Mar 2025 17:41:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java line 93:
>> 
>>> 91:             }
>>> 92: 
>>> 93:             long maximumHeapSize = Runtime.getRuntime().maxMemory() -
>> 
>> The test program does not contain any "real" large data, so it should not run into an OutOfMemoryError from the start.
>> 
>> Note that after the current patch, the code may still allocate a huge chunk of memory on large systems just by processing a small soundbank which is not good.
>
> Well, it does contain a valid MIDI sequence that produces 1.9GB sound file - you can try to render it with any MIDI sequencer and will get the same result - the uncompressed WAV file generated with Apple GarageBand is about 2.1GB. That's just how MIDI work.

If the data is correct then you do not need to add any additional checks in front, just proceed it as is and catch OOM. similar to [this](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388#diff-b92a36346bec4c6f7d5e8921bd69b038e0932f116d627bb4f6b514e670e1fccdR1035).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1977934824

From aivanov at openjdk.org  Mon Mar  3 18:02:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Mar 2025 18:02:57 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <ZWEQgkm9R8RBL1Ml_zLkIUcjjcOdbV8fcnZ5BqZWI7k=.4e37e2f5-47fa-42ed-a6c2-faa7bc3c97f7@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
 <ZWEQgkm9R8RBL1Ml_zLkIUcjjcOdbV8fcnZ5BqZWI7k=.4e37e2f5-47fa-42ed-a6c2-faa7bc3c97f7@github.com>
Message-ID: <PFzjU9lYn9NVkOsvD-4qlrpvUVSMA9o0mEobMZtMHJ8=.c018b029-9858-4b52-b635-b6b0a7018655@github.com>

On Mon, 3 Mar 2025 17:26:04 GMT, Phil Race <prr at openjdk.org> wrote:

> > Drag mouse for a short while.
> 
> Why does this help ?

Initially I thought the problem was similar to other drag and drop tests where handling timeout takes 2 hours occasionally. There are several cases where `javax/swing/JColorChooser/Test6827032.java` took more than 2 hours.


----------System.out:(1/37)----------
Timeout signalled after 240 seconds
----------System.err:(1/16)----------
STATUS:Passed.

result: Error. Program `?\jdk-17.0.16\bin\java' timed out
(timeout set to 240000ms, elapsed time including timeout handling was 7469797ms).


We've never figured out why it happens.

However, the hang that I reproduced locally looked differently. I thought it could be related to starting secondary event loop for drag and drop? but then I didn't see any AWT threads in the thread dump.

It may be that dragging mouse actually finishes drag and drop? and it makes the test run a little longer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695161702

From prr at openjdk.org  Mon Mar  3 18:04:07 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 18:04:07 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
Message-ID: <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>

On Mon, 3 Mar 2025 17:47:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1169:
> 
>> 1167:      * @throws IllegalArgumentException if this is a built-in profile for one
>> 1168:      *         of the pre-defined ColorSpaces, i.e. those which can be obtained
>> 1169:      *         by calling {@code ICC_Profile.getInstance(int colorSpaceID)}
> 
> can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?

The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.
Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.
And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977947820

From kizune at openjdk.org  Mon Mar  3 18:04:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 18:04:51 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v2]
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <6iJuLvNcGeUG94Ejhab5xpBKCxhAtFKbKeYU1s5kkWo=.3812dae7-482f-4a6f-ae55-cdeab623e792@github.com>

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/javax/sound/midi/BulkSoundBank/BulkSoundBank.java
  
  Use try with resources clause in the test.
  
  Co-authored-by: Harshitha Onkar <harshitha.onkar at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23814/files
  - new: https://git.openjdk.org/jdk/pull/23814/files/8a2fa6c1..e48e16a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23814/head:pull/23814

PR: https://git.openjdk.org/jdk/pull/23814

From kizune at openjdk.org  Mon Mar  3 18:13:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 18:13:55 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v2]
In-Reply-To: <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
Message-ID: <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>

On Mon, 3 Mar 2025 17:51:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Well, it does contain a valid MIDI sequence that produces 1.9GB sound file - you can try to render it with any MIDI sequencer and will get the same result - the uncompressed WAV file generated with Apple GarageBand is about 2.1GB. That's just how MIDI work.
>
> If the data is correct then you do not need to add any additional checks in front, just proceed it as is and catch OOM. similar to [this](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388#diff-b92a36346bec4c6f7d5e8921bd69b038e0932f116d627bb4f6b514e670e1fccdR1035).

That's actually a very bad idea for two reasons:
1. It will consume a lot of resources loading and rendering the sound bank impacting background task that might fail because they do not have enough memory - and that's while we know upfront that we will not be able to finish with the rendering process.
2. It is not advised to continue normal operation after OOME is caught, because at this moment VM might not work reliably unless we can guarantee that memory can be immediately released. For example in the code above we are trying to re-throw OOME as a checked exception - but if we do not have enough heap to instantiate a new IOException - then what? What if some background task already failed because it could not initialize its inner classes? What if that background task is GC? It is commonly advised to catch OOME only as a "fail gracefully" scenario and be ready with pre-initialized output classes to save current state because you might not have enough heap to initialize the emergency shutdown procedure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1977961866

From prr at openjdk.org  Mon Mar  3 18:16:16 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 18:16:16 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <n6fTlL7cEgkAV8GkVMcFQP0MVpjEdMoTUNavZyQeUVI=.7106ea65-853b-4068-8ca0-149b69b36f99@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

>It may be that dragging mouse actually finishes drag and drop? and it makes the test run a little longer.

OK.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23846#pullrequestreview-2654878595

From serb at openjdk.org  Mon Mar  3 18:16:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 18:16:16 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <D_r51XqXpctECgSDZ9y4APVnM1gdHULUb8AN6No7v-w=.afcbe809-4930-4d0c-b26e-a449492e06b5@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
 <D_r51XqXpctECgSDZ9y4APVnM1gdHULUb8AN6No7v-w=.afcbe809-4930-4d0c-b26e-a449492e06b5@github.com>
Message-ID: <-NhXj9tbsfgwXLypF7JQ2vBVEj_iAjREvSMC2mwLexA=.fbb6a163-a9db-4db7-b3fa-11bae9aa6da7@github.com>

On Mon, 3 Mar 2025 17:47:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I ran the `javax/swing/JColorChooser/Test6827032.java` test, and it hung. I got the stack traces from the hung process, and there were no AWT threads.
> 
> The test isn't problem-listed in LTS releases, that's how I ended up looking at the failure.

Could it be possible that the different modes used to run the test in the past: ovm vs agent are causing this issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695191688

From honkar at openjdk.org  Mon Mar  3 18:18:05 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 3 Mar 2025 18:18:05 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
Message-ID: <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>

On Mon, 3 Mar 2025 17:46:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1156:
> 
>> 1154:      * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
>> 1155:      * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
>> 1156:      * {@link ColorSpace#CS_CIEXYZ}.
> 
> The standard profile could be acquired by the application via serialization as well, but I'm not sure if we should mention it.

This builtin flag check is exclusively for JDK built-in profiles created within the private interface `BuiltInProfile` and not applicable if an application loads the profile by serialization. 

Since `BuiltInProfile` interface and `builtin` flag are private we could not include it in javadoc hence used ICC_Profile.getInstance(int colorspaceID) to specify built-in profile. Please let us know if the javadoc sound okay or requires any changes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977966082

From honkar at openjdk.org  Mon Mar  3 18:21:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 3 Mar 2025 18:21:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
Message-ID: <q9_IJTpPbTxAg2NK381FpfX2nGy7CQtplAQ9yALZznQ=.1c7866bd-0093-499c-859e-344b4cee2f9a@github.com>

On Mon, 3 Mar 2025 17:43:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 784:
> 
>> 782:      * Note: {@code ProfileDeferralInfo} is used for only built-in profile
>> 783:      * creation and all built-in profiles should be constructed using it.
>> 784:      * </p>
> 
> </p> is not necessary here.

This note was added based on the suggestion here: https://github.com/openjdk/jdk/pull/23606#discussion_r1976123437

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977970353

From honkar at openjdk.org  Mon Mar  3 18:30:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 3 Mar 2025 18:30:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <q9_IJTpPbTxAg2NK381FpfX2nGy7CQtplAQ9yALZznQ=.1c7866bd-0093-499c-859e-344b4cee2f9a@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <q9_IJTpPbTxAg2NK381FpfX2nGy7CQtplAQ9yALZznQ=.1c7866bd-0093-499c-859e-344b4cee2f9a@github.com>
Message-ID: <LuaTZF8nWYUfSkBABZhoXTTZu-rQKy9ymkW5vw-rqi4=.8b9ae7ae-a7db-441c-8dd7-edf8f947a545@github.com>

On Mon, 3 Mar 2025 18:18:58 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 784:
>> 
>>> 782:      * Note: {@code ProfileDeferralInfo} is used for only built-in profile
>>> 783:      * creation and all built-in profiles should be constructed using it.
>>> 784:      * </p>
>> 
>> </p> is not necessary here.
>
> This note was added based on the suggestion here: https://github.com/openjdk/jdk/pull/23606#discussion_r1976123437

Oh you meant `<p>` tag :) 
It was not rendered in github comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1977981688

From kizune at openjdk.org  Mon Mar  3 18:47:10 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 18:47:10 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v3]
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <zf73cB7dbdSaJ84fh4yaJD1PDM92TW_dgDnGK6HHOs0=.1e42d969-9909-425b-a204-c406593c6f71@github.com>

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23814/files
  - new: https://git.openjdk.org/jdk/pull/23814/files/e48e16a1..e02c5863

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23814/head:pull/23814

PR: https://git.openjdk.org/jdk/pull/23814

From serb at openjdk.org  Mon Mar  3 18:50:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 18:50:56 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v3]
In-Reply-To: <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
Message-ID: <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>

On Mon, 3 Mar 2025 18:11:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>2. It is not advised to continue normal operation after OOME is caught, because at this moment VM might not work reliably unless we can guarantee that memory can be immediately released. For example in the code above we are trying to re-throw OOME as a checked exception - but if we do not have enough heap to instantiate a new IOException - then what? 

Then an OOM will be thrown, signaling to the application that it is not possible to proceed?

>What if some background task already failed because it could not initialize its inner classes? What if that background task is GC? It is commonly advised to catch OOME only as a "fail gracefully" scenario and be ready with pre-initialized output classes to save current state because you might not have enough heap to initialize the emergency shutdown procedure.

The current patch will not solve any of these issues, as the check in advance may pass while the code still fails producing an unexpected exception in the application. The try/catch block, at the very least, provides an opportunity for the application to catch the expected IOException instead of fatal OOM and retry or skip this file. That is exact reason why the try/catch was added [here](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388#diff-b92a36346bec4c6f7d5e8921bd69b038e0932f116d627bb4f6b514e670e1fccdR1035)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1978013315

From bpb at openjdk.org  Mon Mar  3 18:54:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 18:54:57 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <Gi2z-GJbaYd1BUPsyBt-ZbaNCrx5q8XjHIR_6oD04HI=.8771cec2-0813-4d01-8f73-7dfb38156fdd@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
 <OCgXbBy8bcQJwSfLYZbk9z8yhcmB57f7Ig2DOzAawbc=.af3707b9-5e4c-4475-8534-cb735c209ae5@github.com>
 <Gi2z-GJbaYd1BUPsyBt-ZbaNCrx5q8XjHIR_6oD04HI=.8771cec2-0813-4d01-8f73-7dfb38156fdd@github.com>
Message-ID: <eMsY_pVV7AUxZm47Q9DrEsSV2tEbZuM5m6UJdraq2bw=.f6082ba8-3347-4b8a-a5dc-33a227e1b4e2@github.com>

On Sat, 1 Mar 2025 17:58:44 GMT, Jeremy <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 182:
>> 
>>> 180:                 // file shows it can also sometimes be 0x60000. I've also observed it to be
>>> 181:                 // undefined, 0x0007, or several variations of 0x????0006. Similarly the same
>>> 182:                 // tag should be 0x0001 for TIFFs, but I also observed a case where it as 0x10000.
>> 
>> Isn't this ( 0x0001/0x0006 vs 0x1000/0x6000) just a matter of endianness in the TIFF structure? Some odd writers may also use LONG/32 bit values, even though the TiFF and Exif specs only mention SHORT/16 bit values for the compression tag. 
>> 
>> Compression 7 "New JPEG"  is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.
>
> Yes, it probably is endianness, or endianness-related. My first design question is: should we care? Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields. If we strictly rely on the compression tag (250) instead: is that better/desirable? (That is: we could just throw an IOException in the rare case this field is missing/broken.)

> Compression 7 "New JPEG" is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.

Probably the `Compression` tag should not be relied upon. While the Exif specification strangely states that for compressed thumbnails its value should be 6, there is no harm in its being 7.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1978020479

From bpb at openjdk.org  Mon Mar  3 18:59:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 18:59:02 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <eMsY_pVV7AUxZm47Q9DrEsSV2tEbZuM5m6UJdraq2bw=.f6082ba8-3347-4b8a-a5dc-33a227e1b4e2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
 <OCgXbBy8bcQJwSfLYZbk9z8yhcmB57f7Ig2DOzAawbc=.af3707b9-5e4c-4475-8534-cb735c209ae5@github.com>
 <Gi2z-GJbaYd1BUPsyBt-ZbaNCrx5q8XjHIR_6oD04HI=.8771cec2-0813-4d01-8f73-7dfb38156fdd@github.com>
 <eMsY_pVV7AUxZm47Q9DrEsSV2tEbZuM5m6UJdraq2bw=.f6082ba8-3347-4b8a-a5dc-33a227e1b4e2@github.com>
Message-ID: <B6kPtDF2K_6dz6Rk_xGHG3_MFCniJFaNdHnz1WdyyIM=.02035069-335f-465d-b431-d919a3dc1c92@github.com>

On Mon, 3 Mar 2025 18:52:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes, it probably is endianness, or endianness-related. My first design question is: should we care? Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields. If we strictly rely on the compression tag (250) instead: is that better/desirable? (That is: we could just throw an IOException in the rare case this field is missing/broken.)
>
>> Compression 7 "New JPEG" is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.
> 
> Probably the `Compression` tag should not be relied upon. While the Exif specification strangely states that for compressed thumbnails its value should be 6, there is no harm in its being 7.

> Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields.

Specifically the `JPEGInterchangeFormat` and `JPEGInterchangeFormatLength` fields. In the Exif 3.0 specification these have support level _mandatory_ for compressed thumbnails and _disallowed_ for uncompressed thumbnails.

> If we strictly rely on the compression tag (250) instead: is that better/desirable?

I don't think so.

> (That is: we could just throw an IOException in the rare case this field is missing/broken.)

This will indeed happen if `JPEGInterchangeFormat` does not point to a valid JPEG stream (SOI marker).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1978025262

From serb at openjdk.org  Mon Mar  3 19:23:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 19:23:04 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <ZMavxF4T17mI30MkXEOyl494zXt0xfA6OSV7Foom7EE=.81081b0f-8b7e-4c28-b4e4-0e9071e4c675@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

It looks like the test was updated at some point (see [commit c0084100](https://github.com/openjdk/jdk/commit/c0084100)), as discussed in the PR [#2220](https://github.com/openjdk/jdk/pull/2220). It seems we worked around a product bug by changing the test. It was promised that the bug would be addressed in [JDK-8261016](https://bugs.openjdk.org/browse/JDK-8261016), but it has been closed as "Cannot Reproduce."

I can still reproduce it if that commit is reverted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2695330926

From bpb at openjdk.org  Mon Mar  3 19:27:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 19:27:01 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
Message-ID: <JcLkQtuB20pg8sIuHtNbeEdUpl4OrEZgGZZQinaeFqw=.05b26828-aab8-4552-974d-dd22a7d7564a@github.com>

On Wed, 26 Feb 2025 09:23:47 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: trying to placate PR script
>   
>   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.

I think we need to add something to the specification, for example:


--- a/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html
+++ b/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html
@@ -509,6 +509,17 @@ <h2>
 <h2>
 <a id=thumbs>Thumbnail Images</a>
 </h2>
+<h3>
+Reading Thumbnail Images
+</h3>
+Thumbnail images are read from JFIF, JFIF extension, and Exif marker segments.
+One or more thumbnails may be present in the JFIF segment(s), but at most one
+will be present in the Exif segment. As specified, JFIF and Exif marker segments
+should be mutually exclusive, but if they are both present, then any JFIF
+thumbnail(s) will precede any Exif thumbnail.
+<h3>
+Writing Thumbnail Images
+</h3>
 Thumbnails are supported by the use of JFIF and JFIF extension marker segments.
 Thumbnails provided on the write methods determine the thumbnails that will be
 included.  <code>app0JFIF</code> and <code>app0JFXX</code> nodes present in


If this is agreeable, I can file a matching CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695336992

From kcr at openjdk.org  Mon Mar  3 19:36:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 19:36:00 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>
Message-ID: <t3MDCgF5R1uIX7DBhHU1CcSWWaQ0CUrcEA90oEL0zgc=.420eca0d-7daf-4dd8-b1b8-c1cf5ba72f6a@github.com>

On Wed, 26 Feb 2025 09:23:47 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: trying to placate PR script
>   
>   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.

I should add that image files for tests are an exception to the general rule that binary files should not be checked into the repo. Zip files are not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695358120

From kcr at openjdk.org  Mon Mar  3 19:35:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 19:35:59 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v5]
In-Reply-To: <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>
 <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>
Message-ID: <WknJyh6_0tOXYPOM5u6ze-N18_wwK1CYU5RQItc0gAw=.0f05ab6c-2955-45af-b546-4e549343d610@github.com>

On Mon, 24 Feb 2025 07:09:35 GMT, Jeremy <duke at openjdk.org> wrote:

> A few questions remain on my end:
> 
> 1. The PR bot somehow flagged two of the test jpg files as executables (which it describes as "Errors"). Any recommendations on how to placate this error? (Should I just zip the images together?)

No, please don't do this. All this does is obscure the fact that the zip file contains images. If you need 2 (or 3 or 10) images, place them each in their own file. Skara will note that they exist so that reviewers can check them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695354366

From kcr at openjdk.org  Mon Mar  3 19:41:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 19:41:53 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v5]
In-Reply-To: <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>
 <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>
Message-ID: <Q0IviFqlWbRGi8qgiEvppY0PrV581z1cN6zngM5lbpI=.ef951c89-528b-4c76-9bdc-fb010915827c@github.com>

On Mon, 24 Feb 2025 07:09:35 GMT, Jeremy <duke at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: replacing the "sony-d700" image
>>   
>>   The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
>>   
>>   I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.
>
> I think I've finished all the pending edits I had in mind. 
> 
> Regarding ownership of images:
> One sample image comes from Brian, the rest come from me.
> 
> A few questions remain on my end:
> 
> 1. The PR bot somehow flagged two of the test jpg files as executables (which it describes as "Errors"). Any recommendations on how to placate this error? (Should I just zip the images together?)
> 
> @bplb :
> 2. Do you still think a test case featuring an uncompressed RGB main image with a uncompressed RGB thumbnail is necessary?
> 
> I'm not sure off the top of my head how to generate this kind of image. It seems to me like reading any thumbnail is completely insulated from reading the main image, so mixing and matching combinations of main images and thumbnails shouldn't be an issue. (?)
> 
> 3. Should I add a test that includes an EXIF thumbnail followed by a JFIF thumbnail? You asked about (and the original ticket included) an image that featured a JFIF thumbnail followed by an EXIF thumbnail, and this PR now covers that test case. But I think the JFIF logic is stricter and will probably throw an exception if the EXIF thumbnail appears first.

@mickleness Your source branch is very out of date (more than two months). Can you merge in the latest upstream master?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695368442

From bpb at openjdk.org  Mon Mar  3 20:00:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 20:00:53 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v5]
In-Reply-To: <Q0IviFqlWbRGi8qgiEvppY0PrV581z1cN6zngM5lbpI=.ef951c89-528b-4c76-9bdc-fb010915827c@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>
 <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>
 <Q0IviFqlWbRGi8qgiEvppY0PrV581z1cN6zngM5lbpI=.ef951c89-528b-4c76-9bdc-fb010915827c@github.com>
Message-ID: <9FjnBZwyhnRhVJA_cxzIIh5UMOAfLt54bCYYJLA6rpk=.70742367-e548-4ad8-a58d-4c60132b50ae@github.com>

On Mon, 3 Mar 2025 19:38:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think I've finished all the pending edits I had in mind. 
>> 
>> Regarding ownership of images:
>> One sample image comes from Brian, the rest come from me.
>> 
>> A few questions remain on my end:
>> 
>> 1. The PR bot somehow flagged two of the test jpg files as executables (which it describes as "Errors"). Any recommendations on how to placate this error? (Should I just zip the images together?)
>> 
>> @bplb :
>> 2. Do you still think a test case featuring an uncompressed RGB main image with a uncompressed RGB thumbnail is necessary?
>> 
>> I'm not sure off the top of my head how to generate this kind of image. It seems to me like reading any thumbnail is completely insulated from reading the main image, so mixing and matching combinations of main images and thumbnails shouldn't be an issue. (?)
>> 
>> 3. Should I add a test that includes an EXIF thumbnail followed by a JFIF thumbnail? You asked about (and the original ticket included) an image that featured a JFIF thumbnail followed by an EXIF thumbnail, and this PR now covers that test case. But I think the JFIF logic is stricter and will probably throw an exception if the EXIF thumbnail appears first.
>
> @mickleness Your source branch is very out of date (more than two months). Can you merge in the latest upstream master?

Thanks, @kevinrushforth, for the various comments.

@mickleness, the merge should be no problem as, aside from the image archive, the diff from the webrev applies cleanly to the current master and builds without problems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695407850

From serb at openjdk.org  Mon Mar  3 20:16:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 20:16:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
Message-ID: <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>

On Mon, 3 Mar 2025 18:15:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This builtin flag check is exclusively for JDK built-in profiles created within the private interface `BuiltInProfile` and not applicable if an application loads the profile by serialization.

The built-in profiles can be serialized and deserialized, [see](https://github.com/openjdk/jdk/blob/c4b516dfe7c5a5fddd4d9c97a21f5f36bf845646/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1573). This means the application may get a reference to the profile not only via the getInstance(id) method. Therefore, the new spec is not strictly accurate regarding ICC_Profile.getInstance(int colorSpaceID), but I am not sure that we should mention serialisation here.

**Note:** 
The new Javadoc for the new private built-in flag is "public" via the serialized form of the class. It probably should be marked as transient, so it will only be set to true when the built-in profile is loaded via serialization. In all other cases, it will be false.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1978134779

From serb at openjdk.org  Mon Mar  3 20:41:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 20:41:59 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
Message-ID: <4ZREpLZ0cY20tX3DMcqr9r_nzzdaLAfN8f0ha80duko=.446f6d9a-3c89-4d0a-adde-6c42965bf859@github.com>

On Mon, 3 Mar 2025 16:52:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year update

src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 80:

> 78: 
> 79:         try {
> 80:             return CACHE.get(signature);

Is it possible to create a test for this patch?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1978162593

From duke at openjdk.org  Mon Mar  3 21:13:18 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 3 Mar 2025 21:13:18 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v8]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <RBV1f-CfpRSFsxx_pzGg0K437ySou5NfOtf8z0Qz0cY=.b1425153-5983-48b8-a528-097bcf4f1ed7@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

Jeremy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:

 - Merge branch 'master' into JDK-8160327
 - Merge branch 'openjdk:master' into master
 - Revert "8160327: trying to placate PR script"
   
   This reverts commit 52cf81f49a61d80c473b69e4a504eeb1d03c38a3.
 - 8160327: trying to placate PR script
   
   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.
 - 8160327: trying to placate PR script
   
   Some github script is concluding:
   ```
   Errors
    ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/jfif_and_exif.jpg)
    ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/malicious_looping_IFD.jpg)
   ```
   
   I'm trying to figure what separates these files from the other JPGs. Maybe I need to use hyphens instead of underscores...? Let's check.
 - 8160327: replacing the "sony-d700" image
   
   The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
   
   I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.
 - 8160327: fix looping ImageFileDirectory vulnerability
   
   There was a `while` loop that someone could exploit to loop infinitely. Now we read exactly 2 iterations and stop.
 - 8160327: remove bug ID from image file names
   
   Now the bug ID is mentioned in their parent directory name.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#issuecomment-2675396159
 - 8160327: replace image of unknown origin with my own image
 - 8160327: alphabetize imports
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
 - ... and 21 more: https://git.openjdk.org/jdk/compare/5c43b70e...b70b0802

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/52cf81f4..b70b0802

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=06-07

  Stats: 252503 lines in 5866 files changed: 122075 ins; 103730 del; 26698 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

PR: https://git.openjdk.org/jdk/pull/22898

From kcr at openjdk.org  Mon Mar  3 21:17:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 21:17:07 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v8]
In-Reply-To: <RBV1f-CfpRSFsxx_pzGg0K437ySou5NfOtf8z0Qz0cY=.b1425153-5983-48b8-a528-097bcf4f1ed7@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <RBV1f-CfpRSFsxx_pzGg0K437ySou5NfOtf8z0Qz0cY=.b1425153-5983-48b8-a528-097bcf4f1ed7@github.com>
Message-ID: <NZl-cjCNniUh55y-EkoAJFX5gwFPAp1_r2WYDFMJlD4=.d386bdcb-f23e-4acf-a4c1-91f3e2ea902c@github.com>

On Mon, 3 Mar 2025 21:13:18 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8160327
>  - Merge branch 'openjdk:master' into master
>  - Revert "8160327: trying to placate PR script"
>    
>    This reverts commit 52cf81f49a61d80c473b69e4a504eeb1d03c38a3.
>  - 8160327: trying to placate PR script
>    
>    The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.
>  - 8160327: trying to placate PR script
>    
>    Some github script is concluding:
>    ```
>    Errors
>     ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/jfif_and_exif.jpg)
>     ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/malicious_looping_IFD.jpg)
>    ```
>    
>    I'm trying to figure what separates these files from the other JPGs. Maybe I need to use hyphens instead of underscores...? Let's check.
>  - 8160327: replacing the "sony-d700" image
>    
>    The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
>    
>    I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.
>  - 8160327: fix looping ImageFileDirectory vulnerability
>    
>    There was a `while` loop that someone could exploit to loop infinitely. Now we read exactly 2 iterations and stop.
>  - 8160327: remove bug ID from image file names
>    
>    Now the bug ID is mentioned in their parent directory name.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2675396159
>  - 8160327: replace image of unknown origin with my own image
>  - 8160327: alphabetize imports
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/caf53b2e...b70b0802

Btw, two of the files are executable. To fix this: `chmod 644 file [file ...]` and then commit the change in file permission.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695550383

From prr at openjdk.org  Mon Mar  3 21:21:53 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Mar 2025 21:21:53 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
Message-ID: <Vj9ByNq-R-2qk0Gk4KeCZsfQPm7UK30Zc2GH4kH4NQA=.8938499b-aede-4e99-9dfc-f17d54ee224f@github.com>

On Tue, 25 Feb 2025 16:40:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Wayland clients are by design not allowed to change the resolution in Wayland.
>> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
>> 
>> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
>> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
>> 
>> ---
>> 
>> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
>> 
>> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
>> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
>> 
>> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
>> 
>> ---
>> 
>> Testing looks good (manual + automated).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoResizeEventOnDMChangeTest update

What about, if we are on Wayland, behave the same in single-screen as you say happens any way with multi-screen - report only one resolution - the current / default one ?
I suggest this in part because I am not sure what the impact is of having the resolution be "emulated". If the app, and AWT think there's a different resolution than there really is, rendering quality could be affected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23774#issuecomment-2695568318

From serb at openjdk.org  Mon Mar  3 21:31:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 21:31:02 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
Message-ID: <xqF2cXdYPnv-5EkA7SJJM2QCafuG6bQHRBZRuWWGAro=.17266f85-039e-4808-a2cf-728a4b9d76d3@github.com>

On Mon, 3 Mar 2025 16:52:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year update

>Cache#get non-obviously creates a value in Cache

Then why we need to call CACHE.create the second time? Can we just return it as is? 
`return CACHE.get(signature);`

I think previously, we couldn't return the cached data as is, since it could be cached by one applet and requested by another. So, in the case of an inaccessible package, we call CACHE.create() and return a duplicate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2695593424

From serb at openjdk.org  Mon Mar  3 21:46:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Mar 2025 21:46:57 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
Message-ID: <4PL3gXkKim-0CCeRe0gfVcS-DS72agDocYd18HEfKtY=.9b766bb9-6453-4ac2-96ac-005f97d69e8e@github.com>

On Mon, 3 Mar 2025 16:52:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year update

`return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);`

I think the old code should be read as:
 - If the method is null, skip the h/w package access check and return.
 - If the method is not null, then perform the h/w package access check and duplicate the data if needed.

So, when the usage of isPackageAccessible was deleted, the null check for the method should also have been removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2695628234

From duke at openjdk.org  Mon Mar  3 22:23:51 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 3 Mar 2025 22:23:51 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

Jeremy has updated the pull request incrementally with one additional commit since the last revision:

  8160327: trying to placate PR script
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/22898#issuecomment-2695550383

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/b70b0802..84827aca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=07-08

  Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

PR: https://git.openjdk.org/jdk/pull/22898

From bpb at openjdk.org  Mon Mar  3 22:42:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 22:42:10 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
Message-ID: <yvdnVB9w4nBMhB1lRr1VhAghRBCcJ4P0mPkUJ-20_EQ=.3d425d28-5ca7-4d48-a4da-2386c008a41b@github.com>

On Mon, 3 Mar 2025 22:23:51 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: trying to placate PR script
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695550383

A local copy of the PR for commit 84827ac built cleanly and all tests in `javax/imageio/plugins/jpeg` passed on macOS-aarch64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695728845

From kizune at openjdk.org  Mon Mar  3 22:50:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 22:50:56 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v3]
In-Reply-To: <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
Message-ID: <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>

On Mon, 3 Mar 2025 18:47:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The current patch will not solve any of these issues, as the check in advance may pass while the code still fails producing an unexpected exception in the application.

I am not trying to solve this problem for the reason stated above - i do not think it is a problem that needs to be solved. If we think we have enough memory but (in some corner cases) the processing overhead will eat up more memory than we expected it will take - we will fail with OOME and i'm not trying to mask it and provide some way to handle this situation - because i think it is useless. What i am trying to do - is that if we are sure that we do not have enough memory - do not eat it up causing VM to exhaust all its heap just to prove the obvious point - we can't load this sound bank. That's it - there's nothing more that i'm trying to achieve. We read the MIDI, we parse its timeline, we know how long it will be and we can calculate what amount of memory will be required to render it into a sound bank - if we know we do not have it - issue an exception with a reason. If we think we have enough memory but processing overhead or some background task consumed part of it - we will 
 have OOME - here or in that background memory-eating process - it does not matter, we will fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1978349216

From duke at openjdk.org  Mon Mar  3 22:51:11 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 3 Mar 2025 22:51:11 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v8]
In-Reply-To: <NZl-cjCNniUh55y-EkoAJFX5gwFPAp1_r2WYDFMJlD4=.d386bdcb-f23e-4acf-a4c1-91f3e2ea902c@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <RBV1f-CfpRSFsxx_pzGg0K437ySou5NfOtf8z0Qz0cY=.b1425153-5983-48b8-a528-097bcf4f1ed7@github.com>
 <NZl-cjCNniUh55y-EkoAJFX5gwFPAp1_r2WYDFMJlD4=.d386bdcb-f23e-4acf-a4c1-91f3e2ea902c@github.com>
Message-ID: <gy4E95pTNsFtGauy0NDDxGqEU6Vyp1FpNvvWjFkYXBQ=.083da3ef-7432-4fcb-83a8-3f37d5fc4f8b@github.com>

On Mon, 3 Mar 2025 21:14:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jeremy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8160327
>>  - Merge branch 'openjdk:master' into master
>>  - Revert "8160327: trying to placate PR script"
>>    
>>    This reverts commit 52cf81f49a61d80c473b69e4a504eeb1d03c38a3.
>>  - 8160327: trying to placate PR script
>>    
>>    The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.
>>  - 8160327: trying to placate PR script
>>    
>>    Some github script is concluding:
>>    ```
>>    Errors
>>     ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/jfif_and_exif.jpg)
>>     ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/malicious_looping_IFD.jpg)
>>    ```
>>    
>>    I'm trying to figure what separates these files from the other JPGs. Maybe I need to use hyphens instead of underscores...? Let's check.
>>  - 8160327: replacing the "sony-d700" image
>>    
>>    The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
>>    
>>    I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.
>>  - 8160327: fix looping ImageFileDirectory vulnerability
>>    
>>    There was a `while` loop that someone could exploit to loop infinitely. Now we read exactly 2 iterations and stop.
>>  - 8160327: remove bug ID from image file names
>>    
>>    Now the bug ID is mentioned in their parent directory name.
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2675396159
>>  - 8160327: replace image of unknown origin with my own image
>>  - 8160327: alphabetize imports
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/5af1de32...b70b0802
>
> Btw, two of the files are executable. To fix this: `chmod 644 file [file ...]` and then commit the change in file permission.

@kevinrushforth thanks, the executable error doesn't appear now.

I merged and double-checked that all imageio.* tests pass on my M2 Mac.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695742275

From duke at openjdk.org  Mon Mar  3 22:54:54 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 3 Mar 2025 22:54:54 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
Message-ID: <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>

On Mon, 3 Mar 2025 22:23:51 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: trying to placate PR script
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695550383

Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695748673

From bpb at openjdk.org  Mon Mar  3 22:58:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 22:58:55 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
Message-ID: <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>

On Mon, 3 Mar 2025 22:52:27 GMT, Jeremy <duke at openjdk.org> wrote:

> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.

If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2695754262

From duke at openjdk.org  Tue Mar  4 01:07:56 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Tue, 4 Mar 2025 01:07:56 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v2]
In-Reply-To: <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <FD2MyxKkWqjOSe8aRSFcK69uch6A-U_yz8P8bx_edKs=.6b0906c1-21dc-4128-804e-881d61148d63@github.com>
Message-ID: <SPLne5gkWOfwFfJt-qI6Q_VIoGl0CYuWisBzCP08LMY=.70571091-136d-4939-a352-f680f3486f44@github.com>

On Sun, 2 Mar 2025 14:21:45 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes HeadlessMalfunctionTest from ProblemList.txt

I've got my aarch64 MacMini building it and I can see that too. Gonna wire it to ci before future contributions.


Output and diagnostic info for process 76543 was saved into 'pid-76543-output.log'
Command line: [/Users/karm/tmp/JENKINS_DEMO_RUN/jdk/build/macosx-aarch64-server-release/images/graal-builder-jdk/bin/java -cp /Users/karm/tmp/JENKINS_DEMO_RUN/jdk/jtreg_results/jdk/JTwork/classes/java/awt/Headless/HeadlessMalfunctionTest.d:/Users/karm/tmp/JENKINS_DEMO_RUN/jdk/test/jdk/java/awt/Headless:/Users/karm/tmp/JENKINS_DEMO_RUN/jdk/jtreg_results/jdk/JTwork/classes/test/lib:/Users/karm/tmp/JENKINS_DEMO_RUN/jdk/test/lib:/Users/karm/tmp/JENKINS_DEMO_RUN/jtreg/build/images/jtreg/lib/javatest.jar:/Users/karm/tmp/JENKINS_DEMO_RUN/jtreg/build/images/jtreg/lib/jtreg.jar --add-opens java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED -javaagent:agent.jar HeadlessMalfunctionTest$Runner ]
[2025-03-03T23:51:31.832863Z] Gathering output for process 76544
[2025-03-03T23:51:31.832992Z] Waiting for completion for process 76544
[2025-03-03T23:51:32.309606Z] Waiting for completion finished for process 76544
Output and diagnostic info for process 76544 was saved into 'pid-76544-output.log'
----------System.err:(29/2012)----------
 stdout: [Transforming java.awt.GraphicsEnvironment.
isHeadless removed from java.awt.GraphicsEnvironment.
];
 stderr: [WARNING: package jdk.internal.org.objectweb.asm not in java.base
Exception in thread "main" java.lang.NoSuchMethodError: 'boolean java.awt.GraphicsEnvironment.isHeadless()'
	at java.desktop/sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:155)
	at java.desktop/sun.awt.PlatformGraphicsInfo.createToolkit(PlatformGraphicsInfo.java:43)
	at java.desktop/java.awt.Toolkit.getDefaultToolkit(Toolkit.java:580)
	at java.desktop/sun.awt.CGraphicsEnvironment.<clinit>(CGraphicsEnvironment.java:72)
	at java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:39)
	at java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:89)
	at java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:80)
	at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:102)
	at HeadlessMalfunctionTest$Runner.main(HeadlessMalfunctionTest.java:69)
]
 exitValue = 1


I realxed the output matching in the test as the log comes from a different code path on MacOS.   Gonna take a look at Windows too...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2695921133

From duke at openjdk.org  Tue Mar  4 03:41:10 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Mar 2025 03:41:10 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

Jeremy has updated the pull request incrementally with one additional commit since the last revision:

  8160327: adding "Reading Thumbnail Images" for Exif marker changes
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/84827aca..eb2283c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=08-09

  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

PR: https://git.openjdk.org/jdk/pull/22898

From duke at openjdk.org  Tue Mar  4 03:41:11 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Mar 2025 03:41:11 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
Message-ID: <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>

On Mon, 3 Mar 2025 22:56:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
>
>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
> 
> If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.

@bplb The HTML changes are added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2696100174

From serb at openjdk.org  Tue Mar  4 03:59:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 03:59:51 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v3]
In-Reply-To: <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
Message-ID: <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>

On Mon, 3 Mar 2025 22:48:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> I am not trying to solve this problem for the reason stated above - i do not think it is a problem that needs to be solved.

But this issue should be addressed?it's similar to a zip bomb, where small but valid source data can consume a huge amount of memory after processing. To handle this, we should convert a fatal OutOfMemoryError into an IOException, which the application is likely already expecting.

It's unlikely that throwing an IOException will also cause an OOM, since before the new exception is thrown, the GC will clean up, freeing the allocated multi-gigabyte data in this block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1978568070

From serb at openjdk.org  Tue Mar  4 04:02:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 04:02:52 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
Message-ID: <gwq5tzURezzpKA9bGiQZBxpKiwfsSXsB0cXFZGBfBtQ=.feb28979-2ec0-4069-a765-e245d5d46ea6@github.com>

On Mon, 3 Mar 2025 08:20:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Is this bug a regression? Why did it start reproducing only now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23837#issuecomment-2696132158

From prr at openjdk.org  Tue Mar  4 04:35:11 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 04:35:11 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <gwq5tzURezzpKA9bGiQZBxpKiwfsSXsB0cXFZGBfBtQ=.feb28979-2ec0-4069-a765-e245d5d46ea6@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <gwq5tzURezzpKA9bGiQZBxpKiwfsSXsB0cXFZGBfBtQ=.feb28979-2ec0-4069-a765-e245d5d46ea6@github.com>
Message-ID: <kU2seZ-jyzkhE-zOUt6JnGdOvdzwtlQKL3eqCNSpV_c=.16c81f32-7523-4f60-84ff-bfad9ca59446@github.com>

On Tue, 4 Mar 2025 04:00:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is this bug a regression? Why did it start reproducing only now?

I probably should let the fixer answer this, but in JBS I saw a note (maybe not publicly visible) that says
> If we check history of this test failure in mach5 with same Exception we see that it has failed in 11, 17 and now in mainline :

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23837#issuecomment-2696164546

From serb at openjdk.org  Tue Mar  4 05:08:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 05:08:52 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
Message-ID: <1HQ5Xhi0TgY-e5lA6euKZGXdao-43c5C3b2qV4I2zSs=.79271be6-b775-4140-baa5-9345551b127f@github.com>

On Mon, 3 Mar 2025 16:52:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year update

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23845#pullrequestreview-2655960125

From abhiscxk at openjdk.org  Tue Mar  4 05:29:59 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Mar 2025 05:29:59 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
 <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
Message-ID: <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>

On Mon, 3 Mar 2025 14:16:56 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix pushed to mac os specific class
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 127:
> 
>> 125:                     AccessibleContext thisAC = accessible.getAccessibleContext();
>> 126:                     Accessible parentAccessible = thisAC.getAccessibleParent();
>> 127:                     if (!(parentAccessible instanceof JSpinner.NumberEditor)) {
> 
> Why do you need all this if the spinner has an accessible role?
> ```jdk-21.0.6+7/src/java.desktop/share/classes/javax/swing/JSpinner.java```
> 
>         public AccessibleRole getAccessibleRole() {
>             return AccessibleRole.SPIN_BOX;
>         }
> 
> Also, there is already getting an a11y parent lower in the code.

Native spinner and Java spinner is not a similar UI component and the issue lies in the text component of JSpinner. I don't find any probable solution in native side implementation of spin box.

This seems a simple workaround fix for the issue right now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1978644965

From abhiscxk at openjdk.org  Tue Mar  4 05:34:57 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Mar 2025 05:34:57 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <kcToSub8SbQv5WhnNr49Xa5wR45ZvBuHiKq6AsyE32M=.67409fe5-d416-4592-8017-9baef06fb10e@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>
 <DKISt9HQf09fylSelhvsHEasGanNAMhTQoyfuUPJgOE=.bcc1bc89-a8c8-421b-b3a0-ea554fef7201@github.com>
 <kcToSub8SbQv5WhnNr49Xa5wR45ZvBuHiKq6AsyE32M=.67409fe5-d416-4592-8017-9baef06fb10e@github.com>
Message-ID: <wQXUhqgMquuidvAaPe93aI9hD3FNPibARUP-5-YAaYI=.27d763da-2c0e-4eaa-b2a9-58952d8c5fc8@github.com>

On Mon, 3 Mar 2025 10:16:42 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Try to debug the native implementation of NSAccessibilityElements? The error might be somewhere there.

I posted my analysis in JBS and root caused the issue in a11y `(NSString *)accessibilityStringForRange:(NSRange)range` API in `NavigableTextAccessibility.m` implementation for `Text Component` but the range value invoked by system seems wrong.

So, this is a workaround fix for the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2696263121

From bpb at openjdk.org  Tue Mar  4 05:37:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 05:37:59 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
Message-ID: <ZefYclv3FYsBbR7hdJf63f4lHTU_kVJbYYUFkP-Iliw=.46ac1fed-7b88-4015-a26a-6181bb002ca5@github.com>

On Mon, 3 Mar 2025 22:56:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
>
>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
> 
> If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.

> @bplb The HTML changes are added.

Thanks, @mickleness, I will file the CSR tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2696267308

From asemenov at openjdk.org  Tue Mar  4 05:49:58 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 4 Mar 2025 05:49:58 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
 <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
 <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>
Message-ID: <6PRBGj0IdZvSvt04LBaGmuvIeP17DwMch0_s2fvJaOM=.159287e3-3f85-4193-a743-7e341354ec16@github.com>

On Tue, 4 Mar 2025 05:27:42 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 127:
>> 
>>> 125:                     AccessibleContext thisAC = accessible.getAccessibleContext();
>>> 126:                     Accessible parentAccessible = thisAC.getAccessibleParent();
>>> 127:                     if (!(parentAccessible instanceof JSpinner.NumberEditor)) {
>> 
>> Why do you need all this if the spinner has an accessible role?
>> ```jdk-21.0.6+7/src/java.desktop/share/classes/javax/swing/JSpinner.java```
>> 
>>         public AccessibleRole getAccessibleRole() {
>>             return AccessibleRole.SPIN_BOX;
>>         }
>> 
>> Also, there is already getting an a11y parent lower in the code.
>
> Native spinner and Java spinner is not a similar UI component and the issue lies in the text component of JSpinner. I don't find any probable solution in native side implementation of spin box.
> 
> This seems a simple workaround fix for the issue right now.

I like this solution, I just ask you to consider replacing the ```instance of``` check with a role comparison?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1978668563

From tr at openjdk.org  Tue Mar  4 06:36:03 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Mar 2025 06:36:03 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
Message-ID: <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>

On Mon, 3 Mar 2025 08:20:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 40:

> 38: /*
> 39:  * @test
> 40:  * @key headful

Can you please add the test summary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978710319

From abhiscxk at openjdk.org  Tue Mar  4 06:42:02 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Mar 2025 06:42:02 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <6PRBGj0IdZvSvt04LBaGmuvIeP17DwMch0_s2fvJaOM=.159287e3-3f85-4193-a743-7e341354ec16@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
 <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
 <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>
 <6PRBGj0IdZvSvt04LBaGmuvIeP17DwMch0_s2fvJaOM=.159287e3-3f85-4193-a743-7e341354ec16@github.com>
Message-ID: <IfK20KgGUq3-qQxiEqHdb3hUsLxBDEhFReJj1X5a4mc=.d192df5d-8b51-4827-afe0-fbc9a024677d@github.com>

On Tue, 4 Mar 2025 05:47:32 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Native spinner and Java spinner is not a similar UI component and the issue lies in the text component of JSpinner. I don't find any probable solution in native side implementation of spin box.
>> 
>> This seems a simple workaround fix for the issue right now.
>
> I like this solution, I just ask you to consider replacing the ```instance of``` check with a role comparison?

ohh ok... role comparison will not work here because the role is "AccessibleRole.TEXT" and we want to ignore the property change only if the parent is a JSpinner with NumberEditor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1978716578

From tr at openjdk.org  Tue Mar  4 06:42:04 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Mar 2025 06:42:04 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
Message-ID: <TeE9svHD4RPcF5h5SC1Fw8OAjIKYTXlGk8KIva7urQ4=.6fedeac9-7dad-4776-a178-27ab98a00e76@github.com>

On Mon, 3 Mar 2025 08:20:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 81:

> 79:         frame.setLocationRelativeTo(null);
> 80:         frame.setVisible(true);
> 81:         button.requestFocusInWindow();

Since the root cause is unknown and you are trying to make the test more robust, should we add a delay after `frame.setVisible(true);` ? I'm just suspecting request focus failure after `setVisible`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978716169

From duke at openjdk.org  Tue Mar  4 06:57:06 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Mar 2025 06:57:06 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing JPEG
 with IndexColorModel
Message-ID: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>

Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.

In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.

Instead:
Now the ImageTypeSpecifier accurately describes the given BufferedImage.

-------------

Commit messages:
 - 8351108: images that are TYPE_BYTE_INDEXED can vary in translucency
 - 8351108: adding failing unit test from ticket
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.org/jdk/pull/23884/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351108
  Stats: 85 lines in 2 files changed: 84 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From psadhukhan at openjdk.org  Tue Mar  4 07:45:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 07:45:42 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v3]
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <R7-TBdVGAIbdjqPAIcnGVq4UXGkXYV_mSd4Vwzv34yY=.a3a53a41-5f55-41b0-92eb-243ddfb614b2@github.com>

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23837/files
  - new: https://git.openjdk.org/jdk/pull/23837/files/840f59ff..8fa01676

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23837/head:pull/23837

PR: https://git.openjdk.org/jdk/pull/23837

From psadhukhan at openjdk.org  Tue Mar  4 07:45:43 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 07:45:43 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>
Message-ID: <-MJu4J1IrjAPIL-lFbHALElv73U_5tgZo1FHyW9QAvY=.3ce272bc-a2f7-474b-968c-a6d6164783f0@github.com>

On Tue, 4 Mar 2025 06:33:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 40:
> 
>> 38: /*
>> 39:  * @test
>> 40:  * @key headful
> 
> Can you please add the test summary.

Added

> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 81:
> 
>> 79:         frame.setLocationRelativeTo(null);
>> 80:         frame.setVisible(true);
>> 81:         button.requestFocusInWindow();
> 
> Since the root cause is unknown and you are trying to make the test more robust, should we add a delay after `frame.setVisible(true);` ? I'm just suspecting request focus failure after `setVisible`.

that's why I added waitForIdle/delay after createShowGUI

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978804150
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978805579

From psadhukhan at openjdk.org  Tue Mar  4 07:48:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 07:48:13 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <kU2seZ-jyzkhE-zOUt6JnGdOvdzwtlQKL3eqCNSpV_c=.16c81f32-7523-4f60-84ff-bfad9ca59446@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <gwq5tzURezzpKA9bGiQZBxpKiwfsSXsB0cXFZGBfBtQ=.feb28979-2ec0-4069-a765-e245d5d46ea6@github.com>
 <kU2seZ-jyzkhE-zOUt6JnGdOvdzwtlQKL3eqCNSpV_c=.16c81f32-7523-4f60-84ff-bfad9ca59446@github.com>
Message-ID: <RJgH5Jmd-oYtM9r7Gr_BNERomZmdViL5NHNMNBj3suY=.4c264e49-30bf-48fc-843d-7017f37c5ff3@github.com>

On Tue, 4 Mar 2025 04:32:45 GMT, Phil Race <prr at openjdk.org> wrote:

> > Is this bug a regression? Why did it start reproducing only now?
> 
> I probably should let the fixer answer this, but in JBS I saw a note (maybe not publicly visible) that says
> 
> > If we check history of this test failure in mach5 with same Exception we see that it has failed in 11, 17 and now in mainline :

it has failed in the past but no bug was raised I presume..Now the bug is raised and it is for ubuntu OCI which has recent history of instability but since this is the only test failed in the CI job it was not thought to be infra issue and so attempt is made at best to make it more robust and less prone to failure..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23837#issuecomment-2696510313

From tr at openjdk.org  Tue Mar  4 08:43:53 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Mar 2025 08:43:53 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <-MJu4J1IrjAPIL-lFbHALElv73U_5tgZo1FHyW9QAvY=.3ce272bc-a2f7-474b-968c-a6d6164783f0@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>
 <-MJu4J1IrjAPIL-lFbHALElv73U_5tgZo1FHyW9QAvY=.3ce272bc-a2f7-474b-968c-a6d6164783f0@github.com>
Message-ID: <bR9ILvzommyX7i0yAAzEVi4ePYJeel_ktP05iudBs_M=.2b88f635-ccd3-40c3-abda-0961021a3bd3@github.com>

On Tue, 4 Mar 2025 07:42:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 81:
>> 
>>> 79:         frame.setLocationRelativeTo(null);
>>> 80:         frame.setVisible(true);
>>> 81:         button.requestFocusInWindow();
>> 
>> Since the root cause is unknown and you are trying to make the test more robust, should we add a delay after `frame.setVisible(true);` ? I'm just suspecting request focus failure after `setVisible`.
>
> that's why I added waitForIdle/delay after createShowGUI

I meant in right after `frame.setVisible(true);`, between line 80 and 81.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978904203

From psadhukhan at openjdk.org  Tue Mar  4 08:59:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 08:59:55 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <bR9ILvzommyX7i0yAAzEVi4ePYJeel_ktP05iudBs_M=.2b88f635-ccd3-40c3-abda-0961021a3bd3@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>
 <-MJu4J1IrjAPIL-lFbHALElv73U_5tgZo1FHyW9QAvY=.3ce272bc-a2f7-474b-968c-a6d6164783f0@github.com>
 <bR9ILvzommyX7i0yAAzEVi4ePYJeel_ktP05iudBs_M=.2b88f635-ccd3-40c3-abda-0961021a3bd3@github.com>
Message-ID: <uis3gbd4IVsNlim5rOnTUSHQZHVqe_yPRtz_WsFeFtI=.5757e543-4426-4584-a701-d39d7021ccca@github.com>

On Tue, 4 Mar 2025 08:41:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> that's why I added waitForIdle/delay after createShowGUI
>
> I meant in right after `frame.setVisible(true);`, between line 80 and 81.

I know what you meant but I am saying its not needed as historically we added delay/waitForIdle after we do setVisible and start the test..
Also requestFocusInWindow is not guranteed to be done by JDK, its just a request...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1978933191

From aivanov at openjdk.org  Tue Mar  4 10:37:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 10:37:55 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <4PL3gXkKim-0CCeRe0gfVcS-DS72agDocYd18HEfKtY=.9b766bb9-6453-4ac2-96ac-005f97d69e8e@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
 <4PL3gXkKim-0CCeRe0gfVcS-DS72agDocYd18HEfKtY=.9b766bb9-6453-4ac2-96ac-005f97d69e8e@github.com>
Message-ID: <qkhLxRwg3VE3HXrx-qNacB2fKe4kGEClkhJ80VLKEMM=.9dd13969-eccd-4502-a618-4f029b54d5f8@github.com>

On Mon, 3 Mar 2025 21:44:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> `return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);`
> 
> I think the old code should be read as:
> 
> * If the method is null, skip the h/w package access check and return.
> * If the method is not null, then perform the h/w package access check and duplicate the data if needed.
> 
> So, when the usage of `isPackageAccessible` was deleted, the null check for the method should also have been removed.

When you put it this way, it makes more sense.

As far as I can see, the `method` variable shouldn't be `null`. Yet if the package wasn't accessible, the cached value couldn't be returned directly, that's why a copy was created.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2697008898

From tr at openjdk.org  Tue Mar  4 11:14:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Mar 2025 11:14:54 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v3]
In-Reply-To: <R7-TBdVGAIbdjqPAIcnGVq4UXGkXYV_mSd4Vwzv34yY=.a3a53a41-5f55-41b0-92eb-243ddfb614b2@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <R7-TBdVGAIbdjqPAIcnGVq4UXGkXYV_mSd4Vwzv34yY=.a3a53a41-5f55-41b0-92eb-243ddfb614b2@github.com>
Message-ID: <oDvwWLMiulS47cchHO1T86-xhYPb1AbSy_OShxRIA5s=.99628f3c-b94e-4d32-9d94-a965fd95f3e7@github.com>

On Tue, 4 Mar 2025 07:45:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add summary

LGTM

-------------

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23837#pullrequestreview-2657022114

From asemenov at openjdk.org  Tue Mar  4 11:15:57 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 4 Mar 2025 11:15:57 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <IfK20KgGUq3-qQxiEqHdb3hUsLxBDEhFReJj1X5a4mc=.d192df5d-8b51-4827-afe0-fbc9a024677d@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
 <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
 <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>
 <6PRBGj0IdZvSvt04LBaGmuvIeP17DwMch0_s2fvJaOM=.159287e3-3f85-4193-a743-7e341354ec16@github.com>
 <IfK20KgGUq3-qQxiEqHdb3hUsLxBDEhFReJj1X5a4mc=.d192df5d-8b51-4827-afe0-fbc9a024677d@github.com>
Message-ID: <KL8nq4qDYgiIaY65cVR6dWC80QRdiezrn2cKa4wnsb4=.418f0c68-79e7-4c8d-9a8e-e9c949c236a0@github.com>

On Tue, 4 Mar 2025 06:39:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I like this solution, I just ask you to consider replacing the ```instance of``` check with a role comparison?
>
> ohh ok... role comparison will not work here because the role is "AccessibleRole.TEXT" and we want to ignore the property change only if the parent is a JSpinner with NumberEditor.

We can check the role of the parent and the current element.
The parent should be a spin box, the current one should be a text element.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1979208646

From abhiscxk at openjdk.org  Tue Mar  4 11:40:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Mar 2025 11:40:56 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <KL8nq4qDYgiIaY65cVR6dWC80QRdiezrn2cKa4wnsb4=.418f0c68-79e7-4c8d-9a8e-e9c949c236a0@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
 <FXaMvnFcB0bR_9iBj8XgVtexaH2FQL2ioLiaoJRmZVU=.ceab0587-3f25-413d-8293-029bbb3dd4b2@github.com>
 <9vEpIF5dnyDMft4mhtQequEsoPHLUPsRMo_5NPie-80=.a2a0ee14-942e-4e9f-a9cb-2a628bcb6b30@github.com>
 <6PRBGj0IdZvSvt04LBaGmuvIeP17DwMch0_s2fvJaOM=.159287e3-3f85-4193-a743-7e341354ec16@github.com>
 <IfK20KgGUq3-qQxiEqHdb3hUsLxBDEhFReJj1X5a4mc=.d192df5d-8b51-4827-afe0-fbc9a024677d@github.com>
 <KL8nq4qDYgiIaY65cVR6dWC80QRdiezrn2cKa4wnsb4=.418f0c68-79e7-4c8d-9a8e-e9c949c236a0@github.com>
Message-ID: <30-QzMD5iPcoieTWG2Fp_XGgZbA431WmvuLhspxYnwI=.8591e7f5-36ef-46f8-af14-a362a240fa3c@github.com>

On Tue, 4 Mar 2025 11:12:55 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> ohh ok... role comparison will not work here because the role is "AccessibleRole.TEXT" and we want to ignore the property change only if the parent is a JSpinner with NumberEditor.
>
> We can check the role of the parent and the current element.
> The parent should be a spin box, the current one should be a text element.

I checked it before, the parent role is `Panel` and current element role is `Text` and that results in inconsistent announcement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1979256513

From aivanov at openjdk.org  Tue Mar  4 12:12:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 12:12:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v8]
In-Reply-To: <upPgxvBO_xWbk_WpNscqaYN0Xkz7BtmpK4DkLr7FaYk=.bf8d6e05-2b83-46c9-9126-d9b0111f9d03@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <1gL0weVb8l4qit443QYXnbR_yNV5CepKZc0oXA_a9qM=.7ce99cc0-35e5-4c3f-ad8a-0c82af8cdf20@github.com>
 <upPgxvBO_xWbk_WpNscqaYN0Xkz7BtmpK4DkLr7FaYk=.bf8d6e05-2b83-46c9-9126-d9b0111f9d03@github.com>
Message-ID: <UuqxWBm4C44_YrQUFHEtcgb3g00HXowllgSYcYskPpA=.6009ed26-1d9a-4a5e-bddc-939534a0d636@github.com>

On Tue, 25 Feb 2025 10:57:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed flag to builtIn
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 115:
> 
>> 113:      * This check is used in {@link #setData(int, byte[])} to prevent modifying
>> 114:      * Built-in profiles.
>> 115:      */
> 
> /**
>      * Set to {@code true} for {@code BuiltInProfile},
>      * remains {@code false} otherwise.
>      * This flag is used in {@link #setData(int, byte[])} to prevent modifying
>      * built-in profiles.
>      */
> 
> There's no need to capitalise ?Built-in?.

It's recommended to use `{@code}` for keywords, therefore both `true` and `false` should be marked up with `{@code}`.

See [How to Write Doc Comments for the Javadoc Tool, A Style Guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide):

> Use `<code>` style for keywords and names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979301473

From asemenov at openjdk.org  Tue Mar  4 12:22:57 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 4 Mar 2025 12:22:57 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
Message-ID: <i3TfG1OG8HoD7tQIxNXKvdL5fO5XcnPRtulSjaenYEg=.b2a7d71a-cede-45ec-b350-ca96b462f67a@github.com>

On Mon, 3 Mar 2025 12:11:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pushed to mac os specific class

LGTM

-------------

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23841#pullrequestreview-2657241992

From aivanov at openjdk.org  Tue Mar  4 12:24:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 12:24:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
Message-ID: <oRZS6LdcjRRxQGmFJSMgK6l0XYZz81_nHIKUq-I3M3Y=.25762131-15fa-43ff-a2ae-d8abf5c5fd24@github.com>

On Sat, 1 Mar 2025 01:11:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc update

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 113:

> 111:     /**
> 112:      * Set to true for {@code BuiltInProfile}, false otherwise.
> 113:      * This check is used in {@link #setData(int, byte[])} to prevent modifying

Suggestion:

     * Set to {@code true} for {@code BuiltInProfile}, {@code false} otherwise.
     * This check is used in {@link #setData(int, byte[])} to prevent modifying


[This suggestion](https://github.com/openjdk/jdk/pull/23606#discussion_r1969536537) isn't fully applied, yet it's marked as resolved.

The [javadoc style guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide) recommends, <q cite="https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide">Use `<code>` style for keywords and names.</q> Therefore both `true` and `false` should be marked up with `{@code}`.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 132:

> 130: 
> 131:         ICC_Profile LRGB = new ICC_ProfileRGB(new ProfileDeferralInfo(
> 132:                 "LINEAR_RGB.pf", ColorSpace.TYPE_RGB, 3, CLASS_DISPLAY));

There should be no additional space added, all these lines in `BuiltInProfile` should remain unmodified when compared to the `master` branch.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1168:

> 1166:      *         the {@code tagSignature}
> 1167:      * @throws IllegalArgumentException if this is a built-in profile for one
> 1168:      *         of the pre-defined ColorSpaces, i.e. those which can be obtained

Suggestion:

     *         of the pre-defined color spaces, i.e. those which can be obtained

Here, you refer to _?color spaces?_ as the concept rather than the [`ColorSpace`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ColorSpace.html) class, therefore regular capitalisation and spelling applies.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2657212692
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979306472
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979320565
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979315193

From aivanov at openjdk.org  Tue Mar  4 12:24:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 12:24:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <LuaTZF8nWYUfSkBABZhoXTTZu-rQKy9ymkW5vw-rqi4=.8b9ae7ae-a7db-441c-8dd7-edf8f947a545@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <q9_IJTpPbTxAg2NK381FpfX2nGy7CQtplAQ9yALZznQ=.1c7866bd-0093-499c-859e-344b4cee2f9a@github.com>
 <LuaTZF8nWYUfSkBABZhoXTTZu-rQKy9ymkW5vw-rqi4=.8b9ae7ae-a7db-441c-8dd7-edf8f947a545@github.com>
Message-ID: <hSGeG8z5YivxKsoNFnQp7vGVs58y6f_KCbLaclZ59rs=.938dc974-e1b6-4e1d-8c0b-66106ccaab55@github.com>

On Mon, 3 Mar 2025 18:27:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This note was added based on the suggestion here: https://github.com/openjdk/jdk/pull/23606#discussion_r1976123437
>
> Oh you meant `</p>` tag :) 
> It was not rendered in github comment.

Yes, usually the closing `</p>` tag is omitted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979309149

From aivanov at openjdk.org  Tue Mar  4 12:47:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 12:47:12 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
Message-ID: <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>

On Mon, 3 Mar 2025 18:01:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1169:
>> 
>>> 1167:      * @throws IllegalArgumentException if this is a built-in profile for one
>>> 1168:      *         of the pre-defined ColorSpaces, i.e. those which can be obtained
>>> 1169:      *         by calling {@code ICC_Profile.getInstance(int colorSpaceID)}
>> 
>> can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?
>
> The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.
> Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.
> And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.

> can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?

This has been [my suggestion](https://github.com/openjdk/jdk/pull/23606#discussion_r1968073992) since the start of this code review.

> The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.  
> Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.

I agree, an exception should be thrown if modification isn't allowed.

> And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.

Therefore we can throw <code>Illegal<i>State</i>Exception</code> instead of <code>Illegal<i>Argument</i>Exception</code>.

Quoting here [Harshitha's reply](https://github.com/openjdk/jdk/pull/23606#discussion_r1968263836):

> As Phil mentioned earlier, the already documented exception IAE for .setData() outweighs introducing a new exception.

Using the exception which clearly describes the reason why it was thrown outweighs re-using an already documented exception?

> Using an existing exception would mean less disruption to any existing applications using the Java API.

?especially because the search for usages of `setData` revealed that there are no usages of `setData` which will be affected by the proposed change.

If I'm not mistaken, the search also showed that no usages of `setData` handle `IllegalArgumentException`???thus apps will be equally unprepared to any type of an unchecked exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979357419

From aivanov at openjdk.org  Tue Mar  4 13:07:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 13:07:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
 <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
Message-ID: <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>

On Mon, 3 Mar 2025 20:14:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This builtin flag check is exclusively for JDK built-in profiles created within the private interface `BuiltInProfile` and not applicable if an application loads the profile by serialization. 
>> 
>> Since `BuiltInProfile` interface and `builtin` flag are private we could not include it in javadoc hence used ICC_Profile.getInstance(int colorspaceID) to specify built-in profile. Please let us know if the javadoc sounds okay or requires any changes?
>
>> This builtin flag check is exclusively for JDK built-in profiles created within the private interface `BuiltInProfile` and not applicable if an application loads the profile by serialization.
> 
> The built-in profiles can be serialized and deserialized, [see](https://github.com/openjdk/jdk/blob/c4b516dfe7c5a5fddd4d9c97a21f5f36bf845646/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1573). This means the application may get a reference to the profile not only via the getInstance(id) method. Therefore, the new spec is not strictly accurate regarding ICC_Profile.getInstance(int colorSpaceID), but I am not sure that we should mention serialisation here.
> 
> **Note:** 
> The new Javadoc for the new private built-in flag is "public" via the serialized form of the class. It probably should be marked as transient, so it will only be set to true when the built-in profile is loaded via serialization. In all other cases, it will be false.

This is an interesting observation.

Are the unserialized built-in profiles mapped to their corresponding singleton instances? I presume it's the case. Then, the `builtIn` flag will still be set to `true` in the returned object.

**Should the serialized form be preserved?**

If the `builtIn` field is `transient`, built-in profiles written by JDK 25 (mainline) could still be read in previous versions and vice versa. This will improve the backward compatibility.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1979392138

From aivanov at openjdk.org  Tue Mar  4 14:22:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 14:22:57 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v3]
In-Reply-To: <R7-TBdVGAIbdjqPAIcnGVq4UXGkXYV_mSd4Vwzv34yY=.a3a53a41-5f55-41b0-92eb-243ddfb614b2@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <R7-TBdVGAIbdjqPAIcnGVq4UXGkXYV_mSd4Vwzv34yY=.a3a53a41-5f55-41b0-92eb-243ddfb614b2@github.com>
Message-ID: <7gzZ-YMZFESzrRJ6u71oE4zgjZ0ezWIk4SsRW6_PBXU=.6832abc9-a92b-4f9e-b915-50302f50f2e1@github.com>

On Tue, 4 Mar 2025 07:45:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add summary

Looks good to me?

?except for a few comments.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 1:

> 1: /*

Could you remove unused imports? There are 5 unused imports.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 58:

> 56:         try {
> 57:             robot = new Robot();
> 58:             SwingUtilities.invokeAndWait(() -> createAndShowGUI());

Suggestion:

            SwingUtilities.invokeAndWait(bug4213634::createAndShowGUI);
);

A method reference can be used.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 88:

> 86:     private static void test() throws Exception {
> 87: 
> 88:         Util.hitMnemonics(robot, KeyEvent.VK_1);

Suggestion:

    private static void test() throws Exception {
        Util.hitMnemonics(robot, KeyEvent.VK_1);

The blank line at the start of a method is redundant and may be removed safely.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23837#pullrequestreview-2657733751
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979541520
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979549853
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979545492

From aivanov at openjdk.org  Tue Mar  4 14:22:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 14:22:58 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v2]
In-Reply-To: <uis3gbd4IVsNlim5rOnTUSHQZHVqe_yPRtz_WsFeFtI=.5757e543-4426-4584-a701-d39d7021ccca@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <z8xbbTvwJbF8JU7low79rrOyBdT68uQesrjavhgDQ1c=.102b5365-2472-453d-b679-4e3348088f89@github.com>
 <B7FFw1E2X0ICvVan4tN5u-I88keJxrihZb7ZL1LVEQA=.73a9b121-85fa-4009-9e7e-19b4aebd9207@github.com>
 <-MJu4J1IrjAPIL-lFbHALElv73U_5tgZo1FHyW9QAvY=.3ce272bc-a2f7-474b-968c-a6d6164783f0@github.com>
 <bR9ILvzommyX7i0yAAzEVi4ePYJeel_ktP05iudBs_M=.2b88f635-ccd3-40c3-abda-0961021a3bd3@github.com>
 <uis3gbd4IVsNlim5rOnTUSHQZHVqe_yPRtz_WsFeFtI=.5757e543-4426-4584-a701-d39d7021ccca@github.com>
Message-ID: <Xv_WUT187ChBJDIvi4DeYGihW7Hr409j-NmGXfLMU0Y=.b0671d22-096f-484d-847f-b44c08e8ddc5@github.com>

On Tue, 4 Mar 2025 08:57:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I meant in right after `frame.setVisible(true);`, between line 80 and 81.
>
> I know what you meant but I am saying its not needed as historically we added delay/waitForIdle after we do setVisible and start the test..
> Also requestFocusInWindow is not guranteed to be done by JDK, its just a request...

Now that the text component is gone, the frame has the only focusable component which is the button. So the button should get the focus even without the request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979557307

From aivanov at openjdk.org  Tue Mar  4 14:22:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 14:22:58 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v3]
In-Reply-To: <QJ3zaRbNR_99xQD-kCe8Lf3UdNde36cyZkR30vc-UcQ=.0dca51cf-9111-4371-be75-b3c3adb0346e@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <QJ3zaRbNR_99xQD-kCe8Lf3UdNde36cyZkR30vc-UcQ=.0dca51cf-9111-4371-be75-b3c3adb0346e@github.com>
Message-ID: <978Q9m0smyxwjQlHmY9o0bThhGrRhwIwgPdQ-SC1vjw=.99b97734-ea30-4734-bb97-98a84c53d87c@github.com>

On Fri, 28 Feb 2025 18:59:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add summary
>
> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 42:
> 
>> 40:  * @key headful
>> 41:  * @bug 4213634 8017187
>> 42:  * @library ../../regtesthelpers
> 
> Suggestion:
> 
>  * @library /java/awt/regtesthelpers

It must be `/javax/swing/regtesthelpers`.

There's also a `Util` class in `/java/awt/regtesthelpers` but it doesn't have the `hitMnemonics` method.

(It's somewhat confusing.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979539843

From aivanov at openjdk.org  Tue Mar  4 14:25:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 14:25:59 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v3]
In-Reply-To: <978Q9m0smyxwjQlHmY9o0bThhGrRhwIwgPdQ-SC1vjw=.99b97734-ea30-4734-bb97-98a84c53d87c@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <QJ3zaRbNR_99xQD-kCe8Lf3UdNde36cyZkR30vc-UcQ=.0dca51cf-9111-4371-be75-b3c3adb0346e@github.com>
 <978Q9m0smyxwjQlHmY9o0bThhGrRhwIwgPdQ-SC1vjw=.99b97734-ea30-4734-bb97-98a84c53d87c@github.com>
Message-ID: <cuaQgn8nGUamfyl-S7n7x3gG2aVUKZJKmLkK3fxH4Rk=.3e95cb2a-629a-4ca6-8f6e-5983304d2b65@github.com>

On Tue, 4 Mar 2025 14:11:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 42:
>> 
>>> 40:  * @key headful
>>> 41:  * @bug 4213634 8017187
>>> 42:  * @library ../../regtesthelpers
>> 
>> Suggestion:
>> 
>>  * @library /java/awt/regtesthelpers
>
> It must be `/javax/swing/regtesthelpers`.
> 
> There's also a `Util` class in `/java/awt/regtesthelpers` but it doesn't have the `hitMnemonics` method.
> 
> (It's somewhat confusing.)

To be clear, leaving `@library ../../regtesthelpers` is fine with me, I was objecting to Harshitha's suggestion. If an absolute path is used, it must refer to the Swing version of the `Util` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1979566870

From azvegint at openjdk.org  Tue Mar  4 15:45:01 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 4 Mar 2025 15:45:01 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null [v3]
In-Reply-To: <4ZREpLZ0cY20tX3DMcqr9r_nzzdaLAfN8f0ha80duko=.446f6d9a-3c89-4d0a-adde-6c42965bf859@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <oH05PoX2t9zJfR9jlEneFht4KySyZ61vgAMYp1Qv4tY=.233df53e-43d7-48a6-9857-435d698b9ab9@github.com>
 <4ZREpLZ0cY20tX3DMcqr9r_nzzdaLAfN8f0ha80duko=.446f6d9a-3c89-4d0a-adde-6c42965bf859@github.com>
Message-ID: <KwJ0px4pZ81Y6CgmEplBKby4ORbOTzpGGKnpU5sftBs=.3e74359d-9752-4414-8d93-0a658d917f64@github.com>

On Mon, 3 Mar 2025 20:39:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   year update
>
> src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 80:
> 
>> 78: 
>> 79:         try {
>> 80:             return CACHE.get(signature);
> 
> Is it possible to create a test for this patch?

We have a slowdown [JDK-8350573](https://bugs.openjdk.org/browse/JDK-8350573) of the `java/beans/XMLDecoder/8028054/TestMethodFinder.java` test

The possible test would be to set a timeout for it, but is depends on the hardware:

> On my test machine the test runtime goes from ~ 40s (hash of the change before [JDK-8344891](https://bugs.openjdk.org/browse/JDK-8344891)) to ~ 1:40 ([JDK-8344891](https://bugs.openjdk.org/browse/JDK-8344891)) .

> Locally on my M1 Macbook pro this test runs in ~4 seconds before and in ~28 seconds after [JDK-8344891](https://bugs.openjdk.org/browse/JDK-8344891) change.

So I believe it would be better to track anomalies by test execution time history in the CI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1979713655

From azvegint at openjdk.org  Tue Mar  4 15:45:01 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 4 Mar 2025 15:45:01 GMT
Subject: Integrated: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <Rv06afxUffPjGe07XcN8cCdGsO7XMSt3X4eq6RAcG7U=.49bb716c-6549-47e2-a7c6-adaa3664c53f@github.com>

On Fri, 28 Feb 2025 14:41:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

This pull request has now been integrated.

Changeset: 216f113f
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/216f113f8b377054bcfccf875ab29e967164d8ab
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8344892: beans/finder/MethodFinder.findMethod incorrectly returns null

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/23845

From azvegint at openjdk.org  Tue Mar  4 15:59:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 4 Mar 2025 15:59:54 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <Vj9ByNq-R-2qk0Gk4KeCZsfQPm7UK30Zc2GH4kH4NQA=.8938499b-aede-4e99-9dfc-f17d54ee224f@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
 <Vj9ByNq-R-2qk0Gk4KeCZsfQPm7UK30Zc2GH4kH4NQA=.8938499b-aede-4e99-9dfc-f17d54ee224f@github.com>
Message-ID: <gn--19zFgIW6LZzqKckOJCjYyGzChc7kfbcszr2GOBA=.b5ce7f28-5fbd-414f-b9b1-ba6d8bbe8734@github.com>

On Mon, 3 Mar 2025 21:19:26 GMT, Phil Race <prr at openjdk.org> wrote:

> What about, if we are on Wayland, behave the same in single-screen as you say happens any way with multi-screen - report only one resolution - the current / default one ?


This effectively sounds like `GraphicsDevice#isDisplayChangeSupported() == false`.

> I suggest this in part because I am not sure what the impact is of having the resolution be "emulated". If the app, and AWT think there's a different resolution than there really is, rendering quality could be affected.

I've so far only been able to think of one case where such a screen resolution change might be needed at all:
Some game that can't have decent performance at the native screen resolution.

So I left this option with the ability to change the resolution. Yes, rendering quality may drop, but we can always go back later to the option where the only available resolution is the native one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23774#issuecomment-2698135159

From psadhukhan at openjdk.org  Tue Mar  4 16:31:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 16:31:52 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v4]
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <PKZdGL1WE2vxpZplVhbBQ6q-coJ_J7ACY_cVA2-D3B4=.b94fd92b-be6f-42da-99ad-48e19acc866f@github.com>

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23837/files
  - new: https://git.openjdk.org/jdk/pull/23837/files/8fa01676..5857ee09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23837/head:pull/23837

PR: https://git.openjdk.org/jdk/pull/23837

From aivanov at openjdk.org  Tue Mar  4 16:46:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 16:46:54 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails [v4]
In-Reply-To: <PKZdGL1WE2vxpZplVhbBQ6q-coJ_J7ACY_cVA2-D3B4=.b94fd92b-be6f-42da-99ad-48e19acc866f@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <PKZdGL1WE2vxpZplVhbBQ6q-coJ_J7ACY_cVA2-D3B4=.b94fd92b-be6f-42da-99ad-48e19acc866f@github.com>
Message-ID: <ncvluecD4i1OVU9XdTsTVoIh1Zqo1qxem4j04tHC74E=.85c729e6-885f-4276-a30b-993b803b5b8d@github.com>

On Tue, 4 Mar 2025 16:31:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23837#pullrequestreview-2658285958

From serb at openjdk.org  Tue Mar  4 16:56:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 16:56:21 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v5]
In-Reply-To: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
Message-ID: <st664ywW63nE80Xt1-BW7YGljf8E15AAAaiX_k-5dnE=.56066b8b-615a-47b5-b961-d89e88695b38@github.com>

> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
> 
> Notes:
>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
> 
> @azvegint @aivanov-jdk please take a look.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - copyright
 - Merge branch 'openjdk:master' into JDK-8339561
 - more volatiles
 - revert change reported in JDK-8339791
 - trigger github for new content
 - trigger github for new content
 - Merge branch 'master' into JDK-8339561
 - Merge branch 'openjdk:master' into JDK-8339561
 - Update bug4490179.java
 - PR review part 1
 - ... and 3 more: https://git.openjdk.org/jdk/compare/216f113f...c37b252a

-------------

Changes: https://git.openjdk.org/jdk/pull/20861/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20861&range=04
  Stats: 184 lines in 7 files changed: 58 ins; 43 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/20861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20861/head:pull/20861

PR: https://git.openjdk.org/jdk/pull/20861

From serb at openjdk.org  Tue Mar  4 16:56:22 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 16:56:22 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v4]
In-Reply-To: <l1XII0UKkArOuHcefTAJq_agPHt2coU8iMh9vFohLKA=.9562ca80-22f7-4eef-9ea4-4c83159908e5@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
 <l1XII0UKkArOuHcefTAJq_agPHt2coU8iMh9vFohLKA=.9562ca80-22f7-4eef-9ea4-4c83159908e5@github.com>
Message-ID: <MQAD4VeUflbbVu5rNkJbrPmP_5FYdyK0tduEVSEgwUE=.d19aaee8-85a0-4bba-bc86-889b3bcfdd3a@github.com>

On Thu, 17 Oct 2024 03:17:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
>> 
>> Notes:
>>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
>> 
>> @azvegint @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8339561
>  - Update bug4490179.java
>  - PR review part 1
>  - Update ProblemList.txt
>  - add try/finally
>  - 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may fail after JDK-8327401

The patch is tweaked here and there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20861#issuecomment-2698320686

From serb at openjdk.org  Tue Mar  4 16:56:22 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Mar 2025 16:56:22 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v5]
In-Reply-To: <Ta5ZMw5GGCxXzPrgBdTNSofBDZiFQb7J0owGLiW7f8M=.15fbd630-3af1-4319-8640-af97ec074ae7@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
 <gcx7ONrZbHWzpVXqjZwaa8Gc1zTYj-H0RtictQv_S3Y=.f708d7bd-5f4b-4408-a226-557b0baf2a4e@github.com>
 <Ta5ZMw5GGCxXzPrgBdTNSofBDZiFQb7J0owGLiW7f8M=.15fbd630-3af1-4319-8640-af97ec074ae7@github.com>
Message-ID: <kDVyqhSkaiNJBElvHpqC1vkA3SrVLmXGM92pI9y3eHE=.7ef6b165-c084-4592-b4fc-7a6d10f900de@github.com>

On Mon, 16 Sep 2024 11:38:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/List/KeyEventsTest/KeyEventsTest.java line 53:
>> 
>>> 51: 
>>> 52: public class KeyEventsTest {
>>> 53:     private volatile TestState currentState;
>> 
>> I'd rather not declare it a `volatile`. It could give a false impression of being thread-safe but it is not. The `volatile` modifier has a meaning only when it's written and read subsequently. If the reference doesn't change, it has no effect on the visibility of the internal object state.
>> 
>> The value is assigned to `currentState` while holding a lock `LOCK`.
>> 
>> At the same time, `currentState.setAction(true)` is called without any synchronisation and adding `volatile` won't make the change of the state thread-safe.
>
> Submitted [JDK-8340196](https://bugs.openjdk.org/browse/JDK-8340196): _j.a/List/KeyEventsTest/KeyEventsTest: TestState currentState is not thread-safe_.

I think as of now it should be good enough, why do you think volatile will not help here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20861#discussion_r1979853674

From psadhukhan at openjdk.org  Tue Mar  4 17:04:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Mar 2025 17:04:08 GMT
Subject: Integrated: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <VmKo0iw6Rj2W7EhyWgbI_0Y2z3tS4l5zDUNx113jz4c=.2d8a991c-d849-4fba-b613-f81a8478e9d8@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

This pull request has now been integrated.

Changeset: daf0213a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/daf0213abc2c860246564b361061dbda9bd9982f
Stats:     59 lines in 1 file changed: 8 ins; 20 del; 31 mod

8350924: javax/swing/JMenu/4213634/bug4213634.java fails

Reviewed-by: aivanov, tr

-------------

PR: https://git.openjdk.org/jdk/pull/23837

From abhiscxk at openjdk.org  Tue Mar  4 18:26:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Mar 2025 18:26:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v17]
In-Reply-To: <rJaQOc-KMZChDjXxcXYDktOnmrhV0u4Z-k2KI2xOyNc=.69c0c464-55f8-47b9-a2cf-34646045f873@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <rJaQOc-KMZChDjXxcXYDktOnmrhV0u4Z-k2KI2xOyNc=.69c0c464-55f8-47b9-a2cf-34646045f873@github.com>
Message-ID: <7aLt7Cn-eNFOP_sDDCnRuYldjUudkxfs3WQgMoFWtLI=.0188e5bd-89df-4236-baaa-610441246777@github.com>

On Fri, 28 Feb 2025 03:45:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test rename

Ran test on windows 11 machine and the menu items layout seems ok to me.
Don't have windows 10 machine to test.

Few test changes are required for consistency.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 664:

> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")
> 663:             && (Integer.parseInt(System.getProperty("os.name").
> 664:                 replaceAll("[^0-9]", "")) >= 11)

Suggestion:

            && (Integer.parseInt(System.getProperty("os.name")
                .replaceAll("[^0-9]", "")) >= 11)

May shift `. operator` on next line for continuation.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 28:

> 26:  * @bug 8348760
> 27:  * @summary Verify if RadioButton is shown if JRadioButtonMenuItem
> 28:  *          is rendered with ImageIcon in WindowsLookAndFeel

JCheckBoxMenuItem is missing in summary. Should be rephrased.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 32:

> 30:  * @library /java/awt/regtesthelpers
> 31:  * @build PassFailJFrame
> 32:  * @run main/manual TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem

File name is different than the class name, jtreg test failed with `Error. can't find TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem in test directory or libraries`

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 38:

> 36: import java.awt.Graphics;
> 37: import java.awt.image.BufferedImage;
> 38: import javax.swing.AbstractButton;

May add a blank line between awt and swing imports.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 47:

> 45: 
> 46: import javax.swing.JMenu;
> 47: import javax.swing.JMenuBar;

Please sort the imports.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 60:

> 58: 
> 59:         Clicking on the Menu will show a
> 60:         RadioButtonMenuItem group with 3 radiobutton menuitems

Suggestion:

        JRadioButtonMenuItem group with 3 radiobutton menuitems


keep it same as JCheckBoxMenuItem below.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 61:

> 59:         Clicking on the Menu will show a
> 60:         RadioButtonMenuItem group with 3 radiobutton menuitems
> 61:         and a JCheckBoxMenuItem group with 3 checkbox menuitems

For consistency, keep period everywhere else remove it.
Suggestion:

        and a JCheckBoxMenuItem group with 3 checkbox menuitems.

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 65:

> 63:         First radio button menuitem is selected with imageicon of a red square.
> 64:         Second radiobutton menuitem is unselected with imageicon.
> 65:         Third radiobutton menuItem is unselected without imageicon.

`Either radio button or radiobutton`, should be consistent

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 74:

> 72:         a bullet is shown alongside the imageicon and
> 73:         for first JCheckBoxMenuItem with imageicon
> 74:         a checkmark is shown alongside the image icon.

for consistency
`either imageicon or image icon`

-------------

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2658519093
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979982189
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979969302
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979963728
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979971880
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979970932
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979973758
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979966221
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979967125
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1979976178

From prr at openjdk.org  Tue Mar  4 20:05:58 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 20:05:58 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
Message-ID: <HDoXFEs3lSVmVaByvi3KEV89mJQv38uhjdF5GvREA9A=.c23364e7-9d2c-4560-a9ce-fc22b0939415@github.com>

On Mon, 3 Mar 2025 22:56:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
> 
> If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.

Yes, please do. We need it in the PR for the CSR to be valid.

Meanwhile, I have run this through our CI testing again and it looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2698773841

From prr at openjdk.org  Tue Mar  4 20:10:59 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 20:10:59 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
Message-ID: <itw-wgN7mWuTPJDshZopBBdTBHCSdza8xdlHmcAz5Oc=.b9ed33c5-dc72-4b64-8e65-2727dfbea2c1@github.com>

On Tue, 25 Feb 2025 16:40:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Wayland clients are by design not allowed to change the resolution in Wayland.
>> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
>> 
>> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
>> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
>> 
>> ---
>> 
>> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
>> 
>> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
>> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
>> 
>> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
>> 
>> ---
>> 
>> Testing looks good (manual + automated).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoResizeEventOnDMChangeTest update

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23774#pullrequestreview-2658867365

From bpb at openjdk.org  Tue Mar  4 20:21:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 20:21:54 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
 <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
Message-ID: <3ibxPPAR7dIR9gbPL8c5R3KHreeeKtWz5k13cP1yiUM=.226dcad9-ab59-4a90-b26b-f76250ae7960@github.com>

On Tue, 4 Mar 2025 03:38:37 GMT, Jeremy <duke at openjdk.org> wrote:

>>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
>> 
>> If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.
>
> @bplb The HTML changes are added.

> @mickleness please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8160327](https://bugs.openjdk.org/browse/JDK-8160327) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

@mickleness Let me know if you have trouble filing a CSR in which case I will do it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2698812926

From prr at openjdk.org  Tue Mar  4 20:28:08 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 20:28:08 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
Message-ID: <tt65i_iRYxyiy_r2NZck3oWOeFklqwXl1as6F9nrVNI=.aa5b4b47-9b17-4cb9-974c-386ed7329662@github.com>

On Tue, 4 Mar 2025 03:41:10 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: adding "Reading Thumbnail Images" for Exif marker changes
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22898#pullrequestreview-2658902589

From prr at openjdk.org  Tue Mar  4 20:28:09 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 20:28:09 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
 <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
Message-ID: <4YNnYdjMrSpXTPSjWYjAwqDlJr0tnE3WHvA-wViEH4g=.6128a6a0-3bba-45e0-b849-fb8bb3cdcf69@github.com>

On Tue, 4 Mar 2025 03:38:37 GMT, Jeremy <duke at openjdk.org> wrote:

>>> Regarding the CSR proposal: that proposal looks accurate to me. I have no experience with CSR proposals/wording.
>> 
>> If you are agreed on my proposed wording, please include the HTML change in the PR and I will then create and manage the CSR.
>
> @bplb The HTML changes are added.

> > @mickleness please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8160327](https://bugs.openjdk.org/browse/JDK-8160327) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.
> 
> @mickleness Let me know if you have trouble filing a CSR in which case I will do it.

I created https://bugs.openjdk.org/browse/JDK-8351218 - @bplb please fill it in and I'll review it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2698826323

From azvegint at openjdk.org  Tue Mar  4 20:58:58 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 4 Mar 2025 20:58:58 GMT
Subject: Integrated: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call
In-Reply-To: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
Message-ID: <dFipH4lAbBNdozl9zwaLWkzZSQBdwoJJBJLGYimV2Jo=.bf442b26-c7d9-4c8a-8d27-d29a4d354eca@github.com>

On Tue, 25 Feb 2025 12:07:11 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Wayland clients are by design not allowed to change the resolution in Wayland.
> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
> 
> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
> 
> ---
> 
> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
> 
> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
> 
> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
> 
> ---
> 
> Testing looks good (manual + automated).

This pull request has now been integrated.

Changeset: 29de20db
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29de20dbc22e0b68698a1b9cb1241ae5861a6b9a
Stats:     88 lines in 4 files changed: 84 ins; 1 del; 3 mod

8280991: [XWayland] No displayChanged event after setDisplayMode call

Reviewed-by: honkar, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23774

From aivanov at openjdk.org  Tue Mar  4 21:21:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 21:21:54 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v5]
In-Reply-To: <kDVyqhSkaiNJBElvHpqC1vkA3SrVLmXGM92pI9y3eHE=.7ef6b165-c084-4592-b4fc-7a6d10f900de@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
 <gcx7ONrZbHWzpVXqjZwaa8Gc1zTYj-H0RtictQv_S3Y=.f708d7bd-5f4b-4408-a226-557b0baf2a4e@github.com>
 <Ta5ZMw5GGCxXzPrgBdTNSofBDZiFQb7J0owGLiW7f8M=.15fbd630-3af1-4319-8640-af97ec074ae7@github.com>
 <kDVyqhSkaiNJBElvHpqC1vkA3SrVLmXGM92pI9y3eHE=.7ef6b165-c084-4592-b4fc-7a6d10f900de@github.com>
Message-ID: <vxl3gJOdw2aGIMF3IGgx-Tc6KXARXsR0i0OYoxOpzf0=.a3866b2d-f55c-4d82-922b-ec70b73b4a29@github.com>

On Tue, 4 Mar 2025 16:53:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think as of now it should be good enough

That's the problem, the presence of the `volatile` modifier creates a false sense of thread-safety, this is why I'd rather not add it.

> why do you think volatile will not help here?

The `volatile` modifier guarantees that a thread which reads from the `volatile` field will see everything that occurred before a (new) reference was written to the `volatile` field. Yet there are no guarantees another thread will see any modifications to fields of the object the reference to which is stored in the `volatile` field.

And this test does exactly this: it writes a reference into the `currentState` field and then it modifies the fields of the object stored in `currentState`. There are no guarantees that `currentState.setAction(true)` will result in `currentState.getAction()` returning `true`.

If you also declare `TestState.action` as `volatile` or use `AtomicBoolean`, it could be enough to safely access the `currentState` field from two threads. Other fields are final, so they can't be modified, and therefore they don't change after another thread sees the reference to `TestState` object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20861#discussion_r1980247699

From aivanov at openjdk.org  Tue Mar  4 21:26:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Mar 2025 21:26:05 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v5]
In-Reply-To: <st664ywW63nE80Xt1-BW7YGljf8E15AAAaiX_k-5dnE=.56066b8b-615a-47b5-b961-d89e88695b38@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
 <st664ywW63nE80Xt1-BW7YGljf8E15AAAaiX_k-5dnE=.56066b8b-615a-47b5-b961-d89e88695b38@github.com>
Message-ID: <4SdFee3Zddo5Ho390aHAnZi_2dCZggoD2Rx1IHM1aGI=.abe051ff-5b1f-4ac6-a19d-c0d58f974aca@github.com>

On Tue, 4 Mar 2025 16:56:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
>> 
>> Notes:
>>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
>> 
>> @azvegint @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - copyright
>  - Merge branch 'openjdk:master' into JDK-8339561
>  - more volatiles
>  - revert change reported in JDK-8339791
>  - trigger github for new content
>  - trigger github for new content
>  - Merge branch 'master' into JDK-8339561
>  - Merge branch 'openjdk:master' into JDK-8339561
>  - Update bug4490179.java
>  - PR review part 1
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/216f113f...c37b252a

test/jdk/java/awt/Paint/ButtonRepaint.java line 51:

> 49:                     frame.dispose();
> 50:                 }
> 51:             }

Would it be cleaner this way?
Suggestion:

            Frame frame = new Frame();
            try {
                frame.setSize(300, 300);
                frame.setLocationRelativeTo(null);
                ButtonRepaint button = new ButtonRepaint();
                frame.add(button);
                frame.setVisible(true);
                sleep();
                button.test();
            } finally {
                frame.dispose();
            }

This avoids the `null`-check in the `finally` block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20861#discussion_r1980253274

From prr at openjdk.org  Tue Mar  4 21:45:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 21:45:53 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <ObEHBL-EJCsNKnXCdxCGE2Zl960Ldqrry27FV6ysYJc=.ee1c4f26-10e2-4b00-a076-979e0ad73040@github.com>

On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy <duke at openjdk.org> wrote:

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:

> 921:             int bufferedImageType = ((BufferedImage)image).getType();
> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {

So we'll no longer use a singleton IST for images with an ICM.
I don't know how much that matters though. They probably aren't heavyweight compared to the image writing.
The alternative - which I'll mention, which isn't the same as recommend - is to check if ColorModel.getTransparency() == OPAQUE before using the singleton, since we know that's the case it maps to.

The BYTE_INDEXED case code in getSpecifier(..) isn't dead code, because it is still used in
public static  ImageTypeSpecifier createFromBufferedImageType(int bufferedImageType)
In that case, there's not  enough information to do anything except "pick one", so it is caveat emptor for callers of  that API in such a case, and no need to do anything there.

I'll have to run this through our testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980278512

From bpb at openjdk.org  Tue Mar  4 22:51:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 22:51:05 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <4YNnYdjMrSpXTPSjWYjAwqDlJr0tnE3WHvA-wViEH4g=.6128a6a0-3bba-45e0-b849-fb8bb3cdcf69@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
 <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
 <4YNnYdjMrSpXTPSjWYjAwqDlJr0tnE3WHvA-wViEH4g=.6128a6a0-3bba-45e0-b849-fb8bb3cdcf69@github.com>
Message-ID: <OJsb37ZnK8O4UKAcVwT00L6_gEhwtRj86rvciyEJH5U=.161bde5c-e093-4f6f-a3a7-4ec730e1d3ed@github.com>

On Tue, 4 Mar 2025 20:24:51 GMT, Phil Race <prr at openjdk.org> wrote:

> I created https://bugs.openjdk.org/browse/JDK-8351218

I intended to do that this afternoon.

> @bplb please fill it in and I'll review it.
> FWIW I don't think Jeremy has a JBS account .. so you'll have to do it.

Will do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2699154152

From duke at openjdk.org  Tue Mar  4 23:15:52 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Mar 2025 23:15:52 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <ObEHBL-EJCsNKnXCdxCGE2Zl960Ldqrry27FV6ysYJc=.ee1c4f26-10e2-4b00-a076-979e0ad73040@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <ObEHBL-EJCsNKnXCdxCGE2Zl960Ldqrry27FV6ysYJc=.ee1c4f26-10e2-4b00-a076-979e0ad73040@github.com>
Message-ID: <PvdnHNMkOp0JcMH0Vn3QlW6TGtUBkCmsM70ciNKrRTY=.6370064b-a5b3-4356-ae42-955acf623ee5@github.com>

On Tue, 4 Mar 2025 21:43:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:
> 
>> 921:             int bufferedImageType = ((BufferedImage)image).getType();
>> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {
> 
> So we'll no longer use a singleton IST for images with an ICM.
> I don't know how much that matters though. They probably aren't heavyweight compared to the image writing.
> The alternative - which I'll mention, which isn't the same as recommend - is to check if ColorModel.getTransparency() == OPAQUE before using the singleton, since we know that's the case it maps to.
> 
> The BYTE_INDEXED case code in getSpecifier(..) isn't dead code, because it is still used in
> public static  ImageTypeSpecifier createFromBufferedImageType(int bufferedImageType)
> In that case, there's not  enough information to do anything except "pick one", so it is caveat emptor for callers of  that API in such a case, and no need to do anything there.
> 
> I'll have to run this through our testing.

Right.

If we value cached singletons: it'd be easy to break this up into 3 basic cached ImageTypeSpecifiers (one for each Transparency constant: OPAQUE, BITMASK, TRANSLUCENT). That would also satisfy the attached unit test and the original TwelveMonkeys complaint. I started with what I thought was the simplest proposal (in this PR), but I'm happy to explore other options if we want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980403056

From prr at openjdk.org  Tue Mar  4 23:28:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 23:28:53 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <PvdnHNMkOp0JcMH0Vn3QlW6TGtUBkCmsM70ciNKrRTY=.6370064b-a5b3-4356-ae42-955acf623ee5@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <ObEHBL-EJCsNKnXCdxCGE2Zl960Ldqrry27FV6ysYJc=.ee1c4f26-10e2-4b00-a076-979e0ad73040@github.com>
 <PvdnHNMkOp0JcMH0Vn3QlW6TGtUBkCmsM70ciNKrRTY=.6370064b-a5b3-4356-ae42-955acf623ee5@github.com>
Message-ID: <iUdB_ImfBV2JxBz_M9PFqycOk2LXwXkvzOrJO2STtGc=.8db77336-1517-4319-954d-fb0b24d9599e@github.com>

On Tue, 4 Mar 2025 23:13:02 GMT, Jeremy <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:
>> 
>>> 921:             int bufferedImageType = ((BufferedImage)image).getType();
>>> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>>> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {
>> 
>> So we'll no longer use a singleton IST for images with an ICM.
>> I don't know how much that matters though. They probably aren't heavyweight compared to the image writing.
>> The alternative - which I'll mention, which isn't the same as recommend - is to check if ColorModel.getTransparency() == OPAQUE before using the singleton, since we know that's the case it maps to.
>> 
>> The BYTE_INDEXED case code in getSpecifier(..) isn't dead code, because it is still used in
>> public static  ImageTypeSpecifier createFromBufferedImageType(int bufferedImageType)
>> In that case, there's not  enough information to do anything except "pick one", so it is caveat emptor for callers of  that API in such a case, and no need to do anything there.
>> 
>> I'll have to run this through our testing.
>
> Right.
> 
> If we value cached singletons: it'd be easy to break this up into 3 basic cached ImageTypeSpecifiers (one for each Transparency constant: OPAQUE, BITMASK, TRANSLUCENT). That would also satisfy the attached unit test and the original TwelveMonkeys complaint. I started with what I thought was the simplest proposal (in this PR), but I'm happy to explore other options if we want.

Unless someone has a performance-sensitive batch job encoding thousands of transparent GIFs, I don't see a problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980415741

From bpb at openjdk.org  Tue Mar  4 23:42:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 23:42:54 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v9]
In-Reply-To: <OJsb37ZnK8O4UKAcVwT00L6_gEhwtRj86rvciyEJH5U=.161bde5c-e093-4f6f-a3a7-4ec730e1d3ed@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <dVmRqLKkkbG99GV6bdHlL6Zi9SeR8knPq08edKlcO_A=.ccaa69b5-5437-42b3-8561-15a5ea1be519@github.com>
 <33Fmr1Ja6N2yaytsRpGO4Hen1bLL_qzQ2UBUzG2wpNg=.5fa56528-32fc-4520-9bf2-5722d8cd2cfa@github.com>
 <qOXegzWEmuwwW3BJbF9xl_1Huks2BtpdqZVFOhM1bA4=.40313a83-9891-484c-8f83-b82cd78932c7@github.com>
 <KIjs-wAg1ReHGjrYLf0GRa377BjMLUnNydLh6mIXawo=.19a82525-640d-41a5-a500-7dc20ac5cea1@github.com>
 <4YNnYdjMrSpXTPSjWYjAwqDlJr0tnE3WHvA-wViEH4g=.6128a6a0-3bba-45e0-b849-fb8bb3cdcf69@github.com>
 <OJsb37ZnK8O4UKAcVwT00L6_gEhwtRj86rvciyEJH5U=.161bde5c-e093-4f6f-a3a7-4ec730e1d3ed@github.com>
Message-ID: <dAM3MpYduH2qtw6KK-he3iB8RoE9cLyQe2RKgwXlbUU=.522380c8-5c66-4cfd-9383-a6cce613aada@github.com>

On Tue, 4 Mar 2025 22:48:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> > @mickleness please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8160327](https://bugs.openjdk.org/browse/JDK-8160327) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.
>>> 
>>> @mickleness Let me know if you have trouble filing a CSR in which case I will do it.
>> 
>> I created https://bugs.openjdk.org/browse/JDK-8351218 - @bplb please fill it in and I'll review it.
>> 
>> FWIW I don't think Jeremy has a JBS account .. so you'll have to do it.
>
>> I created https://bugs.openjdk.org/browse/JDK-8351218
> 
> I intended to do that this afternoon.
> 
>> @bplb please fill it in and I'll review it.
>> FWIW I don't think Jeremy has a JBS account .. so you'll have to do it.
> 
> Will do.

> I created https://bugs.openjdk.org/browse/JDK-8351218 - @bplb please fill it in and I'll review it.

@prrace Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2699262638

From prr at openjdk.org  Tue Mar  4 23:59:12 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Mar 2025 23:59:12 GMT
Subject: RFR: 8319192: Remove javax.swing.plaf.synth.SynthLookAndFeel.load(URL
 url)
Message-ID: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>

Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.

No open tests needed to be updated to accommodate this removal 
I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.

There will be a CSR (and probably a release note too).

-------------

Commit messages:
 - 8319192

Changes: https://git.openjdk.org/jdk/pull/23909/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319192
  Stats: 86 lines in 2 files changed: 0 ins; 79 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23909/head:pull/23909

PR: https://git.openjdk.org/jdk/pull/23909

From honkar at openjdk.org  Wed Mar  5 01:03:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 01:03:51 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
Message-ID: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>

Harfbuzz upgraded to v10.4.0

File changes -

**Newly added files**

libharfbuzz/OT/Var/VARC/VARC.hh
libharfbuzz/OT/Var/VARC/coord-setter.hh
libharfbuzz/hb-decycler.hh
libharfbuzz/hb-geometry.hh 
libharfbuzz/hb-ot-var-varc-table.hh 
libharfbuzz/hb-subset-instancer-iup.hh  
libharfbuzz/hb-subset-serialize.h


**Deleted**

libharfbuzz/OT/glyf/VarCompositeGlyph.hh
libharfbuzz/OT/glyf/coord-setter.hh


**Modified: 182 existing files modified**

To prevent build failures due to dangling pointer on linux it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

-------------

Commit messages:
 - md file updated
 - md file updated
 - md file updated to 10.4.0
 - v10.3.0 to v10.4.0 changes
 - whitespace fix
 - warning section updated in gmk
 - .md file changes
 - modified files
 - newly added files
 - deleted files

Changes: https://git.openjdk.org/jdk/pull/23910/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348597
  Stats: 18558 lines in 193 files changed: 10013 ins; 2990 del; 5555 mod
  Patch: https://git.openjdk.org/jdk/pull/23910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23910/head:pull/23910

PR: https://git.openjdk.org/jdk/pull/23910

From prr at openjdk.org  Wed Mar  5 01:21:08 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 01:21:08 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
Message-ID: <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>

> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
> 
> No open tests needed to be updated to accommodate this removal 
> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
> 
> There will be a CSR (and probably a release note too).

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8319192

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23909/files
  - new: https://git.openjdk.org/jdk/pull/23909/files/bd7549bf..6656254c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23909&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23909&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23909/head:pull/23909

PR: https://git.openjdk.org/jdk/pull/23909

From psadhukhan at openjdk.org  Wed Mar  5 03:13:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Mar 2025 03:13:32 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/a3475a91..38876068

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=16-17

  Stats: 26 lines in 3 files changed: 6 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Wed Mar  5 03:13:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Mar 2025 03:13:32 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v17]
In-Reply-To: <7aLt7Cn-eNFOP_sDDCnRuYldjUudkxfs3WQgMoFWtLI=.0188e5bd-89df-4236-baaa-610441246777@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <rJaQOc-KMZChDjXxcXYDktOnmrhV0u4Z-k2KI2xOyNc=.69c0c464-55f8-47b9-a2cf-34646045f873@github.com>
 <7aLt7Cn-eNFOP_sDDCnRuYldjUudkxfs3WQgMoFWtLI=.0188e5bd-89df-4236-baaa-610441246777@github.com>
Message-ID: <lqUlXeCtePuIl83vB9_8irk9M8lGJ5-eNlywsS2mFts=.0816cf66-9370-4ac5-b60b-759df202e967@github.com>

On Tue, 4 Mar 2025 18:08:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test rename
>
> test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 32:
> 
>> 30:  * @library /java/awt/regtesthelpers
>> 31:  * @build PassFailJFrame
>> 32:  * @run main/manual TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem
> 
> File name is different than the class name, jtreg test failed with `Error. can't find TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem in test directory or libraries`

Thanks..Renamed the file but forgot to update the classname..Updated..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1980614320

From psadhukhan at openjdk.org  Wed Mar  5 08:33:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Mar 2025 08:33:58 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
Message-ID: <7pp1gEHmQCq-VWurDn9t8YkMQhIO5FHROBLK04Fggi4=.3fcc4f35-4acc-4420-acf5-48bd41d5b208@github.com>

On Wed, 5 Mar 2025 01:21:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 249:

> 247:      */
> 248:     private URL getResource(String path) {
> 249:         return _classResourceBase.getResource(path);

Any particular reason for removing the null check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1980923857

From erikj at openjdk.org  Wed Mar  5 14:11:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Mar 2025 14:11:51 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <1Lkzsid1vE9sXmyoP-6_2FJN9RUkOJEKbrYdLVTHIAI=.b26c3b8d-13f7-45fe-b20b-00fac416b2ee@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

Build change looks ok.

The clang users on Linux may want to check if the same new warning triggers there.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23910#pullrequestreview-2661239964

From dgredler at openjdk.org  Wed Mar  5 14:21:53 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 5 Mar 2025 14:21:53 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands
In-Reply-To: <XGUCtWzlkT4_1G1AhhQfXLcRcK5c_lN0482w892EgN0=.197869a8-c653-41ad-b138-2df44dc6d05c@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
 <XGUCtWzlkT4_1G1AhhQfXLcRcK5c_lN0482w892EgN0=.197869a8-c653-41ad-b138-2df44dc6d05c@github.com>
Message-ID: <KFmNUXR73be_h_GsihfoW6We3kfrz5kP20-_LqPMEcs=.eedae7fa-7ff6-4acc-a37e-c1fe9d4b5495@github.com>

On Fri, 14 Feb 2025 20:41:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
>> 
>> Two methods are impacted:
>> 
>> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
>> 
>> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
>> 
>> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
>> 
>> A test case is included.
>
> The new test failed on Windows
> java.lang.RuntimeException: Expected 1 path, but found 0 paths
> 	at PostScriptLeanTest.main(PostScriptLeanTest.java:80)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)

@prrace This one is ready for a second review, if you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23595#issuecomment-2701082666

From dgredler at openjdk.org  Wed Mar  5 14:22:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 5 Mar 2025 14:22:54 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
Message-ID: <rYdDlwLumkMrc4ANTqoVuYn4_CXJlnYxvLa5DIUBtyQ=.225a9a1b-03b3-4676-9317-917a847a4962@github.com>

On Fri, 14 Feb 2025 00:04:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Early days but the test fails on macOS
> Exception in thread "main" java.lang.RuntimeException: nextOffset 1 for char 00ad using font Dialog: 2 != 1
> 	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:289)
> 	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:282)
> 	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:165)
> 	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:154)

@prrace This one is also ready for a second review, if you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2701084811

From azvegint at openjdk.org  Wed Mar  5 14:33:57 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 5 Mar 2025 14:33:57 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
Message-ID: <6z-8zV71nJz03gBc2ODuU3soireHUVI9v8i-OxoLITY=.15ae4770-79c1-4394-86c4-fb27f802848a@github.com>

On Wed, 5 Mar 2025 01:21:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

It is also mentioned in https://github.com/openjdk/jdk/blob/caaf4098452476d981183ad4302b76b9c883a72b/src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html#L57-L58

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23909#issuecomment-2701113896

From serb at openjdk.org  Wed Mar  5 16:55:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 5 Mar 2025 16:55:55 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v5]
In-Reply-To: <vxl3gJOdw2aGIMF3IGgx-Tc6KXARXsR0i0OYoxOpzf0=.a3866b2d-f55c-4d82-922b-ec70b73b4a29@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
 <gcx7ONrZbHWzpVXqjZwaa8Gc1zTYj-H0RtictQv_S3Y=.f708d7bd-5f4b-4408-a226-557b0baf2a4e@github.com>
 <Ta5ZMw5GGCxXzPrgBdTNSofBDZiFQb7J0owGLiW7f8M=.15fbd630-3af1-4319-8640-af97ec074ae7@github.com>
 <kDVyqhSkaiNJBElvHpqC1vkA3SrVLmXGM92pI9y3eHE=.7ef6b165-c084-4592-b4fc-7a6d10f900de@github.com>
 <vxl3gJOdw2aGIMF3IGgx-Tc6KXARXsR0i0OYoxOpzf0=.a3866b2d-f55c-4d82-922b-ec70b73b4a29@github.com>
Message-ID: <xQhMaeFy0N9ZHhYjmApqGzPVKI7P6SpBLUHOEwMafaQ=.6f48aeea-3b9e-43cc-9f21-58ef63ac60f7@github.com>

On Tue, 4 Mar 2025 21:19:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>If you also declare TestState.action as volatile...

TestState.action is marked as volatile below at the end of this diff.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20861#discussion_r1981808947

From duke at openjdk.org  Wed Mar  5 18:34:39 2025
From: duke at openjdk.org (Jeremy)
Date: Wed, 5 Mar 2025 18:34:39 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions
Message-ID: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>

JPEG segments can only be 65535-bytes long. (The marker length is expressed as 2 bytes.) The problem in this ticket is that we were writing more than 65535 bytes to a segment, which later caused parsing errors when we tried to read the file back.

This includes 2 changes:

1. We now clip the thumbnail width/height to fit within the available marker. We were already constraining the width & height to a max of 255. (Because the width & height are expressed as 1 byte.) So this new clipping is similar to something we were already doing, and we issue the same WARNING_THUMB_CLIPPED warning to the writer. (Does this require a CSR?)

2. This adds a bounds check to `write2bytes`. IMO the bigger problem in this ticket was the `ImageIO.write(..)` caller thought they ended up with a valid JPEG. (We were violating the "do no harm / lose no data" doctrine.) Now if something like this ever comes up again: writing will fail with an IIOException. Technically you can argue this change is unnecessary because the new clipping avoids this error condition, but IMO including this safety net is an overall good thing to keep. If anyone disagrees I'm OK with removing it.

Separately:
I included (and reversed) a commit in this branch that provides an alternate solution. That commit anticipates the overflow problem and switches to a JPEG-encoded thumbnail. From an end user perspective this "just works": they get a (slightly lossly) thumbnail of the original dimensions. But I assume it would be more controversial compared to the clipping approach, since the clipping approach has a strong precedent in this codebase.

-------------

Commit messages:
 - 8351110: write thumbnail using reduced thumbnail size
 - Revert "8351110: write thumbnail using JFIFThumbJPEG"
 - 8351110: write thumbnail using JFIFThumbJPEG
 - 8351110: avoid writing invalid JPEG segments
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c4b516df...3b39df55

Changes: https://git.openjdk.org/jdk/pull/23920/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351110
  Stats: 169 lines in 3 files changed: 167 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23920/head:pull/23920

PR: https://git.openjdk.org/jdk/pull/23920

From honkar at openjdk.org  Wed Mar  5 19:04:59 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 19:04:59 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

src/java.desktop/share/native/libharfbuzz/hb.hh line 134:

> 132: #pragma GCC diagnostic ignored "-Wcast-function-type-strict" // https://github.com/harfbuzz/harfbuzz/pull/3859#issuecomment-1295409126
> 133: #pragma GCC diagnostic ignored "-Wdangling-reference" // https://github.com/harfbuzz/harfbuzz/issues/4043
> 134: #pragma GCC diagnostic ignored "-Wdangling-pointer" // Trigerred by hb_decycler_node_t().

@prrace With the latest harfbuzz (v10.4.0), dangling-pointer warning is ignored. With this addition, I assumed that we no longer need to add it to harfbuzz warning section explicitly. 

But without adding dangling-pointer to `HARFBUZZ_DISABLED_WARNINGS_gcc` build fails on linux so probably JDK build requires warnings to be explicitly added to ClientLibraries.gmk ?


decycler.hh:110:25: error: storing the address of local variable ?decycler_node'
 in '((hb_decycler_t*)((char*)scratch + 8))[1].hb_decycler_t::tortoise' [-Werror=dangling-pointer=]
  110 |       decycler.tortoise = decycler.hare = this;
      |       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1982033388

From prr at openjdk.org  Wed Mar  5 19:52:07 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 19:52:07 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <7pp1gEHmQCq-VWurDn9t8YkMQhIO5FHROBLK04Fggi4=.3fcc4f35-4acc-4420-acf5-48bd41d5b208@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
 <7pp1gEHmQCq-VWurDn9t8YkMQhIO5FHROBLK04Fggi4=.3fcc4f35-4acc-4420-acf5-48bd41d5b208@github.com>
Message-ID: <ABJSnQ1YsnTvHp_-hLG_lVmvTP-HzLWzdIqcX1JK_cw=.133dcfa5-6ed6-4142-b0b3-386bdd942266@github.com>

On Wed, 5 Mar 2025 08:30:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8319192
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 249:
> 
>> 247:      */
>> 248:     private URL getResource(String path) {
>> 249:         return _classResourceBase.getResource(path);
> 
> Any particular reason for removing the null check?

Yes. the resource was *either* url-based or classpath based. One would be null, the other not.
Now there's only one, so it must be the non-null one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982094177

From honkar at openjdk.org  Wed Mar  5 19:54:20 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 19:54:20 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v12]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <SRdaF5zimK-a4xRs74cjljdNTiwPk12bc2R0ABtsgY8=.c2da2a22-f177-4043-9be1-42a888d9601d@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/b6fffacf..a5754754

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=10-11

  Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Wed Mar  5 20:00:18 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 20:00:18 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/a5754754..6e3b98ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Wed Mar  5 20:04:01 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 20:04:01 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
 <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
 <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>
Message-ID: <V2Y1WH5_BnqPsyGN67wBEOVHOqZ8_f39HAQTkgq6RO8=.d81c7a50-0909-4e06-93a1-f20d4f39c3f0@github.com>

On Tue, 4 Mar 2025 13:05:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This builtin flag check is exclusively for JDK built-in profiles created within the private interface `BuiltInProfile` and not applicable if an application loads the profile by serialization.
>> 
>> The built-in profiles can be serialized and deserialized, [see](https://github.com/openjdk/jdk/blob/c4b516dfe7c5a5fddd4d9c97a21f5f36bf845646/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1573). This means the application may get a reference to the profile not only via the getInstance(id) method. Therefore, the new spec is not strictly accurate regarding ICC_Profile.getInstance(int colorSpaceID), but I am not sure that we should mention serialisation here.
>> 
>> **Note:** 
>> The new Javadoc for the new private built-in flag is "public" via the serialized form of the class. It probably should be marked as transient, so it will only be set to true when the built-in profile is loaded via serialization. In all other cases, it will be false.
>
> This is an interesting observation.
> 
> Are the unserialized built-in profiles mapped to their corresponding singleton instances? I presume it's the case. Then, the `builtIn` flag will still be set to `true` in the returned object.
> 
> **Should the serialized form be preserved?**
> 
> If the `builtIn` field is `transient`, built-in profiles written by JDK 25 (mainline) could still be read in previous versions and vice versa. This will improve the backward compatibility.

Good point. I had not considered the effect of serialization on builtIn flag, let me check and get back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1982109310

From prr at openjdk.org  Wed Mar  5 20:18:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:18:55 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <47x-CN3ZcoOHt0rkLBnoWGqN5WgRqng0oHra1AL4Gpc=.1a9274b8-ad40-4958-88c9-f1df68d00fb0@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

src/java.desktop/share/native/libharfbuzz/UPDATING.txt line 56:

> 54: STEP 3: COMPILER WARNINGS AND SETTING FLAGS
> 55: -------------------------------------------
> 56: - Update make parameters in make/modules/java.desktop/lib/ClientLibraries.gmk

good catch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1980742878

From prr at openjdk.org  Wed Mar  5 20:18:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:18:56 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
 <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>
Message-ID: <C_jtsYDvOghWkIhfO1FLfje4Vcg4c7PAtc1eWISHz4Q=.ce9fdef6-b1b0-48a4-b054-01ee48a57f69@github.com>

On Wed, 5 Mar 2025 19:00:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harfbuzz upgraded to v10.4.0
>> 
>> File changes -
>> 
>> **Newly added files**
>> 
>> libharfbuzz/OT/Var/VARC/VARC.hh
>> libharfbuzz/OT/Var/VARC/coord-setter.hh
>> libharfbuzz/hb-decycler.hh
>> libharfbuzz/hb-geometry.hh 
>> libharfbuzz/hb-ot-var-varc-table.hh 
>> libharfbuzz/hb-subset-instancer-iup.hh  
>> libharfbuzz/hb-subset-serialize.h
>> 
>> 
>> **Deleted**
>> 
>> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
>> libharfbuzz/OT/glyf/coord-setter.hh
>> 
>> 
>> **Modified: 182 existing files modified**
>> 
>> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)
>
> src/java.desktop/share/native/libharfbuzz/hb.hh line 134:
> 
>> 132: #pragma GCC diagnostic ignored "-Wcast-function-type-strict" // https://github.com/harfbuzz/harfbuzz/pull/3859#issuecomment-1295409126
>> 133: #pragma GCC diagnostic ignored "-Wdangling-reference" // https://github.com/harfbuzz/harfbuzz/issues/4043
>> 134: #pragma GCC diagnostic ignored "-Wdangling-pointer" // Trigerred by hb_decycler_node_t().
> 
> @prrace With the latest harfbuzz (v10.4.0), dangling-pointer warning is ignored. With this addition, I assumed that we no longer need to add it to harfbuzz warning section explicitly. 
> 
> But without adding dangling-pointer to `HARFBUZZ_DISABLED_WARNINGS_gcc` build fails on linux so probably JDK build requires warnings to be explicitly added to ClientLibraries.gmk ?
> 
> 
> decycler.hh:110:25: error: storing the address of local variable ?decycler_node'
>  in '((hb_decycler_t*)((char*)scratch + 8))[1].hb_decycler_t::tortoise' [-Werror=dangling-pointer=]
>   110 |       decycler.tortoise = decycler.hare = this;
>       |       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

Interesting. I also would have expected this to over-ride the JDK default.
But if that's what you see ... 
A bit  of googling suggests that sometimes these pragmas are read too late.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1982127430

From prr at openjdk.org  Wed Mar  5 20:35:57 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:35:57 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <l7q5tu82tEipF6ZzRnEIv-XzSsMFmhqIsdVV5HJFBDo=.4ed768fb-9ca2-43f6-b520-0b41a94a5cc1@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

I had to use webrev to review. github was too painfully slow.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23910#pullrequestreview-2662424045

From prr at openjdk.org  Wed Mar  5 20:44:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:44:56 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <UIB5dlZ1y9toQkmycyoMUvW8ilzgacFSa3-B0SOnL2M=.33837b8a-f87a-4299-93dc-4d01272200c6@github.com>

On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy <duke at openjdk.org> wrote:

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

testing looks good.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2662440140

From prr at openjdk.org  Wed Mar  5 20:57:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:57:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
Message-ID: <DtkRoB2uSz5iZptH0CU0rFM5ljFmHvp74YCZWYLH3Bk=.c8b68b57-7b14-4c5a-800e-c2741c6ff28d@github.com>

On Wed, 5 Mar 2025 20:00:18 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 71:

> 69:             } catch (IllegalArgumentException iae) {
> 70:                 if (!iae.getMessage().equals(EXCEPTION_MSG)) {
> 71:                     throw new RuntimeException("Test Failed! IAE with exception msg \""

I don't think you need to - or should - expect a specific exception message.
Obviously you can update the test if the text changes, but I just don't think this is necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1982173349

From honkar at openjdk.org  Wed Mar  5 21:23:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 21:23:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
Message-ID: <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>

On Tue, 4 Mar 2025 12:44:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.
>> Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.
>> And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.
>
>> can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?
> 
> This has been [my suggestion](https://github.com/openjdk/jdk/pull/23606#discussion_r1968073992) since the start of this code review.
> 
>> The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.  
>> Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.
> 
> I agree, an exception should be thrown if modification isn't allowed.
> 
>> And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.
> 
> Therefore we can throw <code>Illegal<i>State</i>Exception</code> instead of <code>Illegal<i>Argument</i>Exception</code>.
> 
> Quoting here [Harshitha's reply](https://github.com/openjdk/jdk/pull/23606#discussion_r1968263836):
> 
>> As Phil mentioned earlier, the already documented exception IAE for .setData() outweighs introducing a new exception.
> 
> Using the exception which clearly describes the reason why it was thrown outweighs re-using an already documented exception?
> 
>> Using an existing exception would mean less disruption to any existing applications using the Java API.
> 
> ?especially because the search for usages of `setData` revealed that there are no usages of `setData` which will be affected by the proposed change.
> 
> If I'm not mistaken, the search also showed that no usages of `setData` handle `IllegalArgumentException`???thus apps will be equally unprepared to any type of an unchecked exception.

@aivanov-jdk @mrserb 
There are two other exceptions that may be better suited that ISE in this case - [UnsupportedOperationException ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) and [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) but the main motivation for going with IAE is that it is existing and documented exception.

> If I'm not mistaken, the search also showed that no usages of setData handle IllegalArgumentException???thus apps will be equally unprepared to any type of an unchecked exception.

Reasonable point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1982200255

From prr at openjdk.org  Wed Mar  5 21:23:58 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 21:23:58 GMT
Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and
 ShapeSINextSpan in libawt java2d from ubsan checks
In-Reply-To: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
References: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
Message-ID: <x5HZurIJienSUvYmYvWEjZ70MTCpjteXUsZFFG8L2hU=.e8bcf238-ec44-4b7f-923e-776ed868f6e4@github.com>

On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) 
> jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows
> 
> jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int'
>     #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683
>     #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499
>     #2 0x7efe9b8dee7b (<unknown module>)
> 
> java/awt/BasicStroke/DashStrokeTest.java shows
> 
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int'
>     #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366
>     #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75
>     #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92
>     #3 0x7fba12d07e7b (<unknown module>)
> 
> 
> There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings.

Marked as reviewed by prr (Reviewer).

I looked at the native code, and it seems to me that overflow is actually by design, when working with fractional pixel positions and color components.
So I think this points out that whilst ubsan findings might be an interesting data point, it isn't an automatic "go update the code".

The mechanism being used to silence the warnings might be palatable in very small quantities, but I sincerely hope it is not the start of a pattern. If it is, then something less intrusive to the source code would be better.
For example, something that is part of the build system. This would become a "must" if there's a 3rd party library involved.
Eg, when we find a compiler warning against 3rd party code, we just selectively disable the warning, and do not change the imported sources.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23255#pullrequestreview-2662521582
PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2702106349

From kizune at openjdk.org  Wed Mar  5 21:26:54 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 21:26:54 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v3]
In-Reply-To: <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
Message-ID: <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>

On Tue, 4 Mar 2025 03:57:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But this issue should be addressed?it's similar to a zip bomb, where small but valid source data can consume a huge amount of memory after processing.

Unlike zip bomb - which is a file that has a valid header but no valid data inside - this time the data is valid, and there are cases where very small amount of input data require a lot of resources to process it, this is exactly the case.

> To handle this, we should convert a fatal OutOfMemoryError into an IOException, which the application is likely already expecting.

No we should not. The OutOfMemoryError is an extension of VirtualMachineError which says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating." - which means that after issuing this kind of error the operation of virtual machine can not be guaranteed and "GC will clean up" might never happen. Additionally, the VirtualMachineError is an extension of Error which says "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." and by converting Error into a checked exception we are doing just that - we hide the underlying problem and making user application catch VM error as if nothing happened in the background. That is just wrong. We can handle it much better. For example i can add a threshold to check that the memory requirement does not exceed 90% of the available memory - that will take care of the overhead structures and buffers needed to proce
 ss the sound bank. But if program is made that it allows concurrent processing of the sound banks that will not help either because two threads will race to exhaust heap and one of them will ultimately eat up the last byte and we will still fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1982204434

From kizune at openjdk.org  Wed Mar  5 21:34:09 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 21:34:09 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
 - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23814/files
  - new: https://git.openjdk.org/jdk/pull/23814/files/e02c5863..ae6ac1c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23814&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23814/head:pull/23814

PR: https://git.openjdk.org/jdk/pull/23814

From prr at openjdk.org  Wed Mar  5 21:34:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 21:34:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <V2Y1WH5_BnqPsyGN67wBEOVHOqZ8_f39HAQTkgq6RO8=.d81c7a50-0909-4e06-93a1-f20d4f39c3f0@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
 <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
 <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>
 <V2Y1WH5_BnqPsyGN67wBEOVHOqZ8_f39HAQTkgq6RO8=.d81c7a50-0909-4e06-93a1-f20d4f39c3f0@github.com>
Message-ID: <hF9k5enYPMOLMRVUsOm9cF8teG5cxQLTQSoNFLcxs4A=.97674177-3306-44fc-b39e-43667bfea565@github.com>

On Wed, 5 Mar 2025 20:01:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This is an interesting observation.
>> 
>> Are the unserialized built-in profiles mapped to their corresponding singleton instances? I presume it's the case. Then, the `builtIn` flag will still be set to `true` in the returned object.
>> 
>> **Should the serialized form be preserved?**
>> 
>> If the `builtIn` field is `transient`, built-in profiles written by JDK 25 (mainline) could still be read in previous versions and vice versa. This will improve the backward compatibility.
>
> Good point. I had not considered the effect of serialization on builtIn flag, let me check and get back.

Yes, readObject(..) and readResolve(..) will return the singleton, as per the serialization spec ? https://docs.oracle.com/en/java/javase/21/docs/api/serialized-form.html#java.awt.color.ICC_Profile
but I agree we don't need to mention that here.

Yes, I agree builtIn should be transient, since we return the singleton as above, all will work as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1982214177

From prr at openjdk.org  Wed Mar  5 22:09:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 22:09:55 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v4]
In-Reply-To: <qugwMqvHOugdo_sGQldgcvi09SK0ZpEXyY_hXKpm9xI=.da5c93dd-878e-4aff-bd4e-2fa861175667@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <qugwMqvHOugdo_sGQldgcvi09SK0ZpEXyY_hXKpm9xI=.da5c93dd-878e-4aff-bd4e-2fa861175667@github.com>
Message-ID: <LEXFRSMjS0Nv4sxx_7hHKyvzksya6KyTzvYRsXcc5fc=.cc3054b4-a74b-4edb-bac5-ca817a2f62b4@github.com>

On Tue, 25 Feb 2025 14:55:41 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into print_options_idx_out_of_rng
>  - remove code duplication
>  - replace regexp s+ with space
>  - use array for option args
>  - Fix ArrayIndexOutOfBoundsException at PSPrinterJob printExecCmd

I notice that UnixPrintJob is even worse .. it would have the same problem except it doesn't even try to iterate over options, even though they can be specified !

I think it makes sense to fix that too.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1579:

> 1577:         if (options != null && !options.isEmpty()) {
> 1578:             optionArgs = options.trim().split(" ");
> 1579:             ncomps+=optionArgs.length;

I would have gone for the simpler one line fix of
ncomps+=options.trim().split(" ").length

test/jdk/javax/print/PrintExecCmdOptionTest.java line 59:

> 57:         MediaTray mediaTray = null;
> 58:         for (PrintService ps : printServices) {
> 59:             Media[] medias = (Media[]) ps.

It looks to me as if this loop needs to reset mediaTray = null.
Otherwise if printer 'N' has a mediaTray, printer 'N+1' will inherit it, even if it does not have one.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23457#pullrequestreview-2662591372
PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1982255789
PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1982242904

From serb at openjdk.org  Wed Mar  5 22:41:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 5 Mar 2025 22:41:07 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
Message-ID: <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>

On Wed, 5 Mar 2025 21:23:57 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> No we should not. The OutOfMemoryError is an extension of VirtualMachineError which says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating."

Then just check all usages of "catch (OutOfMemoryError e)" in the java.base and java.desktop/sound/2d/ modules. You did not mention the doc for OOM "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, **and no more memory could be made available by the garbage collector**."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1982286728

From prr at openjdk.org  Wed Mar  5 22:49:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 22:49:52 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <6z-8zV71nJz03gBc2ODuU3soireHUVI9v8i-OxoLITY=.15ae4770-79c1-4394-86c4-fb27f802848a@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
 <6z-8zV71nJz03gBc2ODuU3soireHUVI9v8i-OxoLITY=.15ae4770-79c1-4394-86c4-fb27f802848a@github.com>
Message-ID: <qkHWApxIys9KBBiRG3uUmXzqwNF4suAmXzdIG75axbI=.229a090d-385d-42dd-81a0-0a90c3acf1df@github.com>

On Wed, 5 Mar 2025 14:31:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> It is also mentioned in
> 
> https://github.com/openjdk/jdk/blob/caaf4098452476d981183ad4302b76b9c883a72b/src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html#L57-L58

Ah. I'd forgotten that. I had updated it back in JDK 21 but it slipped my mind this time round.

I'll remove the relevant text.
Hmm, is that *specific text* part of the spec needed for the CSR ? I didn't include it in the JDK 21 case, and it seems to be just examples, so I am going to say no.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23909#issuecomment-2702251627

From serb at openjdk.org  Wed Mar  5 22:51:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 5 Mar 2025 22:51:52 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
Message-ID: <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YOvFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>

On Wed, 5 Mar 2025 22:38:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> But this issue should be addressed?it's similar to a zip bomb, where small but valid source data can consume a huge amount of memory after processing.
>> 
>> Unlike zip bomb - which is a file that has a valid header but no valid data inside - this time the data is valid, and there are cases where very small amount of input data require a lot of resources to process it, this is exactly the case.
>> 
>>> To handle this, we should convert a fatal OutOfMemoryError into an IOException, which the application is likely already expecting.
>> 
>> No we should not. The OutOfMemoryError is an extension of VirtualMachineError which says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating." - which means that after issuing this kind of error the operation of virtual machine can not be guaranteed and "GC will clean up" might never happen. Additionally, the VirtualMachineError is an extension of Error which says "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." and by converting Error into a checked exception we are doing just that - we hide the underlying problem and making user application catch VM error as if nothing happened in the background. That is just wrong. We can handle it much better. For example i can add a threshold to check that the memory requirement does not exceed 90% of the available memory - that will take care of the overhead structures and buffers needed to pr
 ocess the sound bank. But if program is made that it allows concurrent processing of the sound banks that will not help either because two threads will race to exhaust heap and one of them will ultimately eat up the last byte and we will still fail.
>
>> No we should not. The OutOfMemoryError is an extension of VirtualMachineError which says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating."
> 
> Then just check all usages of "catch (OutOfMemoryError e)" in the java.base and java.desktop/sound/2d/ modules. You did not mention the doc for OOM "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, **and no more memory could be made available by the garbage collector**."

>Unlike zip bomb - which is a file that has a valid header but no valid data inside - this time the data is valid, and there are cases where very small amount of input data require a lot of resources to process it, this is exactly the case.

But is that really the case? In the test program, we have a MIDI file that we convert into an audio stream using the default sound bank from the JDK. Then, we try convert the audio stream back into a sound bank.

What should be expected from MidiSystem.getSoundbank(midiStream)? I assume it should return the sound bank [used ](https://github.com/openjdk/jdk/blob/11a37c829c12d064874416a7b242596cf23972e5/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java#L355) to render the MIDI file. And if no sound bank is found, the default one should be returned? Can we extract that w/o decoding?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1982295649

From azvegint at openjdk.org  Wed Mar  5 22:55:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 5 Mar 2025 22:55:53 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
Message-ID: <e8XYVHZ4_QG8zb78UYJlzKAyUjRQIh6BOmaYG_gSFJg=.0e613f8d-72f0-4fc0-8802-c8c159ad4a8f@github.com>

On Wed, 5 Mar 2025 01:21:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 223:

> 221:         }
> 222: 
> 223:         assert(classResourceBase != null);

It looks like this assert is no longer needed, because the `classResourceBase` is not null at this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982287358

From prr at openjdk.org  Wed Mar  5 23:07:06 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 23:07:06 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
Message-ID: <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>

> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
> 
> No open tests needed to be updated to accommodate this removal 
> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
> 
> There will be a CSR (and probably a release note too).

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8319192

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23909/files
  - new: https://git.openjdk.org/jdk/pull/23909/files/6656254c..f0b771b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23909&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23909&range=01-02

  Stats: 39 lines in 2 files changed: 0 ins; 35 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23909/head:pull/23909

PR: https://git.openjdk.org/jdk/pull/23909

From prr at openjdk.org  Wed Mar  5 23:07:07 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 23:07:07 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <qkHWApxIys9KBBiRG3uUmXzqwNF4suAmXzdIG75axbI=.229a090d-385d-42dd-81a0-0a90c3acf1df@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
 <6z-8zV71nJz03gBc2ODuU3soireHUVI9v8i-OxoLITY=.15ae4770-79c1-4394-86c4-fb27f802848a@github.com>
 <qkHWApxIys9KBBiRG3uUmXzqwNF4suAmXzdIG75axbI=.229a090d-385d-42dd-81a0-0a90c3acf1df@github.com>
Message-ID: <PtKHjakpDOdobbw3_G9LxgO8-EukTdTZTPLTlTMSwH4=.7fda2670-fd30-4052-9796-cd4dcbdc45f3@github.com>

On Wed, 5 Mar 2025 22:47:11 GMT, Phil Race <prr at openjdk.org> wrote:

> > It is also mentioned in
> > https://github.com/openjdk/jdk/blob/caaf4098452476d981183ad4302b76b9c883a72b/src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html#L57-L58
> 
> Ah. I'd forgotten that. I had updated it back in JDK 21 but it slipped my mind this time round.

fixed

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 223:
>> 
>>> 221:         }
>>> 222: 
>>> 223:         assert(classResourceBase != null);
>> 
>> It looks like this assert is no longer needed, because the `classResourceBase` is not null at this point.
>
> Fair enough. But I'm not sure it was ever needed. The condition in the existing code also ensured it would never fail.

fixed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23909#issuecomment-2702278386
PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982310621

From prr at openjdk.org  Wed Mar  5 23:07:07 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 23:07:07 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <e8XYVHZ4_QG8zb78UYJlzKAyUjRQIh6BOmaYG_gSFJg=.0e613f8d-72f0-4fc0-8802-c8c159ad4a8f@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
 <e8XYVHZ4_QG8zb78UYJlzKAyUjRQIh6BOmaYG_gSFJg=.0e613f8d-72f0-4fc0-8802-c8c159ad4a8f@github.com>
Message-ID: <RlEM7mFyyeRWbHAk9poHoaJ7yOQeumJM_KszUPTp9-E=.b12f7837-d6e2-46cc-902a-a0f853c1f98a@github.com>

On Wed, 5 Mar 2025 22:38:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8319192
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 223:
> 
>> 221:         }
>> 222: 
>> 223:         assert(classResourceBase != null);
> 
> It looks like this assert is no longer needed, because the `classResourceBase` is not null at this point.

Fair enough. But I'm not sure it was ever needed. The condition in the existing code also ensured it would never fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982309622

From azvegint at openjdk.org  Wed Mar  5 23:40:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 5 Mar 2025 23:40:53 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
Message-ID: <1RX8uDFOM10n2dEQdZO_nMQP9grwzq6xnCJMWMndsXs=.77b8144a-3053-49a3-bca3-59a90d2b34d6@github.com>

On Wed, 5 Mar 2025 23:07:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23909#pullrequestreview-2662736829

From azvegint at openjdk.org  Wed Mar  5 23:40:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 5 Mar 2025 23:40:54 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <PtKHjakpDOdobbw3_G9LxgO8-EukTdTZTPLTlTMSwH4=.7fda2670-fd30-4052-9796-cd4dcbdc45f3@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <YJDKoAA6NpLEdv7Y_m6wIya_GGx9yrMoEODxHcQsSPo=.c0c12b05-6dc8-454f-9542-1ce6282645e2@github.com>
 <6z-8zV71nJz03gBc2ODuU3soireHUVI9v8i-OxoLITY=.15ae4770-79c1-4394-86c4-fb27f802848a@github.com>
 <qkHWApxIys9KBBiRG3uUmXzqwNF4suAmXzdIG75axbI=.229a090d-385d-42dd-81a0-0a90c3acf1df@github.com>
 <PtKHjakpDOdobbw3_G9LxgO8-EukTdTZTPLTlTMSwH4=.7fda2670-fd30-4052-9796-cd4dcbdc45f3@github.com>
Message-ID: <SopxzLGB4GoEK7hQq7UgqR_XLP4f6OynhLw6QfJ0f-k=.90756fa6-c7ad-4f8b-a76e-f253458aef58@github.com>

On Wed, 5 Mar 2025 23:04:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Fair enough. But I'm not sure it was ever needed. The condition in the existing code also ensured it would never fail.
>
> fixed

> But I'm not sure it was ever needed.

It seems that this was a check that both `urlResourceBase` and `classResourceBase` are not null at the same time, but only when assertions are enabled.
Not sure why it was an assertion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982335843

From azvegint at openjdk.org  Wed Mar  5 23:47:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 5 Mar 2025 23:47:02 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <9xL7ZXwGcSCliRuqefu8yTRPjHx8lhV5XoheVmL6rdc=.41008432-be58-4669-a0ab-da531215ab5e@github.com>

On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2662742857

From prr at openjdk.org  Thu Mar  6 00:07:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 00:07:01 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands [v2]
In-Reply-To: <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
 <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
Message-ID: <fDss_uYap-Y8lyIWQXPaqWIGnK2LLwDLCwvKljZ9H0g=.79f55d3e-8082-4a6f-879a-f2a268e6d57e@github.com>

On Fri, 14 Feb 2025 23:51:49 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
>> 
>> Two methods are impacted:
>> 
>> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
>> 
>> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
>> 
>> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
>> 
>> A test case is included.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consider OS line separator when inspecting PostScript

>@prrace This one is ready for a second review, if you have time.

It has been on my list. Approved now.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23595#pullrequestreview-2662762370

From duke at openjdk.org  Thu Mar  6 00:07:01 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 00:07:01 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands [v2]
In-Reply-To: <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
 <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
Message-ID: <r-63s_BojuS7QEpAENizc_r28EZipJ7HJuFasvThn-c=.e0fa91f4-1911-423a-ac24-459ca4a0feb8@github.com>

On Fri, 14 Feb 2025 23:51:49 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
>> 
>> Two methods are impacted:
>> 
>> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
>> 
>> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
>> 
>> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
>> 
>> A test case is included.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consider OS line separator when inspecting PostScript

@gredler 
Your change (at version 0d8009d7fa20a60abb2c943a3f4833b0786f54fd) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23595#issuecomment-2702357781

From prr at openjdk.org  Thu Mar  6 00:12:55 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 00:12:55 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
Message-ID: <qpkXbDwA0fq6ZXUV5EWxZOvO2PaB494BvNHidwi4hH8=.c88f4136-43bf-4f17-a6b4-0b8e6cef1533@github.com>

On Fri, 14 Feb 2025 00:04:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Early days but the test fails on macOS
> Exception in thread "main" java.lang.RuntimeException: nextOffset 1 for char 00ad using font Dialog: 2 != 1
> 	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:289)
> 	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:282)
> 	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:165)
> 	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:154)

> @prrace This one is also ready for a second review, if you have time.

I need to look again at the changes, but I'm going to start by submitting a new build/test job for the latest version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2702366807

From serb at openjdk.org  Thu Mar  6 00:14:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 00:14:54 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
Message-ID: <DDihzSGwDeQ3A0j3HGcFqLxtV_53BlpNNWtXr4l6_Bk=.ecce5292-e9c7-4701-b051-2724b51bb546@github.com>

On Wed, 5 Mar 2025 23:07:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 38:

> 36: import java.io.InputStream;
> 37: import java.net.URL;
> 38: import java.net.URLClassLoader;

Is URLClassLoader no longer used?

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 216:

> 214:      * @param inputStream XML document containing the styles to read
> 215:      * @param factory DefaultSynthStyleFactory that new styles are added to
> 216:      * @param urlResourceBase the URL used to resolve any resources, such as Images

The description of this method includes information about the URL

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982362397
PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1982360613

From kizune at openjdk.org  Thu Mar  6 00:29:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 6 Mar 2025 00:29:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YOvFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
 <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YO
 vFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
Message-ID: <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>

On Wed, 5 Mar 2025 22:48:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> No we should not. The OutOfMemoryError is an extension of VirtualMachineError which says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating."
>> 
>> Then just check all usages of "catch (OutOfMemoryError e)" in the java.base and java.desktop/sound/2d/ modules. You did not mention the doc for OOM "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, **and no more memory could be made available by the garbage collector**."
>
>>Unlike zip bomb - which is a file that has a valid header but no valid data inside - this time the data is valid, and there are cases where very small amount of input data require a lot of resources to process it, this is exactly the case.
> 
> But is that really the case? In the test program, we have a MIDI file that we convert into an audio stream using the default sound bank from the JDK. Then, we try convert the audio stream back into a sound bank.
> 
> What should be expected from MidiSystem.getSoundbank(midiStream)? I assume it should return the sound bank [used ](https://github.com/openjdk/jdk/blob/11a37c829c12d064874416a7b242596cf23972e5/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java#L355) to render the MIDI file. And if no sound bank is found, the default one should be returned? Can we extract that w/o decoding?

> Then just check all usages of "catch (OutOfMemoryError e)" in the java.base and java.desktop/sound/2d/ modules. You did not mention the doc for OOM "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, **and no more memory could be made available by the garbage collector**."

And your point is? If someone made a bad choice in the past i do not think repeating it is beneficial.

> But is that really the case? In the test program, we have a MIDI file that we convert into an audio stream using the default sound bank from the JDK. Then, we try convert the audio stream back into a sound bank.

We do not "Convert back" to the sound bank - we construct new sound bank with a singular instrument that can produce  only one sound - the rendered MIDI that we just loaded. How user will use that sound bank is up to user - he can load this instrument into a new Synthesizer and play it as a background adding other parts on top of it. We do not know.

> And if no sound bank is found, the default one should be returned?

No - we have method for retrieving default sound bank. I am not sure what do you mean "no sound bank is found" - we are not looking for the sound bank inside the MIDI file, if we can render MIDI stream into an audio data we construct a sound bank with it, if we can't - we throw an exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1982375152

From serb at openjdk.org  Thu Mar  6 03:24:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 03:24:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
Message-ID: <AIFWC_wrsYuKV4LsDzv7-dIn1CwXu3LW56Oj7YEEfK4=.7adcb637-2b1e-4a53-8c8f-89d58b9f09bf@github.com>

On Wed, 5 Mar 2025 20:00:18 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 37:

> 35:             ColorSpace.CS_PYCC, ColorSpace.CS_GRAY,
> 36:             ColorSpace.CS_CIEXYZ
> 37:     };

With this modification, we will lose information about which color space is broken from the stack trace. So, at the least, you should print it in case of failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1982628417

From mbaesken at openjdk.org  Thu Mar  6 08:12:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Mar 2025 08:12:57 GMT
Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and
 ShapeSINextSpan in libawt java2d from ubsan checks
In-Reply-To: <x5HZurIJienSUvYmYvWEjZ70MTCpjteXUsZFFG8L2hU=.e8bcf238-ec44-4b7f-923e-776ed868f6e4@github.com>
References: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
 <x5HZurIJienSUvYmYvWEjZ70MTCpjteXUsZFFG8L2hU=.e8bcf238-ec44-4b7f-923e-776ed868f6e4@github.com>
Message-ID: <OcNvu80-CLf60wjPeAlzxJviHeZdIGrs8ibN1qPcAzc=.59256ed4-df63-4f54-99a6-1c763eafd9a4@github.com>

On Wed, 5 Mar 2025 21:21:14 GMT, Phil Race <prr at openjdk.org> wrote:

> So I think this points out that whilst ubsan findings might be an interesting data point, it isn't an automatic "go update the code".

I agree, the findings have to be checked and not always this leads to a source change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2703108860

From mbaesken at openjdk.org  Thu Mar  6 08:12:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Mar 2025 08:12:58 GMT
Subject: Integrated: 8330936: [ubsan] exclude function BilinearInterp and
 ShapeSINextSpan in libawt java2d from ubsan checks
In-Reply-To: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
References: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
Message-ID: <Wp0bWRKSWrtpP3LNMcs_rZ_PMp8jKY35sqHMcEtQNZo=.0869b47c-8af5-4a37-be88-c85261f073b1@github.com>

On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) 
> jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows
> 
> jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int'
>     #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683
>     #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499
>     #2 0x7efe9b8dee7b (<unknown module>)
> 
> java/awt/BasicStroke/DashStrokeTest.java shows
> 
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int'
>     #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366
>     #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75
>     #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92
>     #3 0x7fba12d07e7b (<unknown module>)
> 
> 
> There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings.

This pull request has now been integrated.

Changeset: 40f150d3
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40f150d3e50caf44fa4a31b79fbcd234142803ce
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks

Reviewed-by: clanger, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23255

From duke at openjdk.org  Thu Mar  6 10:45:04 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 10:45:04 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
Message-ID: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>

Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.

This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.

Sponsored by: The FreeBSD Foundation
Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>

[1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

-------------

Commit messages:
 - 8351322: Parameterize link option for pthreads

Changes: https://git.openjdk.org/jdk/pull/23930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351322
  Stats: 661 lines in 10 files changed: 9 ins; 0 del; 652 mod
  Patch: https://git.openjdk.org/jdk/pull/23930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23930/head:pull/23930

PR: https://git.openjdk.org/jdk/pull/23930

From dholmes at openjdk.org  Thu Mar  6 12:49:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 12:49:02 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

Needs build team approval before integrating.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664340896

From duke at openjdk.org  Thu Mar  6 13:29:55 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 13:29:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
Message-ID: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>

On Thu, 6 Mar 2025 12:46:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2703853406

From duke at openjdk.org  Thu Mar  6 13:55:53 2025
From: duke at openjdk.org (Antonio Vieiro)
Date: Thu, 6 Mar 2025 13:55:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/test/JtregNativeHotspot.gmk line 886:

> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
> 885: else
> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)

Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
Could be me too, I need new reading glasses...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983396617

From erikj at openjdk.org  Thu Mar  6 14:23:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Mar 2025 14:23:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?

make/autoconf/libraries.m4 line 142:

> 140:   # Threading library
> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"

If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.

Suggestion:

    BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

-------------

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664582520
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983435650

From ihse at openjdk.org  Thu Mar  6 15:51:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:51:52 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>

On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?

This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

Yes, this is incorrect. Remember that m4 are shell scripts so you need to use shell syntax here. (I know it is confusing).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2704233217
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983608153

From ihse at openjdk.org  Thu Mar  6 15:58:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <oXeR7653mNNaWgQUd8T_KiQM8R987ZCjfuWAWNAoLLU=.a1980e25-ad0d-4da6-9bb2-92c13e790b28@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

You're absolutely right. 

@snake66 Making changes to makefiles is tricky, since a misspelled variable do not get any warning but is just silently ignored. 

For a change like this, that is a pure refactoring that is not supposed to change the output, I highly recommend using the `COMPARE_BUILD` system. Unfortunately, this is severely underdocumented. There is a short paragraph at https://openjdk.org/groups/build/doc/building.html under "Developing the Build System Itself", but in short, what I'd do is to create a diff files of these changes compared to a baseline (e.g. master, a specific build or commit), make sure you have the baseline checked out, and then run `make jdk-image test-image COMPARE_BUILD=PATCH=my_patch.diff`. This will build the targets twice, one without the patch and one with the patch, and then automatically run the `compare` script to analyze any differences. For this particular patch, there should be none. This would likely have caught this typo. (Given that the test-image is actually compared; I suddenly got a bit uncertain about that...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983618250

From ihse at openjdk.org  Thu Mar  6 15:58:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/Hsdis.gmk line 131:

> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
> 131:   else

The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983621784

From duke at openjdk.org  Thu Mar  6 17:21:01 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:21:01 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <1xDhCbB5y6lKeTsljSaXQIctUdhLeZYMZc3ttv3CCAY=.e32e38b6-8431-4fa9-9b49-8fb305a744aa@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

@vieiro Thanks! That's well spotted, I'll fix!

@magicus Thanks for this info! I'll give it a try without fixing the typo first, to see if it would catch it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983764371

From duke at openjdk.org  Thu Mar  6 17:31:53 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
Message-ID: <vLspqp3iNAf1V1PXvKB4844a1K71STekYMCWeTLLqv8=.ed29364e-71fa-4ca6-83a3-48435263cd3d@github.com>

On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/Hsdis.gmk line 131:
> 
>> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
>> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
>> 131:   else
> 
> The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

Ack, I'll drop that one from the patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983780437

From duke at openjdk.org  Thu Mar  6 17:31:54 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>

On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

@erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983779126

From ihse at openjdk.org  Thu Mar  6 18:24:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:24:05 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
Message-ID: <8oD1j-gxmzv2_5BOV5GohhkiKcuTDqxAC-3mnF8i-3o=.f2d870af-a508-4b53-95ac-d886fdc21b09@github.com>

On Thu, 6 Mar 2025 17:28:10 GMT, snake66 <duke at openjdk.org> wrote:

>> make/autoconf/libraries.m4 line 142:
>> 
>>> 140:   # Threading library
>>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>> 
>> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
>> 
>> Suggestion:
>> 
>>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"
>
> @erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

I'm not sure what you mean now. The link is to this very patch, which does what you describe -- sets LIBPTHREAD according to OS and stores it in spec.gmk.

And no, the paranthesis should not stay. If you keep them, the variable will be re-evaluated in make every time BASIC_JVM_LIBS is evaluated. That is not needed; by dropping the parenthesis the actual value to be used will be inserted as a string constant. Which is what we want, since we know the value at configure time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983853576

From prr at openjdk.org  Thu Mar  6 19:02:18 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 19:02:18 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
Message-ID: <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>

On Wed, 5 Mar 2025 03:13:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

There is a lot to absorb here. I don't want to get into line by line code discussion, we need to have the big picture right first.

(1) This affects all releases, right ? The evaluation in the bug report is non-existent.
I expect to see a full description of how it came about (history) what the consequences are,
what the options are etc. Without that the PR is in a vacuum.

(2) My rough understanding is that this was "observed" because of a change in Windows 11 vs earlier Windows versions
with the highlighting of the radio button .. but the fix has some how become focused on the ImageIcon ?
If I don't have this right, give me a clear and complete explanation of the issue (ie part of the missing evaluation)

Surely that isn't a Windows 10 vs Windows 11 issue ?? Unless it is an accidental by-product of some layout problem ?
I am seeing code in the pre-fix side of the diff that does paint an icon .. so I am not sure I understand.
If the same control in native windows doesn't allow such an icon, then we are within our rights to ignore it.
There are a bunch of settings, such as b/g color etc that various L&Fs ignore if they aren't appropriate.
Search the javax.swing javadoc for the word "ignore" and you'll find hundreds of matches.

I can't actually tell from the PR description what the inentention is
"Added provision of drawing the radiobutton windows Skin even when imageIcon is present."

Does that mean it continues to ignore the imageicon - ie not render it ? But as I wrote there is something that looks to be painting an icon. Maybe we are talking about the "icon" that is actually the rendering of the radio button - not an application supplied imageicon ?
I'd like 100% clarity here.

(3) Any fix requiring a CSR would be a problem - at least if it is SE spec significant, because it seems like this fix needs to be backported all the way to 8u. If there is a *better* fix that requires a CSR for the future, we can do that as a follow-on for JDK 25 only, but we should start with what can be backported, and do the better fix as a follow-on.

I'll deviate  slightly from my "I won't get in to lines for code here", and say that FWIW the current fix isn't what I'd like to see.
Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??

(4) We are not any time soon de-supporting Windows 10.
Windows 10 is still supported by Microsoft the day JDK 25 ships, even for regular users.
We need to make this work  properly on both Windows 10 and Windows 11.
NB in both cases, there are unsupported older updates and still supported updates .. like 22H2 for Windows 10 is the one to check. If this means the code needs to work out if it is on Windows 11 vs 10, so be it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2704698129

From aivanov at openjdk.org  Thu Mar  6 19:32:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Mar 2025 19:32:00 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
Message-ID: <1GxzeFO2w9I4jvk2N7FT3Q_H0jj2gWLtH2pDYLq9mAE=.cd774004-fe55-4b41-bb5f-64582013df04@github.com>

On Wed, 5 Mar 2025 03:13:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

I can quickly answer to this part:

> Surely that isn't a Windows 10 vs Windows 11 issue ?? Unless it is an accidental by-product of some layout problem ?

It is a Windows 10 vs Windows 11 issue.

Currently, an `ImageIcon` associated with a radio- or check menu item is painted instead of the bullet or check-mark. The selected state of the corresponding menu item is still apparent since the background of the icon is darker.

![Windows-10-menu-items-no-fix-2025-02-06](https://github.com/user-attachments/assets/684c9461-e47e-46de-a609-7bd9724099cb)

This is a screenshot from [the discussion above](https://github.com/openjdk/jdk/pull/23324#issuecomment-2640591767). Here the purplish background around icon indicates the selected state.

In Windows 11, there's no way to distinguish whether a radio- or check menu item is selected or not because the selection background is gone in Windows 11 style.

Prasanta found a menu in Windows File Explorer, the **View** button on the toolbar, which displays both the radio bullet and an icon to the left of menu text.

![A highlighted menu item Windows-11-highlighted-menu-item-in-Explorer](https://github.com/user-attachments/assets/0f7de244-58f4-42c5-b8da-2461ce04b1d0)

No one has found a similar usage in Windows 10. Other apps, Oracle VirtualBox and Paint.NET, which draw icons in menu items add a small check-mark to the icon to indicate the menu item is selected.

As far as I'm aware Win32 menus don't allow displaying both an icon and a bullet or check-mark; apps have to custom-draw such menu items.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2704755835

From achung at openjdk.org  Thu Mar  6 20:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 6 Mar 2025 20:11:15 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>

> upgrading third party library to newest version

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23784/files
  - new: https://git.openjdk.org/jdk/pull/23784/files/6531cfaf..c021e977

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23784&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23784&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23784/head:pull/23784

PR: https://git.openjdk.org/jdk/pull/23784

From serb at openjdk.org  Thu Mar  6 20:13:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 20:13:57 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
 <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YO
 vFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
 <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>
Message-ID: <5xSDhfirAFhWrkywEnGD20qpEI4Nqz45tgWvLoCIiWw=.2842c7e0-0b14-4423-9f4a-84fbc8a24599@github.com>

On Thu, 6 Mar 2025 00:27:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>And your point is? If someone made a bad choice in the past i do not think repeating it is beneficial.

That is not a bad choice; this is how it should be implemented. Most, if not all, of those code paths are security-related. You can consult with the authors and reviewers of those patches to clarify why it was implemented that way.

>We do not "Convert back" to the sound bank - we construct new sound bank with a singular instrument that can produce only one sound - the rendered MIDI that we just loaded. How user will use that sound bank is up to user - he can load this instrument into a new Synthesizer and play it as a background adding other parts on top of it. We do not know.

But that new soundbank instrument is just a MIDI file rendered using the default soundbank. Do we really need to render it? Wouldn't it be possible to simply store the MIDI events and the soundbank and use them when the user selects the instrument?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1983988914

From prr at openjdk.org  Thu Mar  6 20:14:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 20:14:59 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
Message-ID: <6rd7XABkYTNxJmthwoJUWLJk-6LWJpElsqL6gQhkyKE=.91a92f8b-c7ab-4674-a702-40d344481d5e@github.com>

On Thu, 6 Mar 2025 20:11:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2665513936

From serb at openjdk.org  Thu Mar  6 20:19:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 20:19:54 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
Message-ID: <AcXqSAHS1dZLKb5Nm-7M5jfqjDol-FehwuYIily48ls=.cba7d687-d85e-4139-bd6b-2302cbf8b44b@github.com>

On Thu, 6 Mar 2025 20:11:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Changes:

- Add fuzzers foundation. Many thanks to Amir Montazery and Open-Source Technology Improvement Fund (ostif.org), Google, for funding that.
- Add ability to disable building tests in meson
- Fixed gamut warning not working on certain conditions
- Mac sequoia added to test beds
- Add the possibility of duplicating a NULL context for cloning defaults.
- Small cleanup of CGATS parser.
- Change computation of profile ID to follow actual ICC spec (yes, they changed the spec!)
- Allow to apply color management on memory blocks > 4Gb.
- Get rid of samples on meson compilation
- Increase coverage of pre-multiplied alpha.
- Bug fixing and cosmetical work.

I guess the most interesting changes for us are related to pre-multiplied alpha. And it would be good to check what "Change computation of profile ID" means.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23784#issuecomment-2704850309

From serb at openjdk.org  Thu Mar  6 20:22:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 20:22:59 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <hF9k5enYPMOLMRVUsOm9cF8teG5cxQLTQSoNFLcxs4A=.97674177-3306-44fc-b39e-43667bfea565@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
 <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
 <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>
 <V2Y1WH5_BnqPsyGN67wBEOVHOqZ8_f39HAQTkgq6RO8=.d81c7a50-0909-4e06-93a1-f20d4f39c3f0@github.com>
 <hF9k5enYPMOLMRVUsOm9cF8teG5cxQLTQSoNFLcxs4A=.97674177-3306-44fc-b39e-43667bfea565@github.com>
Message-ID: <9vbGkBRR9Zo9jy41Gh5uSuNtPSAQQNevg1MHHB-7-Eg=.72ec2f7e-903c-4f6b-ac8a-06b231e737ce@github.com>

On Wed, 5 Mar 2025 21:32:39 GMT, Phil Race <prr at openjdk.org> wrote:

>Yes, readObject(..) and readResolve(..) will return the singleton

We do not specify anywhere in the API that we use singletons; that is an implementation detail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1983998902

From honkar at openjdk.org  Thu Mar  6 20:23:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Mar 2025 20:23:00 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
Message-ID: <c2fzBy3edSepZDtHFd5BMIEjLvzk1ep8iUu022BGPfk=.8974429e-b709-447f-9d29-a1bbbf8d22ae@github.com>

On Thu, 6 Mar 2025 20:11:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by honkar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2665532269

From serb at openjdk.org  Thu Mar  6 20:32:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Mar 2025 20:32:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
Message-ID: <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>

On Wed, 5 Mar 2025 21:20:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> can we just ignore it instead and did not use suspicion IllegalArgumentException for correct parameters? or change the type to something unrelated to "..ArgumentException"?
>> 
>> This has been [my suggestion](https://github.com/openjdk/jdk/pull/23606#discussion_r1968073992) since the start of this code review.
>> 
>>> The silently do nothing option was considered, but if you do that, then you have no easy way of knowing if it worked.  
>>> Tests may pass spuriously, or fail later for the wrong reasons. So a worse choice.
>> 
>> I agree, an exception should be thrown if modification isn't allowed.
>> 
>>> And in all my searching of uses of this API it is (1) tests in the JDK itself and (2) a couple of libraries that are targeting specific known profiles with issues and are fixed up - so never applied to built-in profiles.
>> 
>> Therefore we can throw <code>Illegal<i>State</i>Exception</code> instead of <code>Illegal<i>Argument</i>Exception</code>.
>> 
>> Quoting here [Harshitha's reply](https://github.com/openjdk/jdk/pull/23606#discussion_r1968263836):
>> 
>>> As Phil mentioned earlier, the already documented exception IAE for .setData() outweighs introducing a new exception.
>> 
>> Using the exception which clearly describes the reason why it was thrown outweighs re-using an already documented exception?
>> 
>>> Using an existing exception would mean less disruption to any existing applications using the Java API.
>> 
>> ?especially because the search for usages of `setData` revealed that there are no usages of `setData` which will be affected by the proposed change.
>> 
>> If I'm not mistaken, the search also showed that no usages of `setData` handle `IllegalArgumentException`???thus apps will be equally unprepared to any type of an unchecked exception.
>
> @aivanov-jdk @mrserb 
> There are two other exceptions that may be better suited that ISE in this case - [UnsupportedOperationException ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) and [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) but still IAE was chosen oven them as it is existing and documented exception.
> 
>> If I'm not mistaken, the search also showed that no usages of setData handle IllegalArgumentException???thus apps will be equally unprepared to any type of an unchecked exception.
> 
> Reasonable point.

I'm just not sure how this should be handled from the application's point of view. The app may obtain a profile from some place and use it for some images or pixels. Then, if the app wants to tweak the rendering intent for some reason, what should it do?

 - Clone the profile and then change the intent?
 - Change the intent, and if an exception occurs, clone the profile and try to change the intent again?
 - Skip changing the intent completely?

I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps. It wasn?t considered very important since the "appcontext was withdrawn". So, why are we deciding to change it now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1984010199

From prr at openjdk.org  Thu Mar  6 20:55:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 20:55:00 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <DDihzSGwDeQ3A0j3HGcFqLxtV_53BlpNNWtXr4l6_Bk=.ecce5292-e9c7-4701-b051-2724b51bb546@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
 <DDihzSGwDeQ3A0j3HGcFqLxtV_53BlpNNWtXr4l6_Bk=.ecce5292-e9c7-4701-b051-2724b51bb546@github.com>
Message-ID: <8BQ1rrmkKI7ka2ZgLQNDHeTLHyg-uPQsxTIupgRIVm8=.89ad2936-b9c4-4874-9de4-8407b89452ac@github.com>

On Thu, 6 Mar 2025 00:11:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8319192
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 38:
> 
>> 36: import java.io.InputStream;
>> 37: import java.net.URL;
>> 38: import java.net.URLClassLoader;
> 
> Is URLClassLoader no longer used?

seems so. I'll remove it.

> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 216:
> 
>> 214:      * @param inputStream XML document containing the styles to read
>> 215:      * @param factory DefaultSynthStyleFactory that new styles are added to
>> 216:      * @param urlResourceBase the URL used to resolve any resources, such as Images
> 
> The description of this method includes information about the URL

The whole sentence is now unnecessary and can be deleted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1984016598
PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1984033190

From dnguyen at openjdk.org  Thu Mar  6 21:04:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 6 Mar 2025 21:04:54 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
Message-ID: <gDxVc6FXFsIaZxnQZcD2So5DTxepQxgIsxtFL49c4cM=.b5d07447-cb01-402a-86f7-1de11fd6da84@github.com>

On Thu, 6 Mar 2025 20:11:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by dnguyen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2665620198

From prr at openjdk.org  Thu Mar  6 21:26:07 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 21:26:07 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
Message-ID: <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>

On Thu, 6 Mar 2025 20:30:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I'm just not sure how this should be handled from the application's point of view. The app may obtain a profile from some place and use it for some images or pixels. Then, if the app wants to tweak the rendering intent for some reason, what should it do?
> 
> * Clone the profile and then change the intent?
> * Change the intent, and if an exception occurs, clone the profile and try to change the intent again?
> * Skip changing the intent completely?

If an app got a profile 'from some place', it probably should not be trying to change it, and likely has no idea if some isolated change will work properly, or the effect on what handed it that profile.
So copying the data and creating a new profile is what I'd recommend in such a case, regardless of this proposed restriction, and even then, only on a 'known' profile. 

> I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps. It wasn?t considered very important since the "appcontext was withdrawn". So, why are we deciding to change it now?

I don't see such a discussion there. Maybe it was 'offline' ?
Yes, this is less of an issue in a closed application, but it is an inappropriate thing to do/allow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1984070656

From achung at openjdk.org  Thu Mar  6 21:27:59 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 6 Mar 2025 21:27:59 GMT
Subject: Integrated: 8348110: Update LCMS to 2.17
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <eUfCPe5tuUsUoESPyHFusYe5ugZi02QpVvFgJqgzxeU=.28c53c91-07f9-4eff-a4b9-b1c9202fe0c0@github.com>

On Tue, 25 Feb 2025 20:00:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

> upgrading third party library to newest version

This pull request has now been integrated.

Changeset: a23fb0af
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a23fb0af65f491ef655ba114fcc8032a09a55213
Stats:     471 lines in 30 files changed: 295 ins; 20 del; 156 mod

8348110: Update LCMS to 2.17

Reviewed-by: honkar, prr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/23784

From prr at openjdk.org  Thu Mar  6 21:42:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 21:42:01 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v3]
In-Reply-To: <AcXqSAHS1dZLKb5Nm-7M5jfqjDol-FehwuYIily48ls=.cba7d687-d85e-4139-bd6b-2302cbf8b44b@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <vxdzkt60xR6Oo_f3ItB-O1Ib9kYcmJfv57gDl9L96bg=.4f155d6d-108c-44db-8b8c-d253d6dd27a5@github.com>
 <AcXqSAHS1dZLKb5Nm-7M5jfqjDol-FehwuYIily48ls=.cba7d687-d85e-4139-bd6b-2302cbf8b44b@github.com>
Message-ID: <Oo9q8ywtJ-fdlCp8sypJCoNTRXMjRG5Ri6QTfVZcaGs=.6be359ed-d040-497d-9401-6cb57dc2af9f@github.com>

On Thu, 6 Mar 2025 20:17:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> I guess the most interesting changes for us are related to pre-multiplied alpha. And it would be good to check what "Change computation of profile ID" means.

I think neither is a big deal.

The first sounds to be about test coverage, in which case it isn't even part of what we use.
But I don't see anything obvious, although I also see an alpha related bug fix .. which should just be good to have.

 the second only for when it generates a profile, and even then isn't important to anything we might care about :
The change is the requirement to set header flags to zero instead of attributes when computing the MD5 digest.
https://github.com/mm2/Little-CMS/commit/736a76259cfea9cd65db2c7ffefc625463db8f9e

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23784#issuecomment-2705001622

From prr at openjdk.org  Thu Mar  6 22:31:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 22:31:59 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <C5cxMhQA1lFgbgeN_-sEuKXLdpzxZhpGlo5DXeu0rXA=.c70b0ef3-fb17-4529-aa5a-7dcf223bdab5@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I am seeing an existing test fail on macOS with this change
java/awt/font/GlyphVector/NLGlyphTest.java

java NLGlyphTest 
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
	at java.desktop/sun.font.StandardGlyphVector.getGlyphCode(StandardGlyphVector.java:311)
	at NLGlyphTest.main(NLGlyphTest.java:46)

I don't know why, but it seems like this 
          char[] chs = { '\n' };
          GlyphVector lgv = font.layoutGlyphVector(frc, chs, 0, 1, 0);
results in a GV with zero glyphs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2705084008

From prr at openjdk.org  Thu Mar  6 22:34:58 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 22:34:58 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <X3iMI3qoS0lXiMU_VPnV7wJOiCFsvy5-tuW0mT4Xq94=.451712f8-d11c-4b1d-a093-dadfacee6691@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I just deleted a comment added to the wrong PR!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2705089899

From prr at openjdk.org  Thu Mar  6 22:37:56 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 22:37:56 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <PyC3RMoU9Lg-wXyJQpzYpQpb-E7qb81JwVryq8dxJYY=.e09dfc19-ad1c-45d9-9af7-14d063bcda27@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

I am seeing an existing test fail on macOS with this change
java/awt/font/GlyphVector/NLGlyphTest.java

java NLGlyphTest
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at java.desktop/sun.font.StandardGlyphVector.getGlyphCode(StandardGlyphVector.java:311)
at NLGlyphTest.main(NLGlyphTest.java:46)

This code
char[] chs = { '\n' };
GlyphVector lgv = font.layoutGlyphVector(frc, chs, 0, 1, 0);
results in a GV with zero glyphs, which isn't what I'd expect - that a string would have no glyphs at all.
Interestingly I think it is OK for some fonts, but not OK for most fonts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2705094639

From prr at openjdk.org  Thu Mar  6 22:44:04 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Mar 2025 22:44:04 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
Message-ID: <4AXo_I1IEKnxm3Qe-tSGiuUWFvn_3W7BbGM1_tCsoyk=.a0055ace-616b-455f-8175-febc0c25fcc0@github.com>

On Fri, 27 Dec 2024 11:05:30 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> This update allows users to print with grayscale using color printers.
>> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)).
>> 
>> **Fix description**
>> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D.
>> 
>> This approach is assumed to be platform, CUPS, and IPP protocol independent.
>> 
>> **Tests**
>> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1.
>
> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Update copyright, fix typos, move the proxy to the macos
>  - Merge branch 'master' into monochrome-printing
>  - proxy mac only
>  - Revert "grammar fixes"
>    
>    This reverts commit 355b2b8f1dbc71cef433e9a925dfb8a7fff56f99.
>  - Revert "formatting"
>    
>    This reverts commit fde514baeadc2775fa502a2a2d312c6038880e7a.
>  - Revert "update copyright"
>    
>    This reverts commit 60e9b4f024544cfac4ddaddc1ea3653bd4a2fe4c.
>  - Revert "move grayscale methods to PSPathGraphics"
>    
>    This reverts commit 1ef135680645ad2647c4430e852095dda8aa7e0c.
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>    
>    # Conflicts:
>    #	src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>  - move grayscale methods to PSPathGraphics
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6c591854...5486473b

I will get back to this very soon. I hope !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21930#issuecomment-2705102266

From duke at openjdk.org  Thu Mar  6 23:42:38 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Thu, 6 Mar 2025 23:42:38 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v3]
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <A2cIYJQCd2itNrrjBtSqSuNsVHuHSaHv2FxqYaVH7ZA=.985f0bc6-d000-42e3-a5e1-2067ef965aa4@github.com>

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

Karm Michal Babacek has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Mac and Windows use different code path
 - Relaxes output.shouldContain to "isHeadless"
 - Removes HeadlessMalfunctionTest from ProblemList.txt
 - HeadlessMalfunctionTest from objectweb.asm to classfile api

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23852/files
  - new: https://git.openjdk.org/jdk/pull/23852/files/c6be9f4d..47c009d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=01-02

  Stats: 19264 lines in 503 files changed: 7872 ins; 8710 del; 2682 mod
  Patch: https://git.openjdk.org/jdk/pull/23852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23852/head:pull/23852

PR: https://git.openjdk.org/jdk/pull/23852

From dholmes at openjdk.org  Fri Mar  7 00:20:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 00:20:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
Message-ID: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?
>
>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
> 
> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

@magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2705227213

From serb at openjdk.org  Fri Mar  7 01:34:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Mar 2025 01:34:00 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
Message-ID: <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>

On Thu, 6 Mar 2025 21:23:26 GMT, Phil Race <prr at openjdk.org> wrote:

>If an app got a profile 'from some place', it probably should not be trying to change it,

But this is not always possible. For example, a buffered image has a color model that references a color space and a color profile. To modify something in that profile(like intents screen vs printer) before converting the entire image, it is necessary to check whether it is a built-in profile. If it is, the whole image must be recreated; otherwise, an exception will occur. Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).

>I don't see such a discussion there. Maybe it was 'offline' ?

It was somewhere online not too long ago.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1984271026

From serb at openjdk.org  Fri Mar  7 01:41:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Mar 2025 01:41:05 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
Message-ID: <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>

On Fri, 7 Mar 2025 01:30:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).

But it also has its own disadvantages...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1984275377

From serb at openjdk.org  Fri Mar  7 01:56:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Mar 2025 01:56:41 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v6]
In-Reply-To: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
Message-ID: <cGJ_3zFNv48gHCfkt08dqdnH11JkiAYDgFzXjuzfHMY=.39f91906-37ce-471f-aba6-5855b05f5938@github.com>

> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
> 
> Notes:
>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
> 
> @azvegint @aivanov-jdk please take a look.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  drop null check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20861/files
  - new: https://git.openjdk.org/jdk/pull/20861/files/c37b252a..ec688da0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20861&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20861&range=04-05

  Stats: 20 lines in 4 files changed: 0 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20861/head:pull/20861

PR: https://git.openjdk.org/jdk/pull/20861

From psadhukhan at openjdk.org  Fri Mar  7 03:01:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Mar 2025 03:01:59 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
Message-ID: <BLPqkLyweTI1f-Hrpe2PexVc1ekXliISlZ5hxAEGRUw=.e28b416d-c8d0-4864-8f9b-e1b13f7f57b4@github.com>

On Wed, 5 Mar 2025 03:13:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

(1) I will add the evaluation in the JBS
(2) Yes, as pointed out already this is a Windows 10 vs Windows 11 issue...WIndows 10 imageicon is drawn on top of bullet/checkmark whereas in Windows 11 it is drawn alongside and I have fixed Windows 11 to look like FileExplorer->View 

![410771901-7d636add-f336-4db3-96cd-d8fe06737b3a](https://github.com/user-attachments/assets/32ab1845-696d-49eb-b73c-af7441e5b78f)

> Putting a check for Windows L&F in a BasicUI class ??  Isn't there a Windows L&F sub-class we can do this in ??

(3) The only way we could do that in Windows L&F class would require a CSR and it is done in this [commit](https://openjdk.github.io/cr/?repo=jdk&pr=23324&range=14) but I reverted back because of CSR requirement

(4) The current fix ensures Windows 10 will continue to work and also fixes Windows 11

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2705406453

From tr at openjdk.org  Fri Mar  7 05:25:03 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 7 Mar 2025 05:25:03 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions
In-Reply-To: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
References: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
Message-ID: <IPjqbbsMnqQq74bcBMkL2WliXCWyK0ZTvB7QTqelC3g=.dd9cb734-1f75-4be9-b0a8-d9b2991b79ee@github.com>

On Wed, 5 Mar 2025 18:29:49 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> JPEG segments can only be 65535-bytes long. (The marker length is expressed as 2 bytes.) The problem in this ticket is that we were writing more than 65535 bytes to a segment, which later caused parsing errors when we tried to read the file back.
> 
> This includes 2 changes:
> 
> 1. We now clip the thumbnail width/height to fit within the available marker. We were already constraining the width & height to a max of 255. (Because the width & height are expressed as 1 byte.) So this new clipping is similar to something we were already doing, and we issue the same WARNING_THUMB_CLIPPED warning to the writer. (Does this require a CSR?)
> 
> 2. This adds a bounds check to `write2bytes`. IMO the bigger problem in this ticket was the `ImageIO.write(..)` caller thought they ended up with a valid JPEG. (We were violating the "do no harm / lose no data" doctrine.) Now if something like this ever comes up again: writing will fail with an IIOException. Technically you can argue this change is unnecessary because the new clipping avoids this error condition, but IMO including this safety net is an overall good thing to keep. If anyone disagrees I'm OK with removing it.
> 
> Separately:
> I included (and reversed) a commit in this branch that provides an alternate solution. That commit anticipates the overflow problem and switches to a JPEG-encoded thumbnail. From an end user perspective this "just works": they get a (slightly lossly) thumbnail of the original dimensions. But I assume it would be more controversial compared to the clipping approach, since the clipping approach has a strong precedent in this codebase.

test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 2:

> 1: /*
> 2:  * Copyright (c) 20025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 38:

> 36: import javax.imageio.stream.ImageInputStream;
> 37: import javax.imageio.stream.ImageOutputStream;
> 38: import java.awt.*;

Please expand the wildcard imports.

test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 41:

> 39: import java.awt.geom.AffineTransform;
> 40: import java.awt.image.BufferedImage;
> 41: import java.io.*;

Please expand the wildcard imports.

test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 155:

> 153:         return null;
> 154:     }
> 155: }

Empty line at last is missing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984465597
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984466151
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984466228
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984466870

From duke at openjdk.org  Fri Mar  7 06:41:36 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 7 Mar 2025 06:41:36 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions [v2]
In-Reply-To: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
References: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
Message-ID: <jsjWCYXCbQR9Vr6PB8HEDEEjykU4b4PFtq9vkge0A2U=.1fce3563-0aa0-488f-8db3-6dee143591a9@github.com>

> JPEG segments can only be 65535-bytes long. (The marker length is expressed as 2 bytes.) The problem in this ticket is that we were writing more than 65535 bytes to a segment, which later caused parsing errors when we tried to read the file back.
> 
> This includes 2 changes:
> 
> 1. We now clip the thumbnail width/height to fit within the available marker. We were already constraining the width & height to a max of 255. (Because the width & height are expressed as 1 byte.) So this new clipping is similar to something we were already doing, and we issue the same WARNING_THUMB_CLIPPED warning to the writer. (Does this require a CSR?)
> 
> 2. This adds a bounds check to `write2bytes`. IMO the bigger problem in this ticket was the `ImageIO.write(..)` caller thought they ended up with a valid JPEG. (We were violating the "do no harm / lose no data" doctrine.) Now if something like this ever comes up again: writing will fail with an IIOException. Technically you can argue this change is unnecessary because the new clipping avoids this error condition, but IMO including this safety net is an overall good thing to keep. If anyone disagrees I'm OK with removing it.
> 
> Separately:
> I included (and reversed) a commit in this branch that provides an alternate solution. That commit anticipates the overflow problem and switches to a JPEG-encoded thumbnail. From an end user perspective this "just works": they get a (slightly lossly) thumbnail of the original dimensions. But I assume it would be more controversial compared to the clipping approach, since the clipping approach has a strong precedent in this codebase.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8351110: code cleanup
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/23920#discussion_r1984465597
  https://github.com/openjdk/jdk/pull/23920#discussion_r1984466151
  https://github.com/openjdk/jdk/pull/23920#discussion_r1984466228
  https://github.com/openjdk/jdk/pull/23920#discussion_r1984466870
  
  This also updates the test summary, removes an unused method, and fixes a trivial compiler warning.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23920/files
  - new: https://git.openjdk.org/jdk/pull/23920/files/3b39df55..4d6afb6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=00-01

  Stats: 19 lines in 1 file changed: 5 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23920/head:pull/23920

PR: https://git.openjdk.org/jdk/pull/23920

From duke at openjdk.org  Fri Mar  7 06:41:36 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 7 Mar 2025 06:41:36 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions [v2]
In-Reply-To: <IPjqbbsMnqQq74bcBMkL2WliXCWyK0ZTvB7QTqelC3g=.dd9cb734-1f75-4be9-b0a8-d9b2991b79ee@github.com>
References: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
 <IPjqbbsMnqQq74bcBMkL2WliXCWyK0ZTvB7QTqelC3g=.dd9cb734-1f75-4be9-b0a8-d9b2991b79ee@github.com>
Message-ID: <Wy9blBv-2npUbxQZJ3El1lvdfPK6iBB7m0Hr73GM8G0=.cb5355f9-f653-4ba8-baa6-b484750152f0@github.com>

On Fri, 7 Mar 2025 05:19:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8351110: code cleanup
>>   
>>   This is in response to:
>>   https://github.com/openjdk/jdk/pull/23920#discussion_r1984465597
>>   https://github.com/openjdk/jdk/pull/23920#discussion_r1984466151
>>   https://github.com/openjdk/jdk/pull/23920#discussion_r1984466228
>>   https://github.com/openjdk/jdk/pull/23920#discussion_r1984466870
>>   
>>   This also updates the test summary, removes an unused method, and fixes a trivial compiler warning.
>
> test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 20025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Thanks, this is fixed.

> test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 38:
> 
>> 36: import javax.imageio.stream.ImageInputStream;
>> 37: import javax.imageio.stream.ImageOutputStream;
>> 38: import java.awt.*;
> 
> Please expand the wildcard imports.

This is updated

> test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 41:
> 
>> 39: import java.awt.geom.AffineTransform;
>> 40: import java.awt.image.BufferedImage;
>> 41: import java.io.*;
> 
> Please expand the wildcard imports.

This is updated

> test/jdk/javax/imageio/plugins/jpeg/WriteJPEGThumbnailTest line 155:
> 
>> 153:         return null;
>> 154:     }
>> 155: }
> 
> Empty line at last is missing.

This is updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984532278
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984532353
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984532757
PR Review Comment: https://git.openjdk.org/jdk/pull/23920#discussion_r1984532444

From duke at openjdk.org  Fri Mar  7 06:48:08 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 7 Mar 2025 06:48:08 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions [v3]
In-Reply-To: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
References: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
Message-ID: <yx2hUU7hcy6Ggrkhuio9REGZ3D-4AKgz5eCL_igP9fo=.36f2f265-6748-40c4-8b70-aaaeb3161ab4@github.com>

> JPEG segments can only be 65535-bytes long. (The marker length is expressed as 2 bytes.) The problem in this ticket is that we were writing more than 65535 bytes to a segment, which later caused parsing errors when we tried to read the file back.
> 
> This includes 2 changes:
> 
> 1. We now clip the thumbnail width/height to fit within the available marker. We were already constraining the width & height to a max of 255. (Because the width & height are expressed as 1 byte.) So this new clipping is similar to something we were already doing, and we issue the same WARNING_THUMB_CLIPPED warning to the writer. (Does this require a CSR?)
> 
> 2. This adds a bounds check to `write2bytes`. IMO the bigger problem in this ticket was the `ImageIO.write(..)` caller thought they ended up with a valid JPEG. (We were violating the "do no harm / lose no data" doctrine.) Now if something like this ever comes up again: writing will fail with an IIOException. Technically you can argue this change is unnecessary because the new clipping avoids this error condition, but IMO including this safety net is an overall good thing to keep. If anyone disagrees I'm OK with removing it.
> 
> Separately:
> I included (and reversed) a commit in this branch that provides an alternate solution. That commit anticipates the overflow problem and switches to a JPEG-encoded thumbnail. From an end user perspective this "just works": they get a (slightly lossly) thumbnail of the original dimensions. But I assume it would be more controversial compared to the clipping approach, since the clipping approach has a strong precedent in this codebase.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8351110: fixing test filename so jtreg sees it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23920/files
  - new: https://git.openjdk.org/jdk/pull/23920/files/4d6afb6b..5448bb2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=01-02

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23920/head:pull/23920

PR: https://git.openjdk.org/jdk/pull/23920

From duke at openjdk.org  Fri Mar  7 08:16:52 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Fri, 7 Mar 2025 08:16:52 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v3]
In-Reply-To: <A2cIYJQCd2itNrrjBtSqSuNsVHuHSaHv2FxqYaVH7ZA=.985f0bc6-d000-42e3-a5e1-2067ef965aa4@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <A2cIYJQCd2itNrrjBtSqSuNsVHuHSaHv2FxqYaVH7ZA=.985f0bc6-d000-42e3-a5e1-2067ef965aa4@github.com>
Message-ID: <VI5r2sn20S-SJMDlc0rG7cHdDHhyvfyeYHdavBf1qcA=.44a6944f-e3be-4951-84b5-608bf74283f3@github.com>

On Thu, 6 Mar 2025 23:42:38 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Mac and Windows use different code path
>  - Relaxes output.shouldContain to "isHeadless"
>  - Removes HeadlessMalfunctionTest from ProblemList.txt
>  - HeadlessMalfunctionTest from objectweb.asm to classfile api

I am running the Windows, Mac and Linux CI now, will post links to test results when it completes...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2705802711

From ihse at openjdk.org  Fri Mar  7 11:34:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:34:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <ZF1daFkBTlQ8lrEMRD3alDurQiOp02Q-5YYJ822f0GE=.24d747ef-9efe-497f-b792-58850aff5467@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

@dholmes-ora Good question. I don't know the answer. I know we used `-pthread` exclusively on Solaris, and that we've used `-lpthread` on Linux (but apparently not in all cases?). I guess this difference would not have been introduced when the Linux port was created from the Solaris port unless it made sense. So maybe at that time, GCC did not support `-pthread`. Otoh, that might have changed by now.

Regardless, I would still like to see this change. We have generalized almost all system libraries to variable (like `$LIBM`, `$LIBDL` etc), and this is the last remaining (I think).

We can then check if we can turn `-lpthread` into `-pthread` on Linux as a follow up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2706220845

From duke at openjdk.org  Fri Mar  7 12:38:08 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Fri, 7 Mar 2025 12:38:08 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:

  Fixed @library /test -> @library /test/lib

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23852/files
  - new: https://git.openjdk.org/jdk/pull/23852/files/47c009d0..f3294bd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23852/head:pull/23852

PR: https://git.openjdk.org/jdk/pull/23852

From aivanov at openjdk.org  Fri Mar  7 13:27:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Mar 2025 13:27:56 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
Message-ID: <qixKQ4nS6PPdYKPtDVeCSMmoSCwPrW3JSztikxBT3HA=.3bedc9b1-1dc5-4a67-84e3-ec463c5be958@github.com>

On Wed, 5 Mar 2025 03:13:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Comparing side by side:

| Windows 10 | Windows 11 |
|---------------|---------------|
| ![A menu rendered by Swing in Windows 10: the first menu item has purplish background around the red square to indicate it's selected; the third menu item has purplish background around the cyan square to indicate it's selected; the fourth menu item renders the default check-mark which also has purple background; the fifth menu item renders a green square as its icon; all the icons are aligned.](https://github.com/user-attachments/assets/684c9461-e47e-46de-a609-7bd9724099cb) |  ![The same menu rendered by Swing in Windows 11: there are no purplish background around icons so it's impossible to tell if a menu item with custom icon is selected or not, it's true for the first (radio) menu item and the third (check) menu item; the fourth menu item displays the default check-mark to indicate selection, there's no special background around the check-mark.](https://github.com/user-attachments/assets/6db3905c-1682-42b4-99cb-8edd7f58a2ba) |

This is how Swing currently renders the same menu in Windows 10 and 11.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2706450223

From psadhukhan at openjdk.org  Fri Mar  7 17:06:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Mar 2025 17:06:11 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v19]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <lg27jFM-1ZeU_WLbfxORyquNHglu5vaDt59yf7QFWVA=.90e67540-8dbf-4c2b-8e2d-1003a1a926b8@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove Windows L&F check from BasicMenuItemUI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/38876068..00daa8fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=17-18

  Stats: 295 lines in 5 files changed: 274 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Fri Mar  7 17:10:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Mar 2025 17:10:55 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
Message-ID: <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>

On Thu, 6 Mar 2025 18:59:23 GMT, Phil Race <prr at openjdk.org> wrote:

> FWIW the current fix isn't what I'd like to see.
> Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??

Since the Windows L&F check in Basic*UI class is a bone of contention, I have removed it and put the code in Windows specific class although there's around 200+ lines of code duplication as most of the required helper methods in BasicMenuItemUI class has private access..
CI run in windows is ok..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2706975903

From dgredler at openjdk.org  Fri Mar  7 17:55:57 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 7 Mar 2025 17:55:57 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <-IFgqZGdhpi1OQ9NlMMc-eibNY6gfodIUBBq5UQSz4o=.7ff0d46d-11bb-4fb5-a5c5-26b47a33952b@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

OK, it looks like we've got a constant conflict between Java's `INVISIBLE_GLYPH_ID` and HarfBuzz's `AAT::DELETED_GLYPH`, both of which are `0xFFFF`. This conflict only really matters when using an AAT font with a `morx` table, at which point `hb_ot_substitute_post` calls `hb_aat_layout_remove_deleted_glyphs`, which mis-identifies our invisible glyph as a deleted glyph which needs to be removed from the buffer.

I'm not sure where to take it from here. Java has been using `0xFFFF` for quite some time to indicate invisible glyphs, so a change to the Java constant seems dangerous. There might be some wiggle room to use `0xFFFE`, since the comments in `CharToGlyphMapper` seem to indicate that it should also be treated as an invisible glyph? The glyph removal in HarfBuzz is wrapped by an `#ifndef HB_NO_AAT_SHAPE`, so I supposed we could disable AAT shaping in HarfBuzz, but that also seems drastic.

Suggestions welcome!

https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java#L45

https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-ot-shape.cc#L961

https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-aat-layout-common.hh#L458

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2707061961

From prr at openjdk.org  Fri Mar  7 17:57:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 17:57:57 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <40wz_zCdylbE_C2_QZIVt21ha-Wce8DomAlbak8FN9I=.5fead66c-0121-4df1-a690-7f7dae264a62@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

I ran your tests, and now windows and mac pass, but Linux now fails 
test result: Error. can't find jdk.test.lib.helpers.ClassFileInstaller in test directory or libraries

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2707064640

From aivanov at openjdk.org  Fri Mar  7 17:59:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Mar 2025 17:59:56 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>
Message-ID: <wV_NxwKTx6OjwmcxAtIcUFp1rDgBaw3jr-Vu85MdO_s=.aaafe7f7-05c8-417b-b161-475fcbb490f6@github.com>

On Fri, 7 Mar 2025 17:08:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > FWIW the current fix isn't what I'd like to see.
> > Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??
> 
> Since the Windows L&F check in Basic*UI class is a bone of contention, I have removed it and put the code in Windows specific class although there's around 200+ lines of code duplication as most of the required helper methods in BasicMenuItemUI class has private access.. CI run in windows is ok..

Can we move these helper methods into a utility class which has public access to both `Basic*UI` and `Windows*UI`? `SwingUtilities3`, or a new class?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2707067002

From prr at openjdk.org  Fri Mar  7 18:08:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 18:08:52 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <40wz_zCdylbE_C2_QZIVt21ha-Wce8DomAlbak8FN9I=.5fead66c-0121-4df1-a690-7f7dae264a62@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
 <40wz_zCdylbE_C2_QZIVt21ha-Wce8DomAlbak8FN9I=.5fead66c-0121-4df1-a690-7f7dae264a62@github.com>
Message-ID: <N03SoK0DKFzDpnzYg8l1YgvPMqDwhY8uPfjEHQwd6aI=.d6eeeab6-e107-4fb4-bd57-a4aad4e40818@github.com>

On Fri, 7 Mar 2025 17:55:22 GMT, Phil Race <prr at openjdk.org> wrote:

> I ran your tests, and now windows and mac pass, but Linux now fails test result: Error. can't find jdk.test.lib.helpers.ClassFileInstaller in test directory or libraries

Oh. I see you just updated to fix this a few hours ago. I'll re-run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2707078957

From duke at openjdk.org  Fri Mar  7 18:08:52 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Fri, 7 Mar 2025 18:08:52 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <N03SoK0DKFzDpnzYg8l1YgvPMqDwhY8uPfjEHQwd6aI=.d6eeeab6-e107-4fb4-bd57-a4aad4e40818@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
 <40wz_zCdylbE_C2_QZIVt21ha-Wce8DomAlbak8FN9I=.5fead66c-0121-4df1-a690-7f7dae264a62@github.com>
 <N03SoK0DKFzDpnzYg8l1YgvPMqDwhY8uPfjEHQwd6aI=.d6eeeab6-e107-4fb4-bd57-a4aad4e40818@github.com>
Message-ID: <fOwLe16S4lTWLnDTSb_Y_qyFMv4L-gDe8AdZ_rZVLYE=.e79bd6e7-2fc6-457f-aaac-35e17268d41d@github.com>

On Fri, 7 Mar 2025 18:03:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> I ran your tests, and now windows and mac pass, but Linux now fails 
>> test result: Error. can't find jdk.test.lib.helpers.ClassFileInstaller in test directory or libraries
>
>> I ran your tests, and now windows and mac pass, but Linux now fails test result: Error. can't find jdk.test.lib.helpers.ClassFileInstaller in test directory or libraries
> 
> Oh. I see you just updated to fix this a few hours ago. I'll re-run.

@prrace @jerboaa 

Given the different code path MacOS and Windows take to initialize the affected isHeadless part, I propose *excluding* Windows and MacOS from the test.

Mere relaxing the test, parsing only for "isHeadless" string in the error message, makes little sense, because such test passes both on Windows and MacOS **regardless** of the JDK-8336382 https://github.com/openjdk/jdk/pull/20169 patch.

The current state of the PR passes `test/jdk/java/awt/Headless` dir on these platforms:

* :green_circle: Windows amd64, 14 PASS 1 SKIPPED (this one)  [REPORT](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=w2k19/artifact/jdk/jtreg_results/jdk/JTreport/html/index.html), [LOGS](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=w2k19/consoleText)
* :green_circle: MacOS aarch64: 14 PASS 1 SKIPPED (this one) [REPORT](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=macos_aarch64/artifact/jdk/jtreg_results/jdk/JTreport/html/index.html), [LOGS](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=macos_aarch64/consoleText)
* :green_circle: Linux amd64: 15 PASS [REPORT](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=el8/artifact/jdk/jtreg_results/jdk/JTreport/html/index.html), [LOGS](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=el8/consoleText)
* :green_circle: Linux aarch64: 15 PASS [REPORT](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=el8_aarch64/artifact/jdk/jtreg_results/jdk/JTreport/html/index.html), [LOGS](https://ci.modcluster.io/job/mandrel-jdk-build-matrix/19/LABEL=el8_aarch64/consoleText)

@prrace I will keep using this CI I established for my future client libs contributions, to aviod platform surprises...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2707082359

From prr at openjdk.org  Fri Mar  7 18:13:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 18:13:53 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <-IFgqZGdhpi1OQ9NlMMc-eibNY6gfodIUBBq5UQSz4o=.7ff0d46d-11bb-4fb5-a5c5-26b47a33952b@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <-IFgqZGdhpi1OQ9NlMMc-eibNY6gfodIUBBq5UQSz4o=.7ff0d46d-11bb-4fb5-a5c5-26b47a33952b@github.com>
Message-ID: <nRWDdYIYIrkbrVr-DUz1htcI_92aLgdQdiGhwdziSko=.0f29c3cc-96a3-4001-9513-afca250d2034@github.com>

On Fri, 7 Mar 2025 17:53:45 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> OK, it looks like we've got a constant conflict between Java's `INVISIBLE_GLYPH_ID` and HarfBuzz's `AAT::DELETED_GLYPH`, both of which are `0xFFFF`. This conflict only really matters when using an AAT font with a `morx` table, at which point `hb_ot_substitute_post` calls `hb_aat_layout_remove_deleted_glyphs`, which mis-identifies our invisible glyph as a deleted glyph which needs to be removed from the buffer.
> 
> I'm not sure where to take it from here. Java has been using `0xFFFF` for quite some time to indicate invisible glyphs, so a change to the Java constant seems dangerous. There might be some wiggle room to use `0xFFFE`, since the comments in `CharToGlyphMapper` seem to indicate that it should also be treated as an invisible glyph? The glyph removal in HarfBuzz is wrapped by an `#ifndef HB_NO_AAT_SHAPE`, so I supposed we could disable AAT shaping in HarfBuzz, but that also seems drastic.
> 
> Suggestions welcome!
> 
> https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java#L45
> 
> https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-ot-shape.cc#L961
> 
> https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-aat-layout-common.hh#L458

That's unfortunate.
0xFFFF for invisible glyph has been in JDK for 25 years. It is probably baked into a lot of stuff. I would not want to change that unless forced to. 
We also don't want HB to delegate AAT to CoreText .. I think we had problems in that area before HB supported it itself.
So I'm not sure where to take it from here either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2707092441

From prr at openjdk.org  Fri Mar  7 18:29:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 18:29:52 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <5r2ZN_rrF_poSiafYQpSpKYdefqEaw_tlEgA5qyWLK4=.f78c14bc-c1c0-4ecc-9a86-2ced42fb5cb7@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

Looking across the code base, there are a number of places which look explicitly for 0xFFFF (INVISIBLE_GLYPH_ID) and somewhat fewer that look for >= 0xFFFE (INVISIBLE_GLYPHS) That's an interesting inconsistency in itself.
Also looking for 0xffff literals across the codebase is unsurprisingly tedious .. 

The idea of 0xFFFE might be worth a shot but it maybe that we need to make a bunch of changes to code that looks just for  INVISIBLE_GLYPH_ID, including in some tests, but it also might be that since this is macOS specific that it could be less risky - although since the result could still be used by shared code it isn't quite as constrained as you might hope.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2707121017

From prr at openjdk.org  Fri Mar  7 18:41:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 18:41:55 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <8Hg0wc2ny2lnEn4O2SYX0MYb5SiVAdB7O-Nh-zUxKNU=.c956d499-5caa-467f-a250-401943efae92@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

Excluding on windows and mac should be OK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2707159311

From serb at openjdk.org  Fri Mar  7 18:46:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Mar 2025 18:46:57 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
Message-ID: <uWnRHyruexX0fjOe5a6VsM89KtdJJeZiLAvHXBW2DK0=.98d4bf90-a3a9-4686-877d-34f163321dd1@github.com>

On Fri, 28 Feb 2025 10:09:30 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments 2

Looks good to me. Please summarize the use cases we discussed(in the description of this PR? or jbs) and how they are currently handled. It would be useful to document this since we don?t have a strict specification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2707169036

From prr at openjdk.org  Fri Mar  7 20:35:01 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 20:35:01 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <3tTo3fNuGSkJcGKD6A0G5S9K3-UEDT6vLe07nFj0EQc=.4a0caab8-939b-420b-9d05-50fb64e3de29@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

I'll hold off re-running the tests until you have updated the PR with the exclusions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2707389621

From duke at openjdk.org  Fri Mar  7 21:09:54 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Fri, 7 Mar 2025 21:09:54 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <yVS0ULCpKezELuM52xNNBlPmurYFTLFGW0Q5jBw_4VU=.6daf55e9-1f82-4e80-991b-a865ddf70a30@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

test/jdk/java/awt/Headless/HeadlessMalfunctionTest.java line 36:

> 34:  * @summary Test that in absence of isHeadless method, the JDK throws a meaningful error message.
> 35:  * @library /test/lib
> 36:  * @requires os.family == "linux"

@prrace 

> I'll hold off re-running the tests until you have updated the PR with the exclusions.

Doesn't this bit do the exclusion? I found out about it looking at other tests...

My Windows says:

Test results: passed: 14; did not meet platform requirements: 1
Report written to C:\workspace\workspace\mandrel-jdk-build-matrix\LABEL\w2k19\jdk\jtreg_results\jdk\JTreport\html\report.html
Results written to C:\workspace\workspace\mandrel-jdk-build-matrix\LABEL\w2k19\jdk\jtreg_results\jdk\JTwork


and MacOS also:

Test results: passed: 14; did not meet platform requirements: 1
Report written to /Users/tester/jenkins/workspace/mandrel-jdk-build-matrix/LABEL/macos_aarch64/jdk/jtreg_results/jdk/JTreport/html/report.html
Results written to /Users/tester/jenkins/workspace/mandrel-jdk-build-matrix/LABEL/macos_aarch64/jdk/jtreg_results/jdk/JTwork

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23852#discussion_r1985712083

From prr at openjdk.org  Fri Mar  7 21:17:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 21:17:53 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <yVS0ULCpKezELuM52xNNBlPmurYFTLFGW0Q5jBw_4VU=.6daf55e9-1f82-4e80-991b-a865ddf70a30@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
 <yVS0ULCpKezELuM52xNNBlPmurYFTLFGW0Q5jBw_4VU=.6daf55e9-1f82-4e80-991b-a865ddf70a30@github.com>
Message-ID: <ShvW1OC-X8SzYsyQq1wydwZhUn1bXdB5hcMD7pdIm4g=.775c616e-7d95-4f3f-8cb6-f82b445c9ba2@github.com>

On Fri, 7 Mar 2025 21:07:01 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed @library /test -> @library /test/lib
>
> test/jdk/java/awt/Headless/HeadlessMalfunctionTest.java line 36:
> 
>> 34:  * @summary Test that in absence of isHeadless method, the JDK throws a meaningful error message.
>> 35:  * @library /test/lib
>> 36:  * @requires os.family == "linux"
> 
> @prrace 
> 
>> I'll hold off re-running the tests until you have updated the PR with the exclusions.
> 
> Doesn't this bit do the exclusion? I found out about it looking at other tests...
> 
> My Windows says:
> 
> Test results: passed: 14; did not meet platform requirements: 1
> Report written to C:\workspace\workspace\mandrel-jdk-build-matrix\LABEL\w2k19\jdk\jtreg_results\jdk\JTreport\html\report.html
> Results written to C:\workspace\workspace\mandrel-jdk-build-matrix\LABEL\w2k19\jdk\jtreg_results\jdk\JTwork
> 
> 
> and MacOS also:
> 
> Test results: passed: 14; did not meet platform requirements: 1
> Report written to /Users/tester/jenkins/workspace/mandrel-jdk-build-matrix/LABEL/macos_aarch64/jdk/jtreg_results/jdk/JTreport/html/report.html
> Results written to /Users/tester/jenkins/workspace/mandrel-jdk-build-matrix/LABEL/macos_aarch64/jdk/jtreg_results/jdk/JTwork

yes it does, I thought you had not done that yet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23852#discussion_r1985719778

From dgredler at openjdk.org  Fri Mar  7 21:47:51 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 7 Mar 2025 21:47:51 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <ov1GvHgO4ZfebDk3NCj3g-4L5EDVMj-NzjMTAllLOLc=.560bbadc-eb73-4e6e-96c7-ad54dbb15577@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

I'm checking with the HarfBuzz guys to see if there's a possible fix on their end: https://github.com/harfbuzz/harfbuzz/discussions/5118

Unfortunately, it sounds like glyph ID `0xFFFF` means "delete me" by convention in the AAT world, so it's a little complicated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2707518125

From prr at openjdk.org  Fri Mar  7 22:07:06 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 22:07:06 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
Message-ID: <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>

On Fri, 27 Dec 2024 11:05:30 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> This update allows users to print with grayscale using color printers.
>> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)).
>> 
>> **Fix description**
>> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D.
>> 
>> This approach is assumed to be platform, CUPS, and IPP protocol independent.
>> 
>> **Tests**
>> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1.
>
> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Update copyright, fix typos, move the proxy to the macos
>  - Merge branch 'master' into monochrome-printing
>  - proxy mac only
>  - Revert "grammar fixes"
>    
>    This reverts commit 355b2b8f1dbc71cef433e9a925dfb8a7fff56f99.
>  - Revert "formatting"
>    
>    This reverts commit fde514baeadc2775fa502a2a2d312c6038880e7a.
>  - Revert "update copyright"
>    
>    This reverts commit 60e9b4f024544cfac4ddaddc1ea3653bd4a2fe4c.
>  - Revert "move grayscale methods to PSPathGraphics"
>    
>    This reverts commit 1ef135680645ad2647c4430e852095dda8aa7e0c.
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>    
>    # Conflicts:
>    #	src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>  - move grayscale methods to PSPathGraphics
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6c591854...5486473b

So this approach looks much better. It works as I'd expect.
My quibbles are all with the test.

src/java.desktop/macosx/classes/sun/print/GrayscaleProxyGraphics2D.java line 3:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2024, BELLSOFT. All rights reserved.

I suggest updating everything to be 2025

test/jdk/javax/print/attribute/MonochromePrintTest.java line 63:

> 61:  * @key printer
> 62:  * @requires (os.family == "mac")
> 63:  * @summary javax.print: Support monochrome printing

This needs to be marked as main/manual

In addition you should use the PassFailJFrame framework you will see widely used in other manual tests that have been added or updated in the last year.

test/jdk/javax/print/attribute/MonochromePrintTest.java line 94:

> 92:         });
> 93: 
> 94:         long time = System.currentTimeMillis() + TIMEOUT;

There's an easy way to do this with PassFailJFrame

test/jdk/javax/print/attribute/MonochromePrintTest.java line 116:

> 114:         if (testCount != testTotalCount) {
> 115:             throw new Exception(
> 116:                     "Timeout: " + testCount + " tests passed out from " + testTotalCount);

I'm not sure where to put this comment, but the PASS and FAIL buttons are generally expected to mean "the whole test", so the flow wasn't what I expected. I think when you change this to use PassFailJFrame you'll find you need to change this to be conformant with how it works.

test/jdk/javax/print/attribute/MonochromePrintTest.java line 123:

> 121: 
> 122:         String[] instructions = {
> 123:                 "Two tests will run and it will test all available color apearances:",

spelling : should be "appearances"

test/jdk/javax/print/attribute/MonochromePrintTest.java line 124:

> 122:         String[] instructions = {
> 123:                 "Two tests will run and it will test all available color apearances:",
> 124:                 Arrays.toString(supportedChromaticity) + "supported by the printer.",

you need to add spaces around the toString(..). Currently this is displayed as
"Two tests will run and it will test all available color apearances:[color, monochrome]supported by the printer"

test/jdk/javax/print/attribute/MonochromePrintTest.java line 137:

> 135:                 "   The print dialog should appear.",
> 136:                 " - Select 'Appearance' tab.",
> 137:                 " - Select '" + chromaticity + "' on the 'Color apearance' panel.",

spelling again

test/jdk/javax/print/attribute/MonochromePrintTest.java line 144:

> 142:                 "A passing test will print the page with color appearance '" + chromaticity + "'.",
> 143:                 "The text, shapes and image should be " + chromaticity + ".",
> 144:                 "The test fails if the page is not printed with required color apearance.",

spelling again

test/jdk/javax/print/attribute/MonochromePrintTest.java line 199:

> 197:     private static void print(Chromaticity chromaticity) throws PrinterException {
> 198:         PrintRequestAttributeSet attr = new HashPrintRequestAttributeSet();
> 199:         attr.add(MediaSizeName.ISO_A4);

You should remove this line .. A4 is not necessarily available.

test/jdk/javax/print/attribute/MonochromePrintTest.java line 213:

> 211:             job.print();
> 212:         } else {
> 213:             throw new RuntimeException("Test for " + chromaticity + " is canceled!");

The test is very badly behaved if I press cancel. The exception is thrown on the Event Thread. Nothing catches it.
The user won't even see the message printed to stdout, and the test hangs, with all options greyed out.

test/jdk/javax/print/attribute/MonochromePrintTest.java line 291:

> 289: 
> 290:             BufferedImage bufferdImage = getBufferedImage((int) Math.ceil(pageFormat.getImageableWidth() / 3), (int) Math.ceil(pageFormat.getImageableHeight() / 7));
> 291:             g.drawImage(bufferdImage, null, sx, sy);

Break up this long line

test/jdk/javax/print/attribute/MonochromePrintTest.java line 304:

> 302: 
> 303:             Paint paint = new LinearGradientPaint(0, 0, 20, 5, new float[]{0.0f, 0.2f, 1.0f},
> 304:                     new Color[]{Color.RED, Color.GREEN, Color.CYAN}, MultipleGradientPaint.CycleMethod.REPEAT);

Break up this long line

test/jdk/javax/print/attribute/MonochromePrintTest.java line 313:

> 311:                     new Color[]{Color.RED, Color.GREEN, Color.CYAN}, MultipleGradientPaint.CycleMethod.REPEAT);
> 312:             g.setPaint(paint);
> 313:             g.fillRect(sx, imh + 10, 50, 50);

Break up this long line

-------------

PR Review: https://git.openjdk.org/jdk/pull/21930#pullrequestreview-2668401193
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985742882
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985721419
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985724097
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985742170
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985725618
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985732809
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985733893
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985728533
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985726653
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985737096
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985727620
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985728016
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985728198

From prr at openjdk.org  Fri Mar  7 22:07:07 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Mar 2025 22:07:07 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
 <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>
Message-ID: <mHHiL7g4Rhm6quPxZ-8gjMp2vsmDseIHqJCPsyYnKI0=.0549bd68-2e5c-4bfc-a3db-60a409db607f@github.com>

On Fri, 7 Mar 2025 21:36:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Update copyright, fix typos, move the proxy to the macos
>>  - Merge branch 'master' into monochrome-printing
>>  - proxy mac only
>>  - Revert "grammar fixes"
>>    
>>    This reverts commit 355b2b8f1dbc71cef433e9a925dfb8a7fff56f99.
>>  - Revert "formatting"
>>    
>>    This reverts commit fde514baeadc2775fa502a2a2d312c6038880e7a.
>>  - Revert "update copyright"
>>    
>>    This reverts commit 60e9b4f024544cfac4ddaddc1ea3653bd4a2fe4c.
>>  - Revert "move grayscale methods to PSPathGraphics"
>>    
>>    This reverts commit 1ef135680645ad2647c4430e852095dda8aa7e0c.
>>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>>    
>>    # Conflicts:
>>    #	src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
>>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>>  - move grayscale methods to PSPathGraphics
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6c591854...5486473b
>
> src/java.desktop/macosx/classes/sun/print/GrayscaleProxyGraphics2D.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2024, BELLSOFT. All rights reserved.
> 
> I suggest updating everything to be 2025

This class *could* be useful in other cases besides macOS. So perhaps you can move it to share/classes/sun/print ?
I note that macOS printing - unlike the Postscript and GDI cases - doesn't depend on the Banding raster print path.
To use it elsewhere, if there's transparency, we'd need to do something similar there to translate the band to gray - but that should not be too hard, if we need it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1985767596

From duke at openjdk.org  Sat Mar  8 00:23:02 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Sat, 8 Mar 2025 00:23:02 GMT
Subject: RFR: 8336382: Fix error reporting in loading AWT [v10]
In-Reply-To: <dWGArQHZNQiVwBkgjBvuZFYSQzjWdbYYeALdDAkw3jg=.926a6130-75b0-473f-8898-72da22db7c7a@github.com>
References: <m5S3knqxLW2I6NdoAyl9U3LoU6F9SHU2YySXCqJdZkc=.28b5a09b-2336-48dc-9dc1-ea12af8b618a@github.com>
 <fvX_A-K2GFBJaPZ82DOYkeFsZgLLTy4n_XOJIJ7vLOc=.7bcd5c36-6ba3-4c9a-a215-17fef50edb91@github.com>
 <dWGArQHZNQiVwBkgjBvuZFYSQzjWdbYYeALdDAkw3jg=.926a6130-75b0-473f-8898-72da22db7c7a@github.com>
Message-ID: <UdjOCCHGI0Aw5fuBbl8VAEei3Hy0dnOn47plqTJf71k=.6355d7ca-e3ef-43f1-b37c-df0c570a6f08@github.com>

On Fri, 31 Jan 2025 13:33:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Amended error message, doesn't clear exception
>
> See https://bugs.openjdk.org/browse/JDK-8349099
> 
> @Karm I was wondering why this did not show up on GHA (it's probably not executed there). But I noticed when researching this that your last merge from mainline was in September. Even if there are no "physical" merge conflicts that git can detect, there are likely to be "logical" conflicts like this, where a library was removed that your test depended on.
> 
> So for a long running PR like this, when it is ready to be checked in, you need to merge in main and verify that the fix (and the tests) still works, and nothing else breaks. If there are no "physical" conflicts you do not need to push the merge to the PR on github, since that might invalidate approvals, but you need to test it locally. 
> 
> As for how long "long running" is, I don't know. A week without merge is likely okay, 3 months is not.

@magicus @aivanov-jdk 

Thanks for the comments. I improved my flow; e.g. https://github.com/openjdk/jdk/pull/23852#issuecomment-2707082359

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2707770699

From dgredler at openjdk.org  Sat Mar  8 12:29:59 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sat, 8 Mar 2025 12:29:59 GMT
Subject: Integrated: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands
In-Reply-To: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
Message-ID: <eZ5mCjmpRQa27Nl1aacTE-uJQxOEoKuIig6_W9KQKO4=.f8c5ca36-eedf-4f77-83bc-3435b4cfced9@github.com>

On Wed, 12 Feb 2025 19:32:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
> 
> Two methods are impacted:
> 
> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
> 
> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
> 
> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
> 
> A test case is included.

This pull request has now been integrated.

Changeset: 7ec2e148
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ec2e14897e6dea0c7864a617ded0e33adf792f7
Stats:     317 lines in 2 files changed: 212 ins; 69 del; 36 mod

8349932: PSPrinterJob sometimes generates unnecessary PostScript commands

Reviewed-by: achung, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23595

From duke at openjdk.org  Sat Mar  8 13:39:44 2025
From: duke at openjdk.org (snake66)
Date: Sat, 8 Mar 2025 13:39:44 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

snake66 has updated the pull request incrementally with three additional commits since the last revision:

 - Use shell var syntax in libraries.m4
 - Fix typo PTREAD->PTHREAD
 - Revert changes to make/Hsdis.gmk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23930/files
  - new: https://git.openjdk.org/jdk/pull/23930/files/6a2c0e53..46999723

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=00-01

  Stats: 641 lines in 3 files changed: 0 ins; 0 del; 641 mod
  Patch: https://git.openjdk.org/jdk/pull/23930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23930/head:pull/23930

PR: https://git.openjdk.org/jdk/pull/23930

From kizune at openjdk.org  Sun Mar  9 02:57:01 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 9 Mar 2025 02:57:01 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <5xSDhfirAFhWrkywEnGD20qpEI4Nqz45tgWvLoCIiWw=.2842c7e0-0b14-4423-9f4a-84fbc8a24599@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
 <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YO
 vFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
 <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>
 <5xSDhfirAFhWrkywEnGD20qpEI4Nqz45tgWvLoCIiWw=.2842c7e0-0b14-4423-9f4a-84fbc8a24599@github.com>
Message-ID: <OE-EFprNbh0-IZfEh-1xWmYtsxUqDdEMznueslUiV4I=.bfe9b794-d436-4de3-8f1a-c7b993e0d83c@github.com>

On Thu, 6 Mar 2025 20:11:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> That is not a bad choice; this is how it should be implemented. Most, if not all, of those code paths are security-related. You can consult with the authors and reviewers of those patches to clarify why it was implemented that way.

Let's say i disagree here - and i talked with some of the authors and they did not sway my opinion.\

> But that new soundbank instrument is just a MIDI file rendered using the default soundbank. Do we really need to render it? Wouldn't it be possible to simply store the MIDI events and the soundbank and use them when the user selects the instrument?

No because rendering of the soundbank would take time - probably seconds - and that will throw reproduction of the second MIDI file off the track. I just remind that the MIDI we are rendering can come from any source - including the connected hardware like MIDI keyboard - and adding random delays before playing a note - even if it's one quarter or one eighth of a second will definitely be audible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1986203616

From ihse at openjdk.org  Mon Mar 10 11:09:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <2Q8X64gNkTwIahuYztjcdmNpOiwF9imTIUUI-0ASx4k=.4ba096ff-d60b-46fd-93ce-33215b0bc650@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

This looks good now. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670569844

From ihse at openjdk.org  Mon Mar 10 11:09:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <fW2QbW1i6Z-yKZaK2UhG5fn-SMbZ7QbX0DQQ4KC4x4w=.85a1740c-d82d-4681-bebf-bc5961a47c3c@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

Another follow-up is if it would hurt to include $LIBPTHREAD for *all* Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710217007

From duke at openjdk.org  Mon Mar 10 12:46:31 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Mar 2025 12:46:31 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v5]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <V3-rQMokxGGyq2nD1ijJFJFpqhKJLRWH1uejnDzIn5Y=.cdf7f01a-8123-4cc6-91c6-a5f5d4cc7f3a@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

GennadiyKrivoshein has updated the pull request incrementally with two additional commits since the last revision:

 - pass print options in UnixPrintJob as [ -o option[=value] ]
 - reset mediaTray to null for each PrintService

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/291ed330..3ea14d68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=03-04

  Stats: 167 lines in 3 files changed: 161 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23457/head:pull/23457

PR: https://git.openjdk.org/jdk/pull/23457

From erikj at openjdk.org  Mon Mar 10 13:04:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 13:04:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <9NJh2NWuQ_op9oUEpq2qS-64TpkGnIXaT54pdIV8amI=.e65c76d6-bb81-4ce0-b3ee-5d8c975b6ac5@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670880262

From duke at openjdk.org  Mon Mar 10 13:14:50 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Mar 2025 13:14:50 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v6]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <TZx80wAkuKKlrNc4gsiNtV41vK-thTnmpXU86NTc9jk=.dd251fcd-45b5-4a3d-a8ed-80a043f2ed77@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:

  simplify changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/3ea14d68..cb9fa254

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=04-05

  Stats: 13 lines in 1 file changed: 6 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23457/head:pull/23457

PR: https://git.openjdk.org/jdk/pull/23457

From psadhukhan at openjdk.org  Mon Mar 10 13:15:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Mar 2025 13:15:00 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v20]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <Ifpp3S3T7RER-bpVpyXBby_XLiRRHLfEaXDrWAHHd_Q=.5b946ea8-067c-43cb-ac83-f9fe14a3f736@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Code duplication removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/00daa8fb..b5a91f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=18-19

  Stats: 312 lines in 3 files changed: 137 ins; 135 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Mon Mar 10 13:15:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Mar 2025 13:15:00 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <wV_NxwKTx6OjwmcxAtIcUFp1rDgBaw3jr-Vu85MdO_s=.aaafe7f7-05c8-417b-b161-475fcbb490f6@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>
 <wV_NxwKTx6OjwmcxAtIcUFp1rDgBaw3jr-Vu85MdO_s=.aaafe7f7-05c8-417b-b161-475fcbb490f6@github.com>
Message-ID: <3ANRlYjGqwwDC80Pd96LsOK1tD5BNBH15PaXCcW8iaY=.e84fe5ec-77b8-417f-9fda-519acc086788@github.com>

On Fri, 7 Mar 2025 17:56:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > FWIW the current fix isn't what I'd like to see.
> > > Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??
> > 
> > 
> > Since the Windows L&F check in Basic*UI class is a bone of contention, I have removed it and put the code in Windows specific class although there's around 200+ lines of code duplication as most of the required helper methods in BasicMenuItemUI class has private access.. CI run in windows is ok..
> 
> Can we move these helper methods into a utility class which has public access to both `Basic*UI` and `Windows*UI`? `SwingUtilities3`, or a new class?

OK..Moved..PR updated

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2710554143

From aivanov at openjdk.org  Mon Mar 10 13:27:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Mar 2025 13:27:04 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <RXyoiSDhb_6dWmtjk3pJirHGgrcD7Zjv8hxzAgsK7aw=.c7cec7d3-28ff-4937-9b1c-fdb3763aa774@github.com>

On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 1:

> 1: /*

Could you bump the copyright year?

src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:

> 921:             int bufferedImageType = ((BufferedImage)image).getType();
> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {

Suggestion:

            if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
                    bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {

Usually, 8-space indentation used for wrapped continuation lines, if the wrapped isn't aligned to a structure on the first line.

Personally, I'd move the `&&` operator to the wrapped line ? it clearly indicates it's a continuation. Yet neither style has been agreed upon.

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 33:

> 31: 
> 32: import javax.imageio.ImageIO;
> 33: import java.awt.*;

Could you expand the wildcard imports?

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 63:

> 61:                 }
> 62:                 if (imageType == Transparency.BITMASK)
> 63:                     alpha[0] = 0;

Suggestion:

                if (imageType == Transparency.BITMASK) {
                    alpha[0] = 0;
                }

It's recommended to always use braces even when there's only one statement in the block.

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 74:

> 72:             boolean result = ImageIO.write(bi, "jpg", new ByteArrayOutputStream());
> 73:             if (result != expectedWriteReturnValue)
> 74:                 throw new Error("ImageIO.write(..) returned " + result + " but we expected " + expectedWriteReturnValue);

Suggestion:

            if (result != expectedWriteReturnValue) {
                throw new Error("ImageIO.write(..) returned " + result + " but we expected " + expectedWriteReturnValue);
            }

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 77:

> 75:             System.out.println("Tested passed");
> 76:             return true;
> 77:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 81:

> 79:             e.printStackTrace();
> 80:             return false;
> 81:         }

Should an exception be allowed to escape? You throw an `Error` if the expected return value doesn't match.

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 83:

> 81:         }
> 82:     }
> 83: }

Having a blank line in the end of a file is preferred.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987265582
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987265134
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987268179
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987271648
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987275369
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987276141
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987278113
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987278977

From duke at openjdk.org  Mon Mar 10 13:28:16 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Mar 2025 13:28:16 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v7]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:

  align UnixPrintJob with PSPrinterJob

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/cb9fa254..7316607e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=05-06

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23457/head:pull/23457

PR: https://git.openjdk.org/jdk/pull/23457

From duke at openjdk.org  Mon Mar 10 13:28:19 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Mar 2025 13:28:19 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v4]
In-Reply-To: <LEXFRSMjS0Nv4sxx_7hHKyvzksya6KyTzvYRsXcc5fc=.cc3054b4-a74b-4edb-bac5-ca817a2f62b4@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <qugwMqvHOugdo_sGQldgcvi09SK0ZpEXyY_hXKpm9xI=.da5c93dd-878e-4aff-bd4e-2fa861175667@github.com>
 <LEXFRSMjS0Nv4sxx_7hHKyvzksya6KyTzvYRsXcc5fc=.cc3054b4-a74b-4edb-bac5-ca817a2f62b4@github.com>
Message-ID: <MS_u5FSkkYvsHkvsGgbIWUI1n4wacCzGuI6bcBEs0o0=.23ea04a2-d18e-4e49-971e-3d7787260f1d@github.com>

On Wed, 5 Mar 2025 22:05:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into print_options_idx_out_of_rng
>>  - remove code duplication
>>  - replace regexp s+ with space
>>  - use array for option args
>>  - Fix ArrayIndexOutOfBoundsException at PSPrinterJob printExecCmd
>
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1579:
> 
>> 1577:         if (options != null && !options.isEmpty()) {
>> 1578:             optionArgs = options.trim().split(" ");
>> 1579:             ncomps+=optionArgs.length;
> 
> I would have gone for the simpler one line fix of
> ncomps+=options.trim().split(" ").length

Done. I tried to avoid using of the `options.trim().split(" ")` twice.

> test/jdk/javax/print/PrintExecCmdOptionTest.java line 59:
> 
>> 57:         MediaTray mediaTray = null;
>> 58:         for (PrintService ps : printServices) {
>> 59:             Media[] medias = (Media[]) ps.
> 
> It looks to me as if this loop needs to reset mediaTray = null.
> Otherwise if printer 'N' has a mediaTray, printer 'N+1' will inherit it, even if it does not have one.

Thank you. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1987280552
PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1987280422

From duke at openjdk.org  Mon Mar 10 13:36:00 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Mar 2025 13:36:00 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v4]
In-Reply-To: <LEXFRSMjS0Nv4sxx_7hHKyvzksya6KyTzvYRsXcc5fc=.cc3054b4-a74b-4edb-bac5-ca817a2f62b4@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <qugwMqvHOugdo_sGQldgcvi09SK0ZpEXyY_hXKpm9xI=.da5c93dd-878e-4aff-bd4e-2fa861175667@github.com>
 <LEXFRSMjS0Nv4sxx_7hHKyvzksya6KyTzvYRsXcc5fc=.cc3054b4-a74b-4edb-bac5-ca817a2f62b4@github.com>
Message-ID: <ubSu8j828BumOdr9RQ8C8NMsM0dreSa6GeX8gMzTX98=.c8ecead4-9ba5-4ae1-a696-55016b06bcbf@github.com>

On Wed, 5 Mar 2025 22:07:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into print_options_idx_out_of_rng
>>  - remove code duplication
>>  - replace regexp s+ with space
>>  - use array for option args
>>  - Fix ArrayIndexOutOfBoundsException at PSPrinterJob printExecCmd
>
> I notice that UnixPrintJob is even worse .. it would have the same problem except it doesn't even try to iterate over options, even though they can be specified !
> 
> I think it makes sense to fix that too.

@prrace UnixPrintJob updated. 
I found only one way to test UnixPrintJob and validate lpr command arguments - parse debug output of the print service and compare expected and actual options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23457#issuecomment-2710613725

From ihse at openjdk.org  Mon Mar 10 13:48:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:48:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
 <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
Message-ID: <g2XMt1vhpaPef9D_78B-x4Rn-hOQeSrBgyK2LJnTo2w=.5d1450d9-8fa0-4cbc-ade5-1a02e20a0250@github.com>

On Thu, 6 Mar 2025 13:27:15 GMT, snake66 <duke at openjdk.org> wrote:

>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
>> 
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
> 
> I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

@snake66 To integrate this, you need to give the command `/integrate` as a comment. Then I (or someone else) with committer permissions can sponsor the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710652078

From rmahajan at openjdk.org  Mon Mar 10 14:53:23 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Mon, 10 Mar 2025 14:53:23 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
Message-ID: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>

Added code to Iterates over all installed Look and Feel environments and added related exception handling.

Testing done.

-------------

Commit messages:
 - removed unnecessary import
 - code refactoring
 - modified code to do exception handling better
 - 8280818: Expand bug8033699.java to iterate over all LaFs

Changes: https://git.openjdk.org/jdk/pull/23964/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280818
  Stats: 110 lines in 1 file changed: 56 ins; 40 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23964/head:pull/23964

PR: https://git.openjdk.org/jdk/pull/23964

From duke at openjdk.org  Mon Mar 10 15:49:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 15:49:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <WeHasZlBKvJdQ7MR4Y_CQiTzB7LCmrEvchELsF61MWU=.cc92b7d3-86ff-4f38-bddc-de7b7f62d74e@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

@snake66 
Your change (at version 469997239f26f59cd47df19fb9e836b883687487) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2711042802

From prr at openjdk.org  Mon Mar 10 17:04:57 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Mar 2025 17:04:57 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v7]
In-Reply-To: <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
Message-ID: <rkwbi_IDZsDKE6dBNtvAIkp0Di-Ufqj4u0yboSFMdWo=.cdbbe694-c35d-46c2-b006-839654f18b1e@github.com>

On Mon, 10 Mar 2025 13:28:16 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align UnixPrintJob with PSPrinterJob

test/jdk/javax/print/UnixPrintJobOptionsTest.java line 50:

> 48:  * @bug 8349350
> 49:  * @key printer
> 50:  * @summary lpr command syntax for options. lpr [ -o option[=value] ]

This test needs an @requires tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1987695049

From duke at openjdk.org  Mon Mar 10 17:11:49 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 17:11:49 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v2]
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <MgYeafo3X-NcYxAQ6I2UVHsns9yt4wYuWJOwva52Z64=.e8d14d52-dcd4-4a14-a138-1e7126ed8705@github.com>

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Jeremy Wood has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23884/files
  - new: https://git.openjdk.org/jdk/pull/23884/files/63337c60..9f6b981e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From bpb at openjdk.org  Mon Mar 10 17:13:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 17:13:12 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
Message-ID: <rdzI3N9sQGbx-rVVAldCaqBXbpFzpqcG95vaKQ2qiVo=.add8117f-1569-477a-9731-62861973fc1e@github.com>

On Tue, 4 Mar 2025 03:41:10 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: adding "Reading Thumbnail Images" for Exif marker changes
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262

> the full name on your profile does not match the author name in this pull requests' [HEAD](https://git.openjdk.org/jdk/pull/22898/commits/eb2283c671c08e08a0f9e65c8c78f61e2dd01215) commit

@mickleness I think this PR is ready to be integrated after which one of us will sponsor it. I don't know whether you want to fix the aforementioned conflict in author name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2711282281

From duke at openjdk.org  Mon Mar 10 17:20:36 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 17:20:36 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:

 - 8351108: adding empty line to bottom of file
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/23884#discussion_r1987278977
 - Merge remote-tracking branch 'origin/JDK-8351108' into JDK-8351108
 - 8351108: replacing wildcard import
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/23884#discussion_r1987268179
 - 8351108: updating copyright year
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/23884#discussion_r1987265582
 - 8351108: changing indentation / line wrapping
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/23884#discussion_r1987265134

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23884/files
  - new: https://git.openjdk.org/jdk/pull/23884/files/9f6b981e..deaa0377

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From aivanov at openjdk.org  Mon Mar 10 17:20:36 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Mar 2025 17:20:36 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
Message-ID: <FrWLe8TsHHXSbXyE8TdmH8RetHhAPMNgSYjkfI1h520=.80c74a28-29d8-45d4-968e-4870ac38aa35@github.com>

On Mon, 10 Mar 2025 17:17:28 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - 8351108: adding empty line to bottom of file
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987278977
>  - Merge remote-tracking branch 'origin/JDK-8351108' into JDK-8351108
>  - 8351108: replacing wildcard import
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987268179
>  - 8351108: updating copyright year
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265582
>  - 8351108: changing indentation / line wrapping
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265134

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2671699641

From duke at openjdk.org  Mon Mar 10 17:20:37 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 17:20:37 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <RXyoiSDhb_6dWmtjk3pJirHGgrcD7Zjv8hxzAgsK7aw=.c7cec7d3-28ff-4937-9b1c-fdb3763aa774@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <RXyoiSDhb_6dWmtjk3pJirHGgrcD7Zjv8hxzAgsK7aw=.c7cec7d3-28ff-4937-9b1c-fdb3763aa774@github.com>
Message-ID: <gxWVODm4VkeU851oxoVG_R0p0InC3bX7WJszBTgbbs0=.7583e350-c26d-48d9-8135-241bcb0df670@github.com>

On Mon, 10 Mar 2025 13:16:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8351108: adding empty line to bottom of file
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987278977
>>  - Merge remote-tracking branch 'origin/JDK-8351108' into JDK-8351108
>>  - 8351108: replacing wildcard import
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987268179
>>  - 8351108: updating copyright year
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265582
>>  - 8351108: changing indentation / line wrapping
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265134
>
> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 1:
> 
>> 1: /*
> 
> Could you bump the copyright year?

Thanks, this is updated

> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:
> 
>> 921:             int bufferedImageType = ((BufferedImage)image).getType();
>> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {
> 
> Suggestion:
> 
>             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>                     bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {
> 
> Usually, 8-space indentation used for wrapped continuation lines, if the wrapped isn't aligned to a structure on the first line.
> 
> Personally, I'd move the `&&` operator to the wrapped line ? it clearly indicates it's a continuation. Yet neither style has been agreed upon.

OK, this is updated.

> test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 33:
> 
>> 31: 
>> 32: import javax.imageio.ImageIO;
>> 33: import java.awt.*;
> 
> Could you expand the wildcard imports?

OK, this is updated.

> test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 81:
> 
>> 79:             e.printStackTrace();
>> 80:             return false;
>> 81:         }
> 
> Should an exception be allowed to escape? You throw an `Error` if the expected return value doesn't match.

This is by design.

The main method resembles:

    public static void main(String[] args) throws IOException {
        boolean b1 = testJpegWriter(Transparency.OPAQUE, "OPAQUE", true);
        boolean b2 = testJpegWriter(Transparency.BITMASK, "BITMASK", false);
        boolean b3 = testJpegWriter(Transparency.TRANSLUCENT, "TRANSLUCENT", false);
        if (!(b1 && b2 && b3))
            throw new Error("Test failed");
    }


The intention here is to help log multiple failures at once. (Otherwise: if there are two failures A and B, then you can only discover B after resolving A.)

> test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 83:
> 
>> 81:         }
>> 82:     }
>> 83: }
> 
> Having a blank line in the end of a file is preferred.

OK, this is updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987717503
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987717590
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987717421
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987717299
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987717159

From azvegint at openjdk.org  Mon Mar 10 17:27:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 10 Mar 2025 17:27:54 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
Message-ID: <Gel6vmpFb0yN11aMhTr5JHMsfif8ZU6pUpDAD3xpUfU=.2ebeb318-3cd4-4d3e-9209-e12949f10df5@github.com>

On Mon, 10 Mar 2025 17:20:36 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - 8351108: adding empty line to bottom of file
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987278977
>  - Merge remote-tracking branch 'origin/JDK-8351108' into JDK-8351108
>  - 8351108: replacing wildcard import
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987268179
>  - 8351108: updating copyright year
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265582
>  - 8351108: changing indentation / line wrapping
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265134

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2671724242

From aivanov at openjdk.org  Mon Mar 10 17:27:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Mar 2025 17:27:55 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <kBwj7AvNJXAEcCUvsx8MeYyej5d3Z6otH_Tjcts2C7Q=.13bbe8b1-7cf8-4593-a0d4-59dae39bac19@github.com>
Message-ID: <EtMLzgM3jIb4SNIHezlH_mCB7T0uNW2rZR6YiASYfOc=.d94bdea9-4747-4c59-97b3-3e990c2580cc@github.com>

On Mon, 10 Mar 2025 17:20:36 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - 8351108: adding empty line to bottom of file
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987278977
>  - Merge remote-tracking branch 'origin/JDK-8351108' into JDK-8351108
>  - 8351108: replacing wildcard import
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987268179
>  - 8351108: updating copyright year
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265582
>  - 8351108: changing indentation / line wrapping
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987265134

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 40:

> 38: 
> 39: public class JpegWriterWriteNonOpaqueIndexColorModelTest {
> 40:     public static void main(String[] args) throws IOException {

The `main` method doesn't throw `IOException` so it could be removed from the `throws` clause and imports.
Suggestion:

    public static void main(String[] args) {

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 45:

> 43:         boolean b3 = testJpegWriter(Transparency.TRANSLUCENT, "TRANSLUCENT", false);
> 44:         if (!(b1 && b2 && b3))
> 45:             throw new Error("Test failed");

Suggestion:

        if (!(b1 && b2 && b3)) {
            throw new Error("Test failed");
        }

Missing braces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987725612
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987724631

From aivanov at openjdk.org  Mon Mar 10 17:30:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Mar 2025 17:30:56 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v3]
In-Reply-To: <gxWVODm4VkeU851oxoVG_R0p0InC3bX7WJszBTgbbs0=.7583e350-c26d-48d9-8135-241bcb0df670@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <RXyoiSDhb_6dWmtjk3pJirHGgrcD7Zjv8hxzAgsK7aw=.c7cec7d3-28ff-4937-9b1c-fdb3763aa774@github.com>
 <gxWVODm4VkeU851oxoVG_R0p0InC3bX7WJszBTgbbs0=.7583e350-c26d-48d9-8135-241bcb0df670@github.com>
Message-ID: <fEMYU3fZpH8P_jG9p0z0j10TRhbkINWeAdNP6lXNxlo=.d614fe0b-3ca9-4cf9-9f68-b2e16871c089@github.com>

On Mon, 10 Mar 2025 17:17:18 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 81:
>> 
>>> 79:             e.printStackTrace();
>>> 80:             return false;
>>> 81:         }
>> 
>> Should an exception be allowed to escape? You throw an `Error` if the expected return value doesn't match.
>
> This is by design.
> 
> The main method resembles:
> 
>     public static void main(String[] args) throws IOException {
>         boolean b1 = testJpegWriter(Transparency.OPAQUE, "OPAQUE", true);
>         boolean b2 = testJpegWriter(Transparency.BITMASK, "BITMASK", false);
>         boolean b3 = testJpegWriter(Transparency.TRANSLUCENT, "TRANSLUCENT", false);
>         if (!(b1 && b2 && b3))
>             throw new Error("Test failed");
>     }
> 
> 
> The intention here is to help log multiple failures at once. (Otherwise: if there are two failures A and B, then you can only discover B after resolving A.)

I see. Yet it still implies the `Error` isn't thrown in `result != expectedWriteReturnValue`? because if it is thrown, the test fails right away without running other cases.

It's fine, it's not expected to be thrown, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987733487

From honkar at openjdk.org  Mon Mar 10 17:51:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 17:51:15 GMT
Subject: Integrated: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <aRptPe17MqJarqsrU-5nArp9AU4MipSr3UbWsXqSiu4=.bbafc100-e23e-42b7-85bf-4a51dd1c33f8@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

This pull request has now been integrated.

Changeset: dbdbbd47
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbdbbd473061d7e8077ed07ccc6b03065a8c2ffc
Stats:     18558 lines in 193 files changed: 10013 ins; 2990 del; 5555 mod

8348597: Update HarfBuzz to 10.4.0

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23910

From prr at openjdk.org  Mon Mar 10 18:22:07 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Mar 2025 18:22:07 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v7]
In-Reply-To: <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
Message-ID: <bFRAxnko3ZgsOqdGLkA8ye-xZf72f7r7772RGgyf5yI=.2988eeef-9565-4b2d-859b-62cf1aedb8ab@github.com>

On Mon, 10 Mar 2025 13:28:16 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align UnixPrintJob with PSPrinterJob

test/jdk/javax/print/UnixPrintJobOptionsTest.java line 131:

> 129:             }
> 130:         }
> 131:         if (!success) {

Maybe it would be more robust to wrap everything in a try block with a finally to restore the printstream.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1987803814

From duke at openjdk.org  Mon Mar 10 18:22:49 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 18:22:49 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v4]
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <vtDAnfgFQo-4oEVubhnEoGHdcyvL6-60XMqxZG79zUU=.3dda8864-3623-414b-9b25-729dde7a56e6@github.com>

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8351108: changing Error to Exception, adding javadoc
  
  This is partly in response to:
  https://github.com/openjdk/jdk/pull/23884#discussion_r1987733487

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23884/files
  - new: https://git.openjdk.org/jdk/pull/23884/files/deaa0377..a69c2e05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=02-03

  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From duke at openjdk.org  Mon Mar 10 18:22:50 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 18:22:50 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v4]
In-Reply-To: <fEMYU3fZpH8P_jG9p0z0j10TRhbkINWeAdNP6lXNxlo=.d614fe0b-3ca9-4cf9-9f68-b2e16871c089@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <RXyoiSDhb_6dWmtjk3pJirHGgrcD7Zjv8hxzAgsK7aw=.c7cec7d3-28ff-4937-9b1c-fdb3763aa774@github.com>
 <gxWVODm4VkeU851oxoVG_R0p0InC3bX7WJszBTgbbs0=.7583e350-c26d-48d9-8135-241bcb0df670@github.com>
 <fEMYU3fZpH8P_jG9p0z0j10TRhbkINWeAdNP6lXNxlo=.d614fe0b-3ca9-4cf9-9f68-b2e16871c089@github.com>
Message-ID: <FMug9419DrSERET5Bdw616mFd3Z3KFbvbh3q3lX5MRQ=.076926c5-693b-415b-a8f4-13ec0eead95a@github.com>

On Mon, 10 Mar 2025 17:28:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This is by design.
>> 
>> The main method resembles:
>> 
>>     public static void main(String[] args) throws IOException {
>>         boolean b1 = testJpegWriter(Transparency.OPAQUE, "OPAQUE", true);
>>         boolean b2 = testJpegWriter(Transparency.BITMASK, "BITMASK", false);
>>         boolean b3 = testJpegWriter(Transparency.TRANSLUCENT, "TRANSLUCENT", false);
>>         if (!(b1 && b2 && b3))
>>             throw new Error("Test failed");
>>     }
>> 
>> 
>> The intention here is to help log multiple failures at once. (Otherwise: if there are two failures A and B, then you can only discover B after resolving A.)
>
> I see. Yet it still implies the `Error` isn't thrown in `result != expectedWriteReturnValue`? because if it is thrown, the test fails right away without running other cases.
> 
> It's fine, it's not expected to be thrown, right?

Ah, thanks. I changed that Error to an Exception. (That was probably an old artifact from earlier drafts.)

You're correct: it's not expected to be thrown. (No Throwables should be thrown in this test anymore.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987804948

From duke at openjdk.org  Mon Mar 10 18:24:05 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 18:24:05 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
Message-ID: <PwClRknZOzf74FafTa19BiR-INr9dMAXYAMBFNEAr7Q=.ca9ddca2-5737-4dc1-ac34-299b568bc55b@github.com>

On Tue, 4 Mar 2025 03:41:10 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: adding "Reading Thumbnail Images" for Exif marker changes
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262

@mickleness 
Your change (at version eb2283c671c08e08a0f9e65c8c78f61e2dd01215) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2711455050

From duke at openjdk.org  Mon Mar 10 18:28:07 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 18:28:07 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
Message-ID: <gdqA-PUhiXSPLT_EngaQiPCMNCb2uA5gfwd8Amq7BN8=.3a9f323b-2aeb-4dca-b02a-46fae092b5fb@github.com>

On Tue, 4 Mar 2025 03:41:10 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: adding "Reading Thumbnail Images" for Exif marker changes
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262

Thanks. (Is there a strong incentive to resolve the author name? Unless I'm opting out of my OpenJDK royalty payments/airline miles/etc: I'm not too worried about it. :) )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2711464331

From prr at openjdk.org  Mon Mar 10 18:35:09 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Mar 2025 18:35:09 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v10]
In-Reply-To: <rdzI3N9sQGbx-rVVAldCaqBXbpFzpqcG95vaKQ2qiVo=.add8117f-1569-477a-9731-62861973fc1e@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <fIbFA8gs6gmwabmoPBRgZ7lHDUEopdVoEKpGejkhAlE=.4bb1af66-928a-4b8c-8b04-e3df1b0839a2@github.com>
 <rdzI3N9sQGbx-rVVAldCaqBXbpFzpqcG95vaKQ2qiVo=.add8117f-1569-477a-9731-62861973fc1e@github.com>
Message-ID: <FvKAFPo4kulIDafKdJJYkshAaPa_RZqDwGJjwBldHkY=.772848e9-b7f8-4c2c-b072-022215b2d226@github.com>

On Mon, 10 Mar 2025 17:10:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: adding "Reading Thumbnail Images" for Exif marker changes
>>   
>>   This is in response to:
>>   https://github.com/openjdk/jdk/pull/22898#issuecomment-2695754262
>
>> the full name on your profile does not match the author name in this pull requests' [HEAD](https://git.openjdk.org/jdk/pull/22898/commits/eb2283c671c08e08a0f9e65c8c78f61e2dd01215) commit
> 
> @mickleness I think this PR is ready to be integrated after which one of us will sponsor it. I don't know whether you want to fix the aforementioned conflict in author name.

Thank you @bplb for your reviews on this.

I have no idea about the author name. Perhaps it helps when people are compiling a list of your fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2711481322

From duke at openjdk.org  Mon Mar 10 18:35:11 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 18:35:11 GMT
Subject: Integrated: 8160327: Support for thumbnails present in APP1 marker for
 JPEG
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <M2b_CTienuz-QYOPj2X5Il4_Yg2tZxtyc_WgMlQnYTw=.6814358b-e020-4000-8963-58e18d186335@github.com>

On Wed, 1 Jan 2025 21:38:28 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

This pull request has now been integrated.

Changeset: 73465b98
Author:    jeremy <jeremy.wood at mac.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73465b9866da8e97e557d6ad80a95568ada3ee01
Stats:     711 lines in 14 files changed: 688 ins; 0 del; 23 mod

8160327: Support for thumbnails present in APP1 marker for JPEG

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/22898

From prr at openjdk.org  Mon Mar 10 18:49:58 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Mar 2025 18:49:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
Message-ID: <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>

On Fri, 7 Mar 2025 01:37:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>>If an app got a profile 'from some place', it probably should not be trying to change it,
>> 
>> But this is not always possible. For example, a buffered image has a color model that references a color space and a color profile. To modify something in that profile(like intents screen vs printer) before converting the entire image, it is necessary to check whether it is a built-in profile. If it is, the whole image must be recreated; otherwise, an exception will occur. Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
>> 
>>>I don't see such a discussion there. Maybe it was 'offline' ?
>> 
>> It was somewhere online not too long ago.
>
>>Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
> 
> But it also has its own disadvantages...

The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
It just ensures that the JDK internally caches the original value for use in certain places.

Consider this program

public class jh {
  public static void main(String[] args) {
   String jhpstr = "java.home";
   String jhp1 = System.getProperty(jhpstr);
   System.setProperty(jhpstr, "foo");
   String jhp2 = System.getProperty("java.home");
   System.out.println(jhp1+" " +jhp2);
  }
} 
% java jh
/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home foo

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1987841827

From aivanov at openjdk.org  Mon Mar 10 19:37:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Mar 2025 19:37:09 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v4]
In-Reply-To: <vtDAnfgFQo-4oEVubhnEoGHdcyvL6-60XMqxZG79zUU=.3dda8864-3623-414b-9b25-729dde7a56e6@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <vtDAnfgFQo-4oEVubhnEoGHdcyvL6-60XMqxZG79zUU=.3dda8864-3623-414b-9b25-729dde7a56e6@github.com>
Message-ID: <bc4vSlUi7ofI9rtCQswbp8UYp1VrO81ZWcRRgN2Iht0=.fb2dbc9c-2b46-4b5b-91de-3d2556e27cce@github.com>

On Mon, 10 Mar 2025 18:22:49 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351108: changing Error to Exception, adding javadoc
>   
>   This is partly in response to:
>   https://github.com/openjdk/jdk/pull/23884#discussion_r1987733487

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

I prefer regular block comments over javadoc-style comments for jtreg tags. Otherwise, IDE shows a warning for _dangling javadoc comment_, or warns about bad javadoc tags.

I don't insist here.

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 55:

> 53:      * @param name the name of the Transparency constant
> 54:      * @param expectedWriteReturnValue the expected return value of <code>ImageIO.write(..)</code>
> 55:      * @return true if <code>ImageIO.write(..) == expectedWriteReturnValue</code>, or false otherwise.

Using `{@code ...}` is the preferred way to mark-up code fragments.

Perhaps, a javadoc is too much? The method isn't that long, and it's rather self-documenting.

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 81:

> 79:                 }
> 80:             }
> 81:             IndexColorModel indexColorModel = new IndexColorModel(8, 256, gray, gray, gray, alpha);

Suggestion:

            }

            IndexColorModel indexColorModel = new IndexColorModel(8, 256, gray, gray, gray, alpha);

I think a blank line here will visually separate the block of preparing the arrays for `IndexColorModel` from their usage.

Creating an instance of `IndexColorModel` marks the start of the *real test*.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2671974299
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987882658
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987896914
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987901996

From dgredler at openjdk.org  Mon Mar 10 19:59:01 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Mar 2025 19:59:01 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <X3iMI3qoS0lXiMU_VPnV7wJOiCFsvy5-tuW0mT4Xq94=.451712f8-d11c-4b1d-a093-dadfacee6691@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
 <X3iMI3qoS0lXiMU_VPnV7wJOiCFsvy5-tuW0mT4Xq94=.451712f8-d11c-4b1d-a093-dadfacee6691@github.com>
Message-ID: <2y7ZqdqfsPYBwCCITRhd0GeZnedbpf1mQsexIoLQARg=.a0efdf4c-6e35-4b2e-81f5-f4ec1eab94a7@github.com>

On Thu, 6 Mar 2025 22:32:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> I just deleted a comment added to the wrong PR!

@prrace Did you get a chance to submit that test job for this PR? If so, were there any failures? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2711678701

From dgredler at openjdk.org  Mon Mar 10 20:16:56 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Mar 2025 20:16:56 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

Good news: it looks like it was possible to resolve the `0xFFFF` conflict on the HarfBuzz side by adjusting the HarfBuzz internal representation of AAT deleted glyphs. Amazingly quick turnaround from @behdad! I think we'll want to put this PR on hold until the next HarfBuzz upgrade. How often are dependencies like HarfBuzz upgraded? I saw we just completed one today, coincidentally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2711714892

From duke at openjdk.org  Mon Mar 10 20:38:45 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 20:38:45 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v5]
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <IgVYhf-82WICPrKJOMNF2o3n5bwmlmJQzZ6bguucQrw=.d6304736-b449-4b2f-bd3b-e97ba581aa24@github.com>

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Jeremy Wood has updated the pull request incrementally with six additional commits since the last revision:

 - Merge branch 'JDK-8351108' of https://github.com/mickleness/jdk into JDK-8351108
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - 8351108: removing method javadoc
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/23884#discussion_r1987896914
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23884/files
  - new: https://git.openjdk.org/jdk/pull/23884/files/a69c2e05..0bf592cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=03-04

  Stats: 16 lines in 1 file changed: 2 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From duke at openjdk.org  Mon Mar 10 20:38:45 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 10 Mar 2025 20:38:45 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v4]
In-Reply-To: <bc4vSlUi7ofI9rtCQswbp8UYp1VrO81ZWcRRgN2Iht0=.fb2dbc9c-2b46-4b5b-91de-3d2556e27cce@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <vtDAnfgFQo-4oEVubhnEoGHdcyvL6-60XMqxZG79zUU=.3dda8864-3623-414b-9b25-729dde7a56e6@github.com>
 <bc4vSlUi7ofI9rtCQswbp8UYp1VrO81ZWcRRgN2Iht0=.fb2dbc9c-2b46-4b5b-91de-3d2556e27cce@github.com>
Message-ID: <OGhmOrNZZTG9O-wJqYQnmZKe8BEjoYBA8oYln71GNhA=.e2bd17db-33bc-42b2-93a5-b8caac928086@github.com>

On Mon, 10 Mar 2025 19:28:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8351108: changing Error to Exception, adding javadoc
>>   
>>   This is partly in response to:
>>   https://github.com/openjdk/jdk/pull/23884#discussion_r1987733487
>
> test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 55:
> 
>> 53:      * @param name the name of the Transparency constant
>> 54:      * @param expectedWriteReturnValue the expected return value of <code>ImageIO.write(..)</code>
>> 55:      * @return true if <code>ImageIO.write(..) == expectedWriteReturnValue</code>, or false otherwise.
> 
> Using `{@code ...}` is the preferred way to mark-up code fragments.
> 
> Perhaps, a javadoc is too much? The method isn't that long, and it's rather self-documenting.

OK, the javadoc is removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1987981271

From honkar at openjdk.org  Mon Mar 10 20:40:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 20:40:54 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>
Message-ID: <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>

On Mon, 10 Mar 2025 20:13:51 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Good news: it looks like it was possible to resolve the `0xFFFF` conflict on the HarfBuzz side by adjusting the HarfBuzz internal representation of AAT deleted glyphs. Amazingly quick turnaround from @behdad! I think we'll want to put this PR on hold until the next HarfBuzz upgrade. How often are dependencies like HarfBuzz upgraded? I saw we just completed one today, coincidentally.

@gredler  Yes, JDK harfbuzz was just upgraded to v10.4.0 - https://github.com/openjdk/jdk/pull/23910.

@prrace Do we consider patching the fix from upstream for this upgrade or can it wait till the next time harfbuzz is upgraded  - https://github.com/harfbuzz/harfbuzz/pull/5119 ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2711768686

From dgredler at openjdk.org  Mon Mar 10 20:51:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Mar 2025 20:51:54 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>
 <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>
Message-ID: <Ohklb43JiXf9MO6LG0GXn01Y2qZuLF96wyBhHb-pHy4=.d125bc85-ea71-4992-9d81-1f42f01024f3@github.com>

On Mon, 10 Mar 2025 20:37:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Good news: it looks like it was possible to resolve the `0xFFFF` conflict on the HarfBuzz side by adjusting the HarfBuzz internal representation of AAT deleted glyphs. Amazingly quick turnaround from @behdad! I think we'll want to put this PR on hold until the next HarfBuzz upgrade. How often are dependencies like HarfBuzz upgraded? I saw we just completed one today, coincidentally.
>
> @gredler  Yes, JDK harfbuzz was just upgraded to v10.4.0 - https://github.com/openjdk/jdk/pull/23910.
> 
> @prrace Do we consider patching the fix from upstream for this upgrade or can it wait till the next time harfbuzz is upgraded  - https://github.com/harfbuzz/harfbuzz/pull/5119 ?

@honkar-jdk Thanks for the info -- note that it's actually a combination of two HB PRs (https://github.com/harfbuzz/harfbuzz/pull/5119 and https://github.com/harfbuzz/harfbuzz/pull/5126), and it sounds like they plan to cut a release with the fix later this week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2711790094

From honkar at openjdk.org  Mon Mar 10 23:22:36 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 23:22:36 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v14]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <g5tI2I9IihEd9EKtnaGPRmka4K3IuNnW4QbgTRGv9Kk=.df52cb0c-b9b0-4757-b7e9-1ca7759005a8@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  builtIn converted to transient, tests updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/6e3b98ae..918cd67a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=12-13

  Stats: 18 lines in 3 files changed: 5 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Mon Mar 10 23:39:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 23:39:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <9vbGkBRR9Zo9jy41Gh5uSuNtPSAQQNevg1MHHB-7-Eg=.72ec2f7e-903c-4f6b-ac8a-06b231e737ce@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <sx7PKXWiw_DfTYDDu6p0vcuXLokHzv0tnpG2_EYFGD4=.5ed63f88-a946-4219-b38e-ed17f342d0b3@github.com>
 <8jjMYB1Gq6UdQLWUPxUr_VzrFvNDgFXQf4SRlKFX3TA=.974162ad-9f6f-4201-a267-3e5c358003ba@github.com>
 <YhM7LecekYqmQKZUTluIXD_tU-dLawTFAcYz2Td0FoE=.9c7b3d9e-5386-4d89-8118-6b3dd9437cf5@github.com>
 <V2Y1WH5_BnqPsyGN67wBEOVHOqZ8_f39HAQTkgq6RO8=.d81c7a50-0909-4e06-93a1-f20d4f39c3f0@github.com>
 <hF9k5enYPMOLMRVUsOm9cF8teG5cxQLTQSoNFLcxs4A=.97674177-3306-44fc-b39e-43667bfea565@github.com>
 <9vbGkBRR9Zo9jy41Gh5uSuNtPSAQQNevg1MHHB-7-Eg=.72ec2f7e-903c-4f6b-ac8a-06b231e737ce@github.com>
Message-ID: <b7BQ70p4UiD6UjmjIg8EaJwVws4C-hPwt3l1VoUj9zE=.60a37c6b-80c8-4d82-81a6-cbdae1f5c336@github.com>

On Thu, 6 Mar 2025 20:20:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, readObject(..) and readResolve(..) will return the singleton, as per the serialization spec ? https://docs.oracle.com/en/java/javase/21/docs/api/serialized-form.html#java.awt.color.ICC_Profile
>> but I agree we don't need to mention that here.
>> 
>> Yes, I agree builtIn should be transient, since we return the singleton as above, all will work as expected.
>
>>Yes, readObject(..) and readResolve(..) will return the singleton
> 
> We do not specify anywhere in the API that we use singletons; that is an implementation detail.

builtIn flag converted to transient var.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1988155483

From honkar at openjdk.org  Mon Mar 10 23:39:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 23:39:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <DtkRoB2uSz5iZptH0CU0rFM5ljFmHvp74YCZWYLH3Bk=.c8b68b57-7b14-4c5a-800e-c2741c6ff28d@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
 <DtkRoB2uSz5iZptH0CU0rFM5ljFmHvp74YCZWYLH3Bk=.c8b68b57-7b14-4c5a-800e-c2741c6ff28d@github.com>
Message-ID: <zcvqJX27wXIUKFZAx9rtlebQrKkyfE3H8qQx6OpalPE=.4155d582-7d40-4952-bf31-574e354c254c@github.com>

On Wed, 5 Mar 2025 20:55:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor
>
> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 71:
> 
>> 69:             } catch (IllegalArgumentException iae) {
>> 70:                 if (!iae.getMessage().equals(EXCEPTION_MSG)) {
>> 71:                     throw new RuntimeException("Test Failed! IAE with exception msg \""
> 
> I don't think you need to - or should - expect a specific exception message.
> Obviously you can update the test if the text changes, but I just don't think this is necessary.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1988153762

From honkar at openjdk.org  Mon Mar 10 23:39:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 23:39:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <AIFWC_wrsYuKV4LsDzv7-dIn1CwXu3LW56Oj7YEEfK4=.7adcb637-2b1e-4a53-8c8f-89d58b9f09bf@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
 <AIFWC_wrsYuKV4LsDzv7-dIn1CwXu3LW56Oj7YEEfK4=.7adcb637-2b1e-4a53-8c8f-89d58b9f09bf@github.com>
Message-ID: <OReDC2xyKS4tGF7bZ92247hxAXdozUIQj2UJse0wUTU=.14b82877-0fd7-496c-b036-bb8ae6326def@github.com>

On Thu, 6 Mar 2025 03:21:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor
>
> test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 37:
> 
>> 35:             ColorSpace.CS_PYCC, ColorSpace.CS_GRAY,
>> 36:             ColorSpace.CS_CIEXYZ
>> 37:     };
> 
> With this modification, we will lose information about which color space is broken from the stack trace. So, at the least, you should print it in case of failure.

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1988153898

From duke at openjdk.org  Tue Mar 11 00:37:00 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 00:37:00 GMT
Subject: Withdrawn: 8337505: Footprint and startup regressions up to 20% in GUI
 apps
In-Reply-To: <XR27ACM-U5dSQ2wrhDkTm0OKSsKvIW9kKe31j8I8cBU=.39253850-f97e-4f3b-96da-877d4c9b5f44@github.com>
References: <XR27ACM-U5dSQ2wrhDkTm0OKSsKvIW9kKe31j8I8cBU=.39253850-f97e-4f3b-96da-877d4c9b5f44@github.com>
Message-ID: <S6LnGtJpOGkkTYW0TiiREWqCkMiq0HbsTBn4q4ebtjg=.d4d5f44d-e9dc-41de-bc04-1ffbfbdccb01@github.com>

On Mon, 28 Oct 2024 21:26:38 GMT, Phil Race <prr at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8338677 already improved things for this so that's good.
> 
> This fix adds to it lazy initialisation of VarHandles in StrikeCache at the cost of some extra code.
> Since these VarHandles get used more or less immediately on Linux this new fix won't further improve matters there
> But should help on Mac where they aren't usually needed at startup
> And Windows is somewhere in between.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21748

From honkar at openjdk.org  Tue Mar 11 00:57:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 00:57:53 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v3]
In-Reply-To: <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <bc-9mgpiVuqPo-rtAY8fvy8iOIQ99m-M_9aTGZ-3cGE=.4e921da4-45b3-4288-8456-aa82fc6617be@github.com>
Message-ID: <yWg28GYwZKBDqDFF44oyj1l_9_x9xRQkoX7rhT79q90=.9740573d-a498-4d19-b3ea-faa19a2d32c5@github.com>

On Mon, 3 Mar 2025 12:11:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pushed to mac os specific class

LGTM. With the updated fix, VO announces percentage values consistently.

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23841#pullrequestreview-2672472354

From prr at openjdk.org  Tue Mar 11 04:20:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Mar 2025 04:20:53 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <fQlgEheIDonk8ESfU06EKoecDzJwrR8nrLBOU5thzUM=.40e88b98-8b49-4852-8977-209c6ce490f5@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

testing looks OK

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23852#pullrequestreview-2672744710

From prr at openjdk.org  Tue Mar 11 04:24:59 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Mar 2025 04:24:59 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <iRG3KVw2y2TRGkHdofolGTr8NwdEXER33JiIz1uw2Ec=.c39d2071-348a-44e9-840e-ef8e65f1ef54@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Testing passed. And I can't see a specific fault here, but have a sense of not being sure we have enough test coverage. Fingers crossed.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23603#pullrequestreview-2672751442

From prr at openjdk.org  Tue Mar 11 04:31:52 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Mar 2025 04:31:52 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <1I02tNia1_P7YHVQ4cVyWr7x_PzoCeM03xZFB5rGZek=.44bc3597-7113-4d8c-8094-8ccf57cab3d0@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

Without even yet having looked at the fix in upstream I'll say something
In general I am not in favour of taking point fixes.
(1) we are supposed to say what version of [upstream library] is in JDK and where do you draw the line of we have version N, vs N+1.
(2) un-released patches may not be properly tested.
(3) They may be reverted, and then where are we ?

Upgrading harfbuzz is not frequent (we don't need busy work) but if there's a clear and valuable reason, it can be done.
In this case, there should be very few (weeks vs years) upstream changes, so I'd support doing it if it makes sense.
But I need to look at the specifics of the upstream fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2712581534

From prr at openjdk.org  Tue Mar 11 04:53:51 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Mar 2025 04:53:51 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <VOAwd5WfEU7uE1E69qUyhtCvMg2xweNoK4YTpRDuHpI=.93d51f55-4b9b-466f-889b-9b3032d49785@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

So let's see if we can integrate a new HB release in maybe 6 weeks from now, and then take up this PR again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2712620020

From abhiscxk at openjdk.org  Tue Mar 11 06:31:14 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Mar 2025 06:31:14 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 1:

> 1: /*

Minor changes can be done
1. mainFrame = new JFrame("Bug 8033699 - `9` Tests for `Grouped / Non-Grouped` Radio Buttons");
2. Non group can be changed to non-group (For consistency across test)
3. Please limit to 80 cols wherever applicable 

Otherwise the changes look good. Verified test on macOS and it works as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1988489870

From abhiscxk at openjdk.org  Tue Mar 11 09:08:07 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Mar 2025 09:08:07 GMT
Subject: Integrated: 8286204: [Accessibility, macOS, VoiceOver] VoiceOver reads
 the spinner value 10 as 1 when user iterates to 10 for the first time
 on macOS
In-Reply-To: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
Message-ID: <92NMLpDBa6-Dj26uwD_wU_uCCILaBhwDK3yh4O0WXUI=.897c90ba-c8db-4fa0-97ca-9d80d378aa2a@github.com>

On Fri, 28 Feb 2025 11:22:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
> 
> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
> Manual test case is added to verify the fix.
> 
> CI pipeline testing is ok for the proposed fix.

This pull request has now been integrated.

Changeset: cd9f1d3d
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd9f1d3d921531511a7552807d099d5d3cce01a6
Stats:     81 lines in 2 files changed: 80 ins; 0 del; 1 mod

8286204: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value 10 as 1 when user iterates to 10 for the first time on macOS

Reviewed-by: honkar, kizune, asemenov

-------------

PR: https://git.openjdk.org/jdk/pull/23841

From sgehwolf at openjdk.org  Tue Mar 11 09:43:53 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Mar 2025 09:43:53 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <dIMBlzURwWXf4EhMy08lpXkcybHMMVFt8AfkLDXuaqY=.1dab6cb8-e93c-4293-adca-997f55060b09@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23852#pullrequestreview-2673633539

From duke at openjdk.org  Tue Mar 11 09:52:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 09:52:53 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <bmQpvmIrZlOnkom0PuNrgqNdQC3D3yHCz2ohmbW-S8A=.89727309-b104-498b-851d-d014ca260518@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

@gredler 
Your change (at version b9b707ae230ed5a46e1219618f9bf5ebc46efa6e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2713414241

From dgredler at openjdk.org  Tue Mar 11 09:57:03 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 11 Mar 2025 09:57:03 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>
 <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>
Message-ID: <Wx8L67SYu5EkxM4FWib3gGozhg5i71elF3KVHI_iZhw=.12ab68f9-7e5a-47d2-81d0-18d9e6d3f848@github.com>

On Mon, 10 Mar 2025 20:37:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Good news: it looks like it was possible to resolve the `0xFFFF` conflict on the HarfBuzz side by adjusting the HarfBuzz internal representation of AAT deleted glyphs. Amazingly quick turnaround from @behdad! I think we'll want to put this PR on hold until the next HarfBuzz upgrade. How often are dependencies like HarfBuzz upgraded? I saw we just completed one today, coincidentally.
>
> @gredler  Yes, JDK harfbuzz was just upgraded to v10.4.0 - https://github.com/openjdk/jdk/pull/23910.
> 
> @prrace Do we consider patching the fix from upstream (https://github.com/harfbuzz/harfbuzz/pull/5119) for this upgrade or can it wait till the next time harfbuzz is upgraded on jdk ?

@honkar-jdk @prrace Makes sense -- thanks for having a look, and I'll check back in on this one later in April.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2713429926

From aivanov at openjdk.org  Tue Mar 11 12:43:06 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 12:43:06 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <KCl878UYB3BYfHd_qrVabDtwvfx1rMsZE-m3MK16z9w=.f074b384-b317-4924-b9f0-0dfd4c36fb97@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

The initial year in the copyright should be preserved; and a second one is to be added if there's no second year, or the second year needs to be bumped to the current year.

Other than that, it looks good.

test/jdk/java/awt/Headless/HeadlessMalfunctionAgent.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

The first year should be preserved; when there are two years, the last one gets updated.

test/jdk/java/awt/Headless/HeadlessMalfunctionTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23852#pullrequestreview-2674244861
PR Review Comment: https://git.openjdk.org/jdk/pull/23852#discussion_r1989130920
PR Review Comment: https://git.openjdk.org/jdk/pull/23852#discussion_r1989164490

From aivanov at openjdk.org  Tue Mar 11 13:50:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 13:50:08 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v5]
In-Reply-To: <IgVYhf-82WICPrKJOMNF2o3n5bwmlmJQzZ6bguucQrw=.d6304736-b449-4b2f-bd3b-e97ba581aa24@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <IgVYhf-82WICPrKJOMNF2o3n5bwmlmJQzZ6bguucQrw=.d6304736-b449-4b2f-bd3b-e97ba581aa24@github.com>
Message-ID: <oQBFk40OHLkkJJ9plmgb4yK_WhZUlVI71T5P7dVB-40=.e41fbb97-d502-4ec6-9df3-881e39d9bde3@github.com>

On Mon, 10 Mar 2025 20:38:45 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Merge branch 'JDK-8351108' of https://github.com/mickleness/jdk into JDK-8351108
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - 8351108: removing method javadoc
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987896914
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2674604546

From aivanov at openjdk.org  Tue Mar 11 14:46:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 14:46:00 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v5]
In-Reply-To: <IgVYhf-82WICPrKJOMNF2o3n5bwmlmJQzZ6bguucQrw=.d6304736-b449-4b2f-bd3b-e97ba581aa24@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <IgVYhf-82WICPrKJOMNF2o3n5bwmlmJQzZ6bguucQrw=.d6304736-b449-4b2f-bd3b-e97ba581aa24@github.com>
Message-ID: <8jhvCfYM6iSpqwygySYKFjUTMtyU6VPaePRcv-J--1M=.44bdd0f4-8cc1-4100-a4c9-6cb5f5bb4fe7@github.com>

On Mon, 10 Mar 2025 20:38:45 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Merge branch 'JDK-8351108' of https://github.com/mickleness/jdk into JDK-8351108
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - 8351108: removing method javadoc
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/23884#discussion_r1987896914
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java line 37:

> 35: import java.awt.image.IndexColorModel;
> 36: import java.io.ByteArrayOutputStream;
> 37: import java.io.IOException;

I'd appreciate if you remove `IOException` from imports, it's unused now.
Suggestion:

import java.io.ByteArrayOutputStream;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1989454070

From duke at openjdk.org  Tue Mar 11 14:48:12 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 11 Mar 2025 14:48:12 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v8]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:

  restore original printstream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/7316607e..4ff93845

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23457&range=06-07

  Stats: 43 lines in 1 file changed: 20 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23457/head:pull/23457

PR: https://git.openjdk.org/jdk/pull/23457

From duke at openjdk.org  Tue Mar 11 14:59:12 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 11 Mar 2025 14:59:12 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v7]
In-Reply-To: <rkwbi_IDZsDKE6dBNtvAIkp0Di-Ufqj4u0yboSFMdWo=.cdbbe694-c35d-46c2-b006-839654f18b1e@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
 <rkwbi_IDZsDKE6dBNtvAIkp0Di-Ufqj4u0yboSFMdWo=.cdbbe694-c35d-46c2-b006-839654f18b1e@github.com>
Message-ID: <WrFpf_CLMpJ9_haiAKcM8h1uDlENDh_WI_gHCy8DWbo=.cf950001-e7e1-4da8-8206-9bb2fed2b359@github.com>

On Mon, 10 Mar 2025 17:02:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   align UnixPrintJob with PSPrinterJob
>
> test/jdk/javax/print/UnixPrintJobOptionsTest.java line 50:
> 
>> 48:  * @bug 8349350
>> 49:  * @key printer
>> 50:  * @summary lpr command syntax for options. lpr [ -o option[=value] ]
> 
> This test needs an @requires tag.

Sure, added `@requires (os.family...`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1989483577

From duke at openjdk.org  Tue Mar 11 15:02:55 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 11 Mar 2025 15:02:55 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v7]
In-Reply-To: <bFRAxnko3ZgsOqdGLkA8ye-xZf72f7r7772RGgyf5yI=.2988eeef-9565-4b2d-859b-62cf1aedb8ab@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <2Zh-P6g6uSiNtyy19n4HD92ZflImSGBmaKdPOjPX2qY=.85955340-5f4d-43f3-8e82-8a31cfa11816@github.com>
 <bFRAxnko3ZgsOqdGLkA8ye-xZf72f7r7772RGgyf5yI=.2988eeef-9565-4b2d-859b-62cf1aedb8ab@github.com>
Message-ID: <OLhc2G3vDh7U5mXscVt9xBn2N7SmOxar_gljwgrMosY=.c15ff0b4-904d-41c3-bac4-8a440f59da25@github.com>

On Mon, 10 Mar 2025 18:18:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   align UnixPrintJob with PSPrinterJob
>
> test/jdk/javax/print/UnixPrintJobOptionsTest.java line 131:
> 
>> 129:             }
>> 130:         }
>> 131:         if (!success) {
> 
> Maybe it would be more robust to wrap everything in a try block with a finally to restore the printstream.

Yes, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1989490232

From aivanov at openjdk.org  Tue Mar 11 15:10:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 15:10:07 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v14]
In-Reply-To: <g5tI2I9IihEd9EKtnaGPRmka4K3IuNnW4QbgTRGv9Kk=.df52cb0c-b9b0-4757-b7e9-1ca7759005a8@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <g5tI2I9IihEd9EKtnaGPRmka4K3IuNnW4QbgTRGv9Kk=.df52cb0c-b9b0-4757-b7e9-1ca7759005a8@github.com>
Message-ID: <gspmM6LRVZV7FhtiOaC9HXk5m6ADQgWYkQ-7sDsicgA=.4151d409-7cc1-40f4-984e-66f2f1684fb2@github.com>

On Mon, 10 Mar 2025 23:22:36 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   builtIn converted to transient, tests updated

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1174:

> 1172:         if (builtIn) {
> 1173:             throw new IllegalArgumentException("Built-in profile"
> 1174:                                                + " cannot be modified");

Is it acceptable to overshoot 80-column limit for 6 characters without wrapping the line?

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 69:

> 67:                 throw new RuntimeException("Test Failed! IAE NOT thrown.");
> 68:             } catch (IllegalArgumentException iae) {
> 69:                 System.out.println("IAE expected: " + iae.getMessage());

I'm for keeping the previous version which verified the exception message???otherwise, how can we distinguish `IllegalArgumentException` for illegal arguments?

If we used another exception type, there wouldn't be the need to check on the message.

test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 41:

> 39:             ColorSpace.CS_CIEXYZ, "CS_CIEXYZ",
> 40:             ColorSpace.CS_LINEAR_RGB, "CS_LINEAR_RGB"
> 41:     ));

Suggestion:

    private static final Map<Integer, String> colorSpace = Map.of(
            ColorSpace.CS_sRGB, "CS_sRGB",
            ColorSpace.CS_PYCC, "CS_PYCC",
            ColorSpace.CS_GRAY, "CS_GRAY",
            ColorSpace.CS_CIEXYZ, "CS_CIEXYZ",
            ColorSpace.CS_LINEAR_RGB, "CS_LINEAR_RGB"
    );


Printing the `int` value of a color space could be enough, although a readable name is better.

test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 49:

> 47:             ICC_Profile profile = ICC_Profile.getInstance(builtInProfile.getData());
> 48:             try {
> 49:                 profile.setData(ICC_Profile.icSigCmykData, tagData);

Suggestion:

                profile.setData(ICC_Profile.icSigCmykData, null);

Should this be simplified?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2674550615
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989502914
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989287031
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989489808
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989491425

From duke at openjdk.org  Tue Mar 11 15:14:04 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 15:14:04 GMT
Subject: Integrated: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <k_Fo07yBcDWjQaVx8M-hu6RaoZ-DE1zHjXo4_PZblzw=.036d0461-a7e9-4b24-9cd3-ceb4da357745@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

This pull request has now been integrated.

Changeset: b957e5ed
Author:    Harald Eilertsen <haraldei at anduin.net>
URL:       https://git.openjdk.org/jdk/commit/b957e5ed1a8b77e01aad1bb574e4914131cdbfa6
Stats:     660 lines in 9 files changed: 9 ins; 0 del; 651 mod

8351322: Parameterize link option for pthreads

Reviewed-by: erikj, ihse, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23930

From achung at openjdk.org  Tue Mar 11 17:22:22 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Mar 2025 17:22:22 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v12]
In-Reply-To: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
Message-ID: <d2EbqpIVY17TLHtqEPj08Gj5wnJVfwFEgR3DqGnTbc8=.e6a9f29f-2d8d-461f-bec0-56f243ae58a5@github.com>

> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
> 
> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
> 
> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  use absolute distance to choose correct screen for offscreen clamping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22781/files
  - new: https://git.openjdk.org/jdk/pull/22781/files/5cd1e6a7..82044442

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=10-11

  Stats: 27 lines in 1 file changed: 6 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781

PR: https://git.openjdk.org/jdk/pull/22781

From honkar at openjdk.org  Tue Mar 11 17:47:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 17:47:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v13]
In-Reply-To: <zcvqJX27wXIUKFZAx9rtlebQrKkyfE3H8qQx6OpalPE=.4155d582-7d40-4952-bf31-574e354c254c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Nj8apuaYhxfUOU8cGqFFJ7I6m0Y5C3RWzfE2g2lAvv0=.da9544d9-8f8d-4d54-97b9-1a4dc5f6850f@github.com>
 <DtkRoB2uSz5iZptH0CU0rFM5ljFmHvp74YCZWYLH3Bk=.c8b68b57-7b14-4c5a-800e-c2741c6ff28d@github.com>
 <zcvqJX27wXIUKFZAx9rtlebQrKkyfE3H8qQx6OpalPE=.4155d582-7d40-4952-bf31-574e354c254c@github.com>
Message-ID: <GIDHOFPHDOKwTyH9V8eDnxERjovVXaD0oGDi7ZFXofg=.ea0e9dbb-ae64-4b0d-bc4d-734ee48ae87f@github.com>

On Mon, 10 Mar 2025 23:33:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 71:
>> 
>>> 69:             } catch (IllegalArgumentException iae) {
>>> 70:                 if (!iae.getMessage().equals(EXCEPTION_MSG)) {
>>> 71:                     throw new RuntimeException("Test Failed! IAE with exception msg \""
>> 
>> I don't think you need to - or should - expect a specific exception message.
>> Obviously you can update the test if the text changes, but I just don't think this is necessary.
>
> Updated.

Reverted based on @aivanov-jdk  suggestion - https://github.com/openjdk/jdk/pull/23606#discussion_r1989287031

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989837589

From honkar at openjdk.org  Tue Mar 11 17:47:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 17:47:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v15]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <iYx-DDlhQ5vvdzOzSlobrxlZcTEBH9S6hSx8VUVBL0o=.1b5c7d35-186d-4f63-8551-14b642aeeaf1@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/918cd67a..d0b7b9f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=13-14

  Stats: 12 lines in 3 files changed: 4 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Tue Mar 11 17:47:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 17:47:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v14]
In-Reply-To: <gspmM6LRVZV7FhtiOaC9HXk5m6ADQgWYkQ-7sDsicgA=.4151d409-7cc1-40f4-984e-66f2f1684fb2@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <g5tI2I9IihEd9EKtnaGPRmka4K3IuNnW4QbgTRGv9Kk=.df52cb0c-b9b0-4757-b7e9-1ca7759005a8@github.com>
 <gspmM6LRVZV7FhtiOaC9HXk5m6ADQgWYkQ-7sDsicgA=.4151d409-7cc1-40f4-984e-66f2f1684fb2@github.com>
Message-ID: <xRb4ECCQPM2vKidpr6_G9I_L1HVQ1qCDzef80nX9fKc=.686737f3-2b64-474d-96cf-04f5300cfbed@github.com>

On Tue, 11 Mar 2025 13:31:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   builtIn converted to transient, tests updated
>
> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 69:
> 
>> 67:                 throw new RuntimeException("Test Failed! IAE NOT thrown.");
>> 68:             } catch (IllegalArgumentException iae) {
>> 69:                 System.out.println("IAE expected: " + iae.getMessage());
> 
> I'm for keeping the previous version which verified the exception message???otherwise, how can we distinguish `IllegalArgumentException` for illegal arguments?
> 
> If we used another exception type, there wouldn't be the need to check on the message.

Reasonable point. Reverted the code to check the msg.
On the other hand, test controls the type of arguments (valid arguments) and profile we are sending in to `.setData()` and we know the expected IAE msg in this case is for built-in profile.

@prrace  I have reverted the test to check the type of exception msg to have a more strict check. IIRC, @jayathirthrao had made same suggestion as @aivanov-jdk for this newly added test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989836746

From aivanov at openjdk.org  Tue Mar 11 17:59:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 17:59:12 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v14]
In-Reply-To: <xRb4ECCQPM2vKidpr6_G9I_L1HVQ1qCDzef80nX9fKc=.686737f3-2b64-474d-96cf-04f5300cfbed@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <g5tI2I9IihEd9EKtnaGPRmka4K3IuNnW4QbgTRGv9Kk=.df52cb0c-b9b0-4757-b7e9-1ca7759005a8@github.com>
 <gspmM6LRVZV7FhtiOaC9HXk5m6ADQgWYkQ-7sDsicgA=.4151d409-7cc1-40f4-984e-66f2f1684fb2@github.com>
 <xRb4ECCQPM2vKidpr6_G9I_L1HVQ1qCDzef80nX9fKc=.686737f3-2b64-474d-96cf-04f5300cfbed@github.com>
Message-ID: <cMdZyQzlxrRM5seaMOrolrT1wOiFF5xrDLw1WjQHJrg=.17059683-890e-4969-bd12-fe2312c8e2a3@github.com>

On Tue, 11 Mar 2025 17:43:44 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> test controls the type of arguments (valid arguments)

Yes. And the arguments can change, although it's very unlikely.

The built-in check in the code is done before validating the arguments, therefore we know that whatever exception is thrown, it should be because of trying to modify a built-in profile.

Anyway, checking the exception message seems reasonable, and it ensures the test behaves the way we expect it to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1989854693

From duke at openjdk.org  Tue Mar 11 19:30:22 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:30:22 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
Message-ID: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>

Allows for future support for platforms that require different flags for libiconv support.

Sponsored-by: The FreeBSD Foundation

-------------

Commit messages:
 - 8351323: Parameterize libiconv compiler and linker flags

Changes: https://git.openjdk.org/jdk/pull/23995/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351323
  Stats: 37 lines in 5 files changed: 31 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23995/head:pull/23995

PR: https://git.openjdk.org/jdk/pull/23995

From erikj at openjdk.org  Tue Mar 11 19:37:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 19:37:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>

On Tue, 11 Mar 2025 19:22:34 GMT, snake66 <duke at openjdk.org> wrote:

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

I think this looks ok, but please wait for Magnus to have a look too.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2675894294

From duke at openjdk.org  Tue Mar 11 19:48:58 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:48:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
Message-ID: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>

On Tue, 11 Mar 2025 19:35:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> I think this looks ok, but please wait for Magnus to have a look too.

@erikj79 Thanks for the review. I'll wait for Magnus as well, and for the tests to pass :)

One thing I was wondering about is that with this change I think it should be safe to just use `$(ICONV_CFLAGS)` etc when setting the main variable.

I.e. instead of:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS), \
      CFLAGS_aix := $(ICONV_CFLAGS), \
      CFLAGS_macosx := $(ICONV_CFLAGS), \


We could just do:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
          $(ICONV_CFLAGS), \


The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.

However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2715520647

From aivanov at openjdk.org  Tue Mar 11 19:55:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 19:55:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v15]
In-Reply-To: <iYx-DDlhQ5vvdzOzSlobrxlZcTEBH9S6hSx8VUVBL0o=.1b5c7d35-186d-4f63-8551-14b642aeeaf1@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <iYx-DDlhQ5vvdzOzSlobrxlZcTEBH9S6hSx8VUVBL0o=.1b5c7d35-186d-4f63-8551-14b642aeeaf1@github.com>
Message-ID: <m04fNZGZ-BWJG4JLt7ZSjh8RUgpPfseL0o0hx7B22XY=.bafce9ec-165a-4681-a7ea-347f8d7c748f@github.com>

On Tue, 11 Mar 2025 17:47:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:

> 114:      * built-in profiles.
> 115:      */
> 116:     private transient final boolean builtIn;

Suggestion:

    private final transient boolean builtIn;

In [the ?blessed? modifier order](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)), `transient` follows `final`.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 783:

> 781:      * <p>
> 782:      * Note: {@code ProfileDeferralInfo} is used for only built-in profile
> 783:      * creation and all built-in profiles should be constructed using it.

Should we repeat the note in a comment for the `BuiltInProfile` interface or before the values?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2675909868
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990014882
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990017050

From aivanov at openjdk.org  Tue Mar 11 20:01:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 20:01:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
Message-ID: <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>

On Mon, 10 Mar 2025 18:47:17 GMT, Phil Race <prr at openjdk.org> wrote:

>>>Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
>> 
>> But it also has its own disadvantages...
>
> The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
> It just ensures that the JDK internally caches the original value for use in certain places.
> 
> Consider this program
> 
> public class jh {
>   public static void main(String[] args) {
>    String jhpstr = "java.home";
>    String jhp1 = System.getProperty(jhpstr);
>    System.setProperty(jhpstr, "foo");
>    String jhp2 = System.getProperty("java.home");
>    System.out.println(jhp1+" " +jhp2);
>   }
> } 
> % java jh
> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home foo

> There are two other exceptions that may be better suited that ISE in this case - [UnsupportedOperationException ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) and [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) but still IAE was chosen over them as it is existing and documented exception.

`UnsupportedOperationException` could be used.

`HeadlessException` extends `UnsupportedOperationException` and indicates a situation where a method cannot proceed because of the platform configuration.

`ProfileDataException` doesn't suit either because there's nothing wrong with the profile data in the case of built-in profiles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990040755

From honkar at openjdk.org  Tue Mar 11 21:08:42 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 21:08:42 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v16]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  modifier order changed, added comment to BuiltInProfile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/d0b7b9f7..afad8d3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=14-15

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From aivanov at openjdk.org  Tue Mar 11 21:14:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 21:14:02 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v16]
In-Reply-To: <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
Message-ID: <7oLnKqhtJdb6axLQd7CwmhBXIBbg5XyH6IWN5WrA1eY=.c31e9d2d-87d6-4fea-a3df-f2bf8b077ae9@github.com>

On Tue, 11 Mar 2025 21:08:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modifier order changed, added comment to BuiltInProfile

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 126:

> 124:         /*
> 125:          * Deferral is only used for standard profiles. Enabling the appropriate
> 126:          * access privileges is handled at a lower level.

I wonder if ?Enabling the appropriate access privileges is handled at a lower level? is still relevant after `SecurityManager` was removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990133673

From honkar at openjdk.org  Tue Mar 11 21:14:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 21:14:00 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v15]
In-Reply-To: <m04fNZGZ-BWJG4JLt7ZSjh8RUgpPfseL0o0hx7B22XY=.bafce9ec-165a-4681-a7ea-347f8d7c748f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <iYx-DDlhQ5vvdzOzSlobrxlZcTEBH9S6hSx8VUVBL0o=.1b5c7d35-186d-4f63-8551-14b642aeeaf1@github.com>
 <m04fNZGZ-BWJG4JLt7ZSjh8RUgpPfseL0o0hx7B22XY=.bafce9ec-165a-4681-a7ea-347f8d7c748f@github.com>
Message-ID: <uY9gqNAXHf2gHl2Bm3O-Dz8dCSZCFwuLsPjNf3N4TV0=.7a04d86e-b3b1-4c97-a9e0-28987572bc9f@github.com>

On Tue, 11 Mar 2025 19:42:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review changes
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:
> 
>> 114:      * built-in profiles.
>> 115:      */
>> 116:     private transient final boolean builtIn;
> 
> Suggestion:
> 
>     private final transient boolean builtIn;
> 
> In [the ?blessed? modifier order](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)), `transient` follows `final`.

Updated

> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 783:
> 
>> 781:      * <p>
>> 782:      * Note: {@code ProfileDeferralInfo} is used for only built-in profile
>> 783:      * creation and all built-in profiles should be constructed using it.
> 
> Should we repeat the note in a comment for the `BuiltInProfile` interface or before the values?

Good idea. Added the note near to the location of usage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990131146
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990130873

From duke at openjdk.org  Tue Mar 11 21:14:22 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Tue, 11 Mar 2025 21:14:22 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v5]
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <o_VXusqQHUQEBKZWUakLBvq3vyol5w7-kzga_TbrW0o=.a1c292a1-3e3c-4382-a62c-8fd70fe12291@github.com>

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:

  Edited years in copyright headers 2025 -> 2024, 2025

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23852/files
  - new: https://git.openjdk.org/jdk/pull/23852/files/f3294bd5..27fdef71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23852&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23852/head:pull/23852

PR: https://git.openjdk.org/jdk/pull/23852

From duke at openjdk.org  Tue Mar 11 21:14:22 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Tue, 11 Mar 2025 21:14:22 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <d31NrBMTChNJxGPLjar_RU0BRslBCbldnQ-88z9f9J8=.4994deaf-683d-4995-9296-1985f8a50640@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

Thanks for the review jerboaa, prrace.

@aivanov-jdk  thx, amended the headers

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2715712590

From aivanov at openjdk.org  Tue Mar 11 21:14:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 21:14:22 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v5]
In-Reply-To: <o_VXusqQHUQEBKZWUakLBvq3vyol5w7-kzga_TbrW0o=.a1c292a1-3e3c-4382-a62c-8fd70fe12291@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <o_VXusqQHUQEBKZWUakLBvq3vyol5w7-kzga_TbrW0o=.a1c292a1-3e3c-4382-a62c-8fd70fe12291@github.com>
Message-ID: <kiTIzeuHkEthDZzjDjRflLZL6eSjFQ3R7ubvKKzChmY=.fc4d8da7-02d9-47f7-acf7-81a6b409b1b8@github.com>

On Tue, 11 Mar 2025 21:11:04 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Edited years in copyright headers 2025 -> 2024, 2025

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23852#pullrequestreview-2676127108

From duke at openjdk.org  Tue Mar 11 21:14:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 21:14:22 GMT
Subject: RFR: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails
 on CI with Compilation error [v4]
In-Reply-To: <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
 <pt58NCuud2GtWMutloxiaxjtjSFZ3zA_Tt6bvreKd18=.420d58bc-703f-4d14-9157-764dffb9cc0a@github.com>
Message-ID: <X85nR656xeaOrIUYiYxTPhehUttMrqZPXOqf5A6I0z4=.78a00bc4-263a-49d4-9555-71abedf4419a@github.com>

On Fri, 7 Mar 2025 12:38:08 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

>> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
>> 
>> Test passes on Linux amd64 so far:
>> 
>> TIME=`date +%s`;
>> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
>> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
>> 
>> Test results: passed: 15
>
> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @library /test -> @library /test/lib

@Karm 
Your change (at version 27fdef71516ec5d040fa039a9f7711c5cb05c31e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23852#issuecomment-2715716925

From rmahajan at openjdk.org  Tue Mar 11 21:19:16 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 11 Mar 2025 21:19:16 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
Message-ID: <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>

On Tue, 11 Mar 2025 06:28:07 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
>> 
>> Testing done.
>
> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 1:
> 
>> 1: /*
> 
> Minor changes can be done
> 1. mainFrame = new JFrame("Bug 8033699 - `9` Tests for `Grouped / Non-Grouped` Radio Buttons");
> 2. Non group can be changed to non-group (For consistency across test)
> 3. Please limit to 80 cols wherever applicable 
> 
> Otherwise the changes look good. Verified test on macOS and it works as expected.

Should these be done as part of this change or a separate bug for refactoring /code cleanup of this test ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1990138506

From duke at openjdk.org  Tue Mar 11 21:19:13 2025
From: duke at openjdk.org (Karm Michal Babacek)
Date: Tue, 11 Mar 2025 21:19:13 GMT
Subject: Integrated: 8349099: java/awt/Headless/HeadlessMalfunctionTest.java
 fails on CI with Compilation error
In-Reply-To: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
References: <5CbDBTxpliQSqOle85ecMWccDowy2E9HbyW-uXJ-fMA=.a7f2fb31-8361-457d-a579-b2f785e9b149@github.com>
Message-ID: <wr8BtK2rMSlDpFvspjuQmxgCaRxjQnLLVhPdd0Xs5mw=.3c83fbde-ec9d-4626-916d-fa577ce53271@github.com>

On Sun, 2 Mar 2025 00:50:30 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:

> Removed objectweb.asm for bytecode manipulation and uses JEP 484 classfile API.
> 
> Test passes on Linux amd64 so far:
> 
> TIME=`date +%s`;
> mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; 
> jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/
> 
> Test results: passed: 15

This pull request has now been integrated.

Changeset: 1dd9cf10
Author:    Karm Michal Babacek <karm at redhat.com>
URL:       https://git.openjdk.org/jdk/commit/1dd9cf1018f33af34f1f822cb0d1dc706353bbdf
Stats:     46 lines in 3 files changed: 7 ins; 14 del; 25 mod

8349099: java/awt/Headless/HeadlessMalfunctionTest.java fails on CI with Compilation error

Reviewed-by: aivanov, sgehwolf, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23852

From aivanov at openjdk.org  Tue Mar 11 21:21:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 21:21:00 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v16]
In-Reply-To: <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
Message-ID: <XFqlwp_12WcV2_51pb0jmFec4ygJ_qT4hoN0ZIkIUjk=.4fee2432-6177-4b1b-919e-3d0de9b7234b@github.com>

On Tue, 11 Mar 2025 21:08:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modifier order changed, added comment to BuiltInProfile

Looks good to me.

I'm still for using a different exception type rather than `IllegalArgumentException`. The alternatives are `IllegalStateException` or `UnsupportedOperationException`.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2676136041

From honkar at openjdk.org  Tue Mar 11 21:21:01 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 21:21:01 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v16]
In-Reply-To: <7oLnKqhtJdb6axLQd7CwmhBXIBbg5XyH6IWN5WrA1eY=.c31e9d2d-87d6-4fea-a3df-f2bf8b077ae9@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
 <7oLnKqhtJdb6axLQd7CwmhBXIBbg5XyH6IWN5WrA1eY=.c31e9d2d-87d6-4fea-a3df-f2bf8b077ae9@github.com>
Message-ID: <3OOJ6CJW1oFwDBt60wDlfBBOYFjSIi8XJD_vzNP3Ocs=.4fa3f496-e7d9-4fcc-93e7-e4d672c10c9c@github.com>

On Tue, 11 Mar 2025 21:11:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modifier order changed, added comment to BuiltInProfile
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 126:
> 
>> 124:         /*
>> 125:          * Deferral is only used for standard profiles. Enabling the appropriate
>> 126:          * access privileges is handled at a lower level.
> 
> I wonder if ?Enabling the appropriate access privileges is handled at a lower level? is still relevant after `SecurityManager` was removed.

I missed reading it. Yes, you are right. I think it can be removed.

Also do we keep - `Deferral is only used for standard profiles` ? 
It may be redundant after adding the note?


         * ProfileDeferralInfo is used for only built-in profile creation and
         * all built-in profiles should be constructed using it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990138600

From aivanov at openjdk.org  Tue Mar 11 21:21:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Mar 2025 21:21:02 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v16]
In-Reply-To: <3OOJ6CJW1oFwDBt60wDlfBBOYFjSIi8XJD_vzNP3Ocs=.4fa3f496-e7d9-4fcc-93e7-e4d672c10c9c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <s0i-DmrGEp0L-OXuRE12FDGgbTPpFDXrMCOMkiNGcZg=.eda9e230-ace4-4bf3-b747-e502d864b3ea@github.com>
 <7oLnKqhtJdb6axLQd7CwmhBXIBbg5XyH6IWN5WrA1eY=.c31e9d2d-87d6-4fea-a3df-f2bf8b077ae9@github.com>
 <3OOJ6CJW1oFwDBt60wDlfBBOYFjSIi8XJD_vzNP3Ocs=.4fa3f496-e7d9-4fcc-93e7-e4d672c10c9c@github.com>
Message-ID: <FZduG3rtF_s8giFxR4DpI3aUMIbHKxkgIUUDoUBnmEk=.bb977ec9-94e8-48e0-a7b5-dd71d62ea1e6@github.com>

On Tue, 11 Mar 2025 21:16:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 126:
>> 
>>> 124:         /*
>>> 125:          * Deferral is only used for standard profiles. Enabling the appropriate
>>> 126:          * access privileges is handled at a lower level.
>> 
>> I wonder if ?Enabling the appropriate access privileges is handled at a lower level? is still relevant after `SecurityManager` was removed.
>
> I missed reading it. Yes, you are right. I think it can be removed.
> 
> Also do we keep - `Deferral is only used for standard profiles` ? 
> It may be redundant after adding the note?
> 
> 
>          * ProfileDeferralInfo is used for only built-in profile creation and
>          * all built-in profiles should be constructed using it.

The first sentence can also be removed. The newly added sentence repeats the first one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990141355

From honkar at openjdk.org  Tue Mar 11 21:26:23 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 21:26:23 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  redudant stmt removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/afad8d3b..bc5e9755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=15-16

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From duke at openjdk.org  Tue Mar 11 21:47:38 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 11 Mar 2025 21:47:38 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v6]
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <qt_Mj0-eaZ6PFhUIVRb1bvj_8IDDrNvMrfmsUoaIY24=.4fefc3b5-5d31-4ad3-b515-35898684c5fd@github.com>

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23884/files
  - new: https://git.openjdk.org/jdk/pull/23884/files/0bf592cc..b0a0b75e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23884&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23884/head:pull/23884

PR: https://git.openjdk.org/jdk/pull/23884

From honkar at openjdk.org  Tue Mar 11 22:02:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 22:02:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <Vg6mUISzr5rGxzgL35kmTuAE8qtyb5ypEHKErwRITTA=.189d2ddc-72d8-4203-bcfb-ade3662efa0d@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

Test update looks good to me.

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23814#pullrequestreview-2676208100

From honkar at openjdk.org  Tue Mar 11 22:13:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Mar 2025 22:13:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <-VpTIIutmIIh3baxOFDrIdfIBgDIRIr0-8QGcrU6A80=.713b71d9-97a8-414d-ae13-c4021cf35397@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

> It will consume a lot of resources loading and rendering the sound bank impacting background task that might fail because they do not have enough memory - and that's while we know upfront that we will not be able to finish with the rendering process.

I think @azuev-java has a valid point here. It might be better to check if enough memory is available upfront rather than end up with OOME later on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2715816369

From prr at openjdk.org  Tue Mar 11 22:45:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Mar 2025 22:45:55 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v8]
In-Reply-To: <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
Message-ID: <ldniVXYd-V_Z4TcNqpi-lJqVm49DS0tudUq1JfP5slo=.6b76010b-4a77-4f1d-bf06-8b8bb4201c41@github.com>

On Tue, 11 Mar 2025 14:48:12 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore original printstream

Marked as reviewed by prr (Reviewer).

test/jdk/javax/print/UnixPrintJobOptionsTest.java line 54:

> 52:  * @run main/manual/othervm -Dsun.print.ippdebug=true UnixPrintJobOptionsTest
> 53:  */
> 54: 

You also made the test manual, yet it has no user interaction. It ought to be enough that you tagged it as a printer test. I'll approve, but maybe it could be reverted to automated ??

I notice that it actually prints - although it is a blank page.
I suppose it has to, in order to get the command line to be used.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23457#pullrequestreview-2676283937
PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1990223608

From kizune at openjdk.org  Tue Mar 11 22:52:08 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 11 Mar 2025 22:52:08 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v8]
In-Reply-To: <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
Message-ID: <N4rfe2V2243kZ7pERVhGF0IgBf0UH9BAbJeWG56RCpA=.3ef4db5f-896a-4420-a880-ef7f0802867c@github.com>

On Tue, 11 Mar 2025 14:48:12 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore original printstream

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23457#pullrequestreview-2676297304

From dnguyen at openjdk.org  Tue Mar 11 22:55:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Mar 2025 22:55:31 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
 <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>
Message-ID: <QzRDrAVpk2tj5EunxOMDDScF1GEvB_BiAZnmmbiynkI=.68a8da51-02ea-440a-af99-b22b9974b9a8@github.com>

On Tue, 11 Mar 2025 21:15:55 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 1:
>> 
>>> 1: /*
>> 
>> Minor changes can be done
>> 1. mainFrame = new JFrame("Bug 8033699 - `9` Tests for `Grouped / Non-Grouped` Radio Buttons");
>> 2. Non group can be changed to non-group (For consistency across test)
>> 3. Please limit to 80 cols wherever applicable 
>> 
>> Otherwise the changes look good. Verified test on macOS and it works as expected.
>
> Should these be done as part of this change or a separate bug for refactoring /code cleanup of this test ?

I usually fix these when I touch the test anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1990232787

From dnguyen at openjdk.org  Tue Mar 11 22:55:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Mar 2025 22:55:31 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <WgRP4w8IQetTZyIEyVXwGf4Svdg31E_Nc1iqGgR3mPo=.932931cf-5ebf-43db-aaec-68e8420f4498@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

I also tested this and the test passes consistently on all LAFs.

test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 131:

> 129:             UIManager.setLookAndFeel(laf.getClassName());
> 130:         } catch (ClassNotFoundException | InstantiationException |
> 131:                  IllegalAccessException | UnsupportedLookAndFeelException e) {

This can just be set to `Exception e` rather than expanding it into separate exceptions.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23964#pullrequestreview-2676297061
PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1990230558

From psadhukhan at openjdk.org  Wed Mar 12 03:38:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Mar 2025 03:38:47 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v21]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <xD6TuOIOLNI3Gg_hjLGjskta3ipMiPN8x5mz2T6AhD8=.f17be7ff-baa5-46eb-88b9-4e6e8da2e0b3@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - Code duplication removed
 - Remove Windows L&F check from BasicMenuItemUI
 - Review comment fix
 - Test rename
 - Revert to non-CSR needed fix
 - Move windows specific change to windows folder
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - comment
 - Extend to Windows11 and later
 - ... and 15 more: https://git.openjdk.org/jdk/compare/48d3ebba...03a08727

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/b5a91f51..03a08727

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=19-20

  Stats: 75963 lines in 1498 files changed: 34914 ins; 28474 del; 12575 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Wed Mar 12 07:13:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Mar 2025 07:13:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v22]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <h411_SffKLLRxbpl4ibZIxkGUyVZdRsj6Qc7v-WC9zQ=.350ec839-8b41-4a13-a3e9-c94e68df9bb8@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/03a08727..381cdf52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=20-21

  Stats: 33 lines in 3 files changed: 2 ins; 25 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From duke at openjdk.org  Wed Mar 12 07:23:05 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Mar 2025 07:23:05 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v8]
In-Reply-To: <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <0ukc29REFabv1dBftyZyQp7z0nZVvezWCAD6JG--EpQ=.26dcfcd9-1194-48ed-82b4-b487b298ce6c@github.com>
Message-ID: <5trkJDIxMjUgbqjqx8bOzAG50WYSr8eGBt-5nxN5qiI=.3b2463c6-4e88-45e8-a62d-010a9c1d1436@github.com>

On Tue, 11 Mar 2025 14:48:12 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore original printstream

@GennadiyKrivoshein 
Your change (at version 4ff9384591b3229ba4190fcdda60d8a29da49e4b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23457#issuecomment-2716853274

From psadhukhan at openjdk.org  Wed Mar 12 07:43:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Mar 2025 07:43:17 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v23]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Expand wildcard imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/381cdf52..2ff5f03e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=21-22

  Stats: 40 lines in 1 file changed: 34 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From abhiscxk at openjdk.org  Wed Mar 12 10:44:59 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 12 Mar 2025 10:44:59 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v23]
In-Reply-To: <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>
Message-ID: <8pQuxq3aytxiqWNvy9Q-WU5uk6TJvKvg0MkXBj1SsOg=.e1ba85c0-bf61-4d64-8789-d28cf27ed5f4@github.com>

On Wed, 12 Mar 2025 07:43:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand wildcard imports

minor formatting changes.

Thank you removing the unneeded methods as we discussed.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 159:

> 157: 
> 158:     public static void applyInsets(Rectangle rect, Insets insets) {
> 159:         if(insets != null) {

Suggestion:

        if (insets != null) {

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 219:

> 217:             if (!model.isEnabled()) {
> 218: 
> 219:                 // *** paint the accText disabled

Suggestion:

                // paint the accText disabled

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 237:

> 235:             } else {
> 236: 
> 237:                 // *** paint the accText normally

Suggestion:

                // paint the accText normally

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 54:

> 52: 
> 53: 
> 54: import java.io.File;

unused import

-------------

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2677893179
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991164053
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991172598
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991174571
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991186609

From abhiscxk at openjdk.org  Wed Mar 12 10:49:03 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 12 Mar 2025 10:49:03 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v23]
In-Reply-To: <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>
Message-ID: <FnfJRR-gMLljqOpOHkS0yXCFuUrNDqe1O8KB9n_Z3sU=.18ddedb5-ad07-4794-bc67-aef5833c6f9f@github.com>

On Wed, 12 Mar 2025 07:43:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand wildcard imports

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 1:

> 1: /*

Please update copyright year

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991192881

From psadhukhan at openjdk.org  Wed Mar 12 11:00:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Mar 2025 11:00:30 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/2ff5f03e..e20cfc05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=22-23

  Stats: 7 lines in 3 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Wed Mar 12 11:00:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Mar 2025 11:00:30 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v23]
In-Reply-To: <8pQuxq3aytxiqWNvy9Q-WU5uk6TJvKvg0MkXBj1SsOg=.e1ba85c0-bf61-4d64-8789-d28cf27ed5f4@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <O0y0YdR7lT1IGis6EzU-G9KLU4L2guCmfdc6wVJ1rUo=.2e1183bf-c6d3-47ed-b6d3-0fdd67f93e2f@github.com>
 <8pQuxq3aytxiqWNvy9Q-WU5uk6TJvKvg0MkXBj1SsOg=.e1ba85c0-bf61-4d64-8789-d28cf27ed5f4@github.com>
Message-ID: <apDqTuTmXeQmdy0ThZbIq3AMpmhR5FAnlQcKxz096Gk=.0d90f55b-5788-4db5-80cc-d5eca6be78a5@github.com>

On Wed, 12 Mar 2025 10:41:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand wildcard imports
>
> test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 54:
> 
>> 52: 
>> 53: 
>> 54: import java.io.File;
> 
> unused import

removed..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1991216590

From abhiscxk at openjdk.org  Wed Mar 12 11:03:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 12 Mar 2025 11:03:56 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <7m5UaVbnq53giG_0j4fsExXYbQhBr9Ee_xNHL7_AllE=.cfd80d7c-018d-4a1d-a8f2-da77c6977edd@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

Tested on Windows 11 machine and current changes look good to me. 
![RadioCheckMenuItem_Win11](https://github.com/user-attachments/assets/aae4b5df-b1b3-497f-ac4a-e3f20aa39232)

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2677986364

From ihse at openjdk.org  Wed Mar 12 12:14:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:14:52 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
Message-ID: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>

On Tue, 11 Mar 2025 19:45:58 GMT, snake66 <duke at openjdk.org> wrote:

> We could just do:
> 
> ```
>       CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
>           $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
>           $(ICONV_CFLAGS), \
> ```
> 
> The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.
> 
> However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

This form is much preferred -- if it is possible and correct. That is, if iconv is used on all platforms where it is available.

>From the diff in the PR, it looks like iconv is used exclusively on macOS and AIX. If so, you can change the definition of ICONV_CFLAG etc to be empty on all platforms except on macOS and AIX (and in the upcoming BSD port), and just add the ICONV variables directly as platform neutral. 

But for this to be a good idea, there need to be some sense that this is "futureproof", as in that there will likely never be a need for iconv on Linux, and that there is a reasonable assumption to think that if a JDK library needs iconv it will need it on all "iconv platforms", that is macOS, AIX and BSD. I don't know enough about the specifics of iconv to say this with certainty. Another way to phrase this is perhaps: "why don't we need iconv on linux?"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717683240

From ihse at openjdk.org  Wed Mar 12 12:17:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:17:57 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
Message-ID: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>

On Wed, 12 Mar 2025 12:12:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Another way to phrase this is perhaps: "why don't we need iconv on linux?"

I googled this and can answer it myself: because `iconv()` is built into glibc. So then I guess it makes sense to add ICONV variables globally, and define it as empty on linux (and windows), where it is not needed to be specified as a separate library.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717689442

From duke at openjdk.org  Wed Mar 12 12:26:53 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 12:26:53 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
 <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
Message-ID: <GFAItR-gpg2wTrUmZJKQhnQ8nGioIhnMbmVgMOxE5_8=.c4e320d5-86f1-46ce-b5c2-464a5a67cf33@github.com>

On Wed, 12 Mar 2025 12:15:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Another way to phrase this is perhaps: "why don't we need iconv on linux?"
> 
> I googled this and can answer it myself: because `iconv()` is built into glibc. 

Yes, that's what I came to as well. Sorry I didn't include that info in the original description. It seems to be even more complicated on some platforms, where there _is_ built in support for iconv (or a system supplied libiconv), but with limitations so that you may want to prefer the GNU libiconv in any case.

I think we should be able to configure these cases properly also with the proposed changes.

I'll update the PR as outlined in the previous comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717713872

From duke at openjdk.org  Wed Mar 12 13:57:43 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 13:57:43 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

snake66 has updated the pull request incrementally with one additional commit since the last revision:

  Set ICONV_* flags for aix and macosx only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23995/files
  - new: https://git.openjdk.org/jdk/pull/23995/files/c9382788..d4c4cca5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=00-01

  Stats: 28 lines in 4 files changed: 2 ins; 11 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23995/head:pull/23995

PR: https://git.openjdk.org/jdk/pull/23995

From aivanov at openjdk.org  Wed Mar 12 14:09:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 14:09:04 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
Message-ID: <OtFqxOUjvEf0HinpAchHLExBhtMFRwXzEbWYtGH6vMo=.8d657ab4-a9c9-4fe1-8504-5be4117d4dd4@github.com>

On Tue, 11 Mar 2025 21:26:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   redudant stmt removed

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2678645266

From aivanov at openjdk.org  Wed Mar 12 14:10:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 14:10:13 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v6]
In-Reply-To: <qt_Mj0-eaZ6PFhUIVRb1bvj_8IDDrNvMrfmsUoaIY24=.4fefc3b5-5d31-4ad3-b515-35898684c5fd@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <qt_Mj0-eaZ6PFhUIVRb1bvj_8IDDrNvMrfmsUoaIY24=.4fefc3b5-5d31-4ad3-b515-35898684c5fd@github.com>
Message-ID: <K49plgYrDDKMxQ4586SN5i_tZWbgwZ50Zyxu6BaI0Fw=.6016e925-1d8f-43ee-9e0a-17e78aa072f1@github.com>

On Tue, 11 Mar 2025 21:47:38 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23884#pullrequestreview-2678650279

From mbaesken at openjdk.org  Wed Mar 12 14:57:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 14:57:29 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build
Message-ID: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>

Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
Reason is that pipewire updates can break the AIX build, so better avoid it if possible.

To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

-------------

Commit messages:
 - JDK-8351277

Changes: https://git.openjdk.org/jdk/pull/24009/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351277
  Stats: 23 lines in 3 files changed: 22 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24009/head:pull/24009

PR: https://git.openjdk.org/jdk/pull/24009

From ihse at openjdk.org  Wed Mar 12 16:58:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 16:58:55 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
Message-ID: <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>

On Wed, 12 Mar 2025 13:57:43 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set ICONV_* flags for aix and macosx only

Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? There is no reason to introduce a variable for completeness sake, if it is never going to have any value. But it is fully okay if they are empty now, but will have a value for BSD.

make/modules/jdk.jdwp.agent/Lib.gmk line 76:

> 74:         java.base:libjava, \
> 75:     JDK_LIBS := java.base:libjvm, \
> 76:     LIBS_linux := $(LIBDL), \

Something got wrong here. You should have kept the LIBS_linux line, and the new LIBS line should be `LIBS := $(ICONV_LIBS)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2718530308
PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1991917140

From rmahajan at openjdk.org  Wed Mar 12 17:17:05 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 12 Mar 2025 17:17:05 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <WgRP4w8IQetTZyIEyVXwGf4Svdg31E_Nc1iqGgR3mPo=.932931cf-5ebf-43db-aaec-68e8420f4498@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <WgRP4w8IQetTZyIEyVXwGf4Svdg31E_Nc1iqGgR3mPo=.932931cf-5ebf-43db-aaec-68e8420f4498@github.com>
Message-ID: <2e9wjH6grYR4SW-ukclh4GnCybTVU79br5wtlOk0Ins=.f785e153-c738-4991-b695-e21c04e0bf2f@github.com>

On Tue, 11 Mar 2025 22:49:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
>> 
>> Testing done.
>
> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 131:
> 
>> 129:             UIManager.setLookAndFeel(laf.getClassName());
>> 130:         } catch (ClassNotFoundException | InstantiationException |
>> 131:                  IllegalAccessException | UnsupportedLookAndFeelException e) {
> 
> This can just be set to `Exception e` rather than expanding it into separate exceptions.

This provides more targeted error messages and logging.
If you catch a broad Exception, you might inadvertently mask other unexpected errors that should be investigated.
Separate exception handlers make it easier to identify the root cause of an issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1991949772

From aivanov at openjdk.org  Wed Mar 12 17:49:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 17:49:08 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <QzRDrAVpk2tj5EunxOMDDScF1GEvB_BiAZnmmbiynkI=.68a8da51-02ea-440a-af99-b22b9974b9a8@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
 <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>
 <QzRDrAVpk2tj5EunxOMDDScF1GEvB_BiAZnmmbiynkI=.68a8da51-02ea-440a-af99-b22b9974b9a8@github.com>
Message-ID: <t5J3m2l6DN4uR7BLC1A-HfAe-V9mxHbFi4pswU6KAI8=.57b8ec08-1920-482e-8e17-1cfb3bbd7f00@github.com>

On Tue, 11 Mar 2025 22:52:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Should these be done as part of this change or a separate bug for refactoring /code cleanup of this test ?
>
> I usually fix these when I touch the test anyway.

> mainFrame = new JFrame("Bug 8033699 - 9 Tests for Grouped / Non-Grouped Radio Buttons");

Makes sense? However, a generic title would be good enough. Something like _?Radio button focus tests?_. The current title is too long, it doesn't fit in the title bar of the frame (at least on Windows), therefore I see no point in making it comprehensive and long.

> I usually fix these when I touch the test anyway.

In majority of cases, I do too. Yet I tend not to change lines that I don't touch. From this point of view, additional changes aren't necessary ? none of the lines that don't fit into 80-column limit aren't touched.

The problem I see with additional refactoring is that it adds noise to the code review and it makes it harder to understand what the real, important changes are.

Use *your common sense*.

> Please limit to 80 cols wherever applicable

This is not applied strictly? I'm for following the 80-column limit where it doesn't reduce the readability. Yet I'm for stronger enforcement of 100-column limit. There are quite a few lines which are longer than 100 columns. The culprit is `KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner()` which accounts for 70 characters.

I'd like to make it shorter, and the focus manager can be cached after the first usage. At the same time, I'm unsure doing so in this code review is reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992004341

From aivanov at openjdk.org  Wed Mar 12 17:49:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 17:49:08 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <t5J3m2l6DN4uR7BLC1A-HfAe-V9mxHbFi4pswU6KAI8=.57b8ec08-1920-482e-8e17-1cfb3bbd7f00@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
 <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>
 <QzRDrAVpk2tj5EunxOMDDScF1GEvB_BiAZnmmbiynkI=.68a8da51-02ea-440a-af99-b22b9974b9a8@github.com>
 <t5J3m2l6DN4uR7BLC1A-HfAe-V9mxHbFi4pswU6KAI8=.57b8ec08-1920-482e-8e17-1cfb3bbd7f00@github.com>
Message-ID: <-6wPIFXB_hmtLIVt1x1GCJJhI18QAPRfa9fHmeaU-VE=.df3078cc-29f0-4509-a973-2d27b0b5cf12@github.com>

On Wed, 12 Mar 2025 17:44:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I usually fix these when I touch the test anyway.
>
>> mainFrame = new JFrame("Bug 8033699 - 9 Tests for Grouped / Non-Grouped Radio Buttons");
> 
> Makes sense? However, a generic title would be good enough. Something like _?Radio button focus tests?_. The current title is too long, it doesn't fit in the title bar of the frame (at least on Windows), therefore I see no point in making it comprehensive and long.
> 
>> I usually fix these when I touch the test anyway.
> 
> In majority of cases, I do too. Yet I tend not to change lines that I don't touch. From this point of view, additional changes aren't necessary ? none of the lines that don't fit into 80-column limit aren't touched.
> 
> The problem I see with additional refactoring is that it adds noise to the code review and it makes it harder to understand what the real, important changes are.
> 
> Use *your common sense*.
> 
>> Please limit to 80 cols wherever applicable
> 
> This is not applied strictly? I'm for following the 80-column limit where it doesn't reduce the readability. Yet I'm for stronger enforcement of 100-column limit. There are quite a few lines which are longer than 100 columns. The culprit is `KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner()` which accounts for 70 characters.
> 
> I'd like to make it shorter, and the focus manager can be cached after the first usage. At the same time, I'm unsure doing so in this code review is reasonable.

In short, I'd rather avoid doing additional refactoring, except for changing the frame title if Rajat wants to, because _none of the lines that need updating are **not** touched by the current changes_.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992007599

From honkar at openjdk.org  Wed Mar 12 17:49:09 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Mar 2025 17:49:09 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <kNVukVdKny6A980lTDF27a0nh0hbdEcKTeHEvXomdVw=.48c81297-da4d-4ffd-9a6a-1bf601b811b0@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 121:

> 119:                 if (mainFrame != null) {
> 120:                     mainFrame.dispose();
> 121:                     mainFrame = null;

Assigning `mainFrame = null` is not required since we are disposing the frame at this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992003914

From aivanov at openjdk.org  Wed Mar 12 17:59:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 17:59:58 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <kNVukVdKny6A980lTDF27a0nh0hbdEcKTeHEvXomdVw=.48c81297-da4d-4ffd-9a6a-1bf601b811b0@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <kNVukVdKny6A980lTDF27a0nh0hbdEcKTeHEvXomdVw=.48c81297-da4d-4ffd-9a6a-1bf601b811b0@github.com>
Message-ID: <CIpOGHiEpBj1PliN2Ec4-Fo4pFVMQ4glBIoLmdmrto0=.1b8bdc73-c41f-4ed5-aaac-519971a1bb0d@github.com>

On Wed, 12 Mar 2025 17:44:14 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Assigning `mainFrame = null` is not required since we are disposing the frame at this point.

It's required here, because the loop is repeated, and setting `mainFrame` to `null` prevents access to a disposed frame? likely from disposing of the frame again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992025095

From aivanov at openjdk.org  Wed Mar 12 17:59:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 17:59:59 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <2e9wjH6grYR4SW-ukclh4GnCybTVU79br5wtlOk0Ins=.f785e153-c738-4991-b695-e21c04e0bf2f@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <WgRP4w8IQetTZyIEyVXwGf4Svdg31E_Nc1iqGgR3mPo=.932931cf-5ebf-43db-aaec-68e8420f4498@github.com>
 <2e9wjH6grYR4SW-ukclh4GnCybTVU79br5wtlOk0Ins=.f785e153-c738-4991-b695-e21c04e0bf2f@github.com>
Message-ID: <dvgH5WbCusmiJnDuRaHZ5ehE3kwPC4gmYd8tTuazY8o=.379158a7-ff1f-40f1-b391-06d464d0dca1@github.com>

On Wed, 12 Mar 2025 17:13:54 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 131:
>> 
>>> 129:             UIManager.setLookAndFeel(laf.getClassName());
>>> 130:         } catch (ClassNotFoundException | InstantiationException |
>>> 131:                  IllegalAccessException | UnsupportedLookAndFeelException e) {
>> 
>> This can just be set to `Exception e` rather than expanding it into separate exceptions.
>
> This provides more targeted error messages and logging.
> If you catch a broad Exception, you might inadvertently mask other unexpected errors that should be investigated.
> Separate exception handlers make it easier to identify the root cause of an issue.

I'm fine with separate types.

You re-throwing any of the exceptions wrapped into `RuntimeException`. From this point of view, a single `Exception` won't change anything: if an exception is thrown, it's caught and re-thrown. These four exceptions are the only checked exceptions that can be thrown, catching `Exception` will catch them either way.

Either way is fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992022959

From honkar at openjdk.org  Wed Mar 12 18:07:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Mar 2025 18:07:53 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <CIpOGHiEpBj1PliN2Ec4-Fo4pFVMQ4glBIoLmdmrto0=.1b8bdc73-c41f-4ed5-aaac-519971a1bb0d@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <kNVukVdKny6A980lTDF27a0nh0hbdEcKTeHEvXomdVw=.48c81297-da4d-4ffd-9a6a-1bf601b811b0@github.com>
 <CIpOGHiEpBj1PliN2Ec4-Fo4pFVMQ4glBIoLmdmrto0=.1b8bdc73-c41f-4ed5-aaac-519971a1bb0d@github.com>
Message-ID: <TEdOU2SRGtbLT3MHKiOW8uCbCf6hNReQpkPExUVENhk=.ef463657-daa6-4b9b-abb0-84e7ac40ffa2@github.com>

On Wed, 12 Mar 2025 17:56:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java line 121:
>> 
>>> 119:                 if (mainFrame != null) {
>>> 120:                     mainFrame.dispose();
>>> 121:                     mainFrame = null;
>> 
>> Assigning `mainFrame = null` is not required since we are disposing the frame at this point.
>
>> Assigning `mainFrame = null` is not required since we are disposing the frame at this point.
> 
> It's required here, because the loop is repeated, and setting `mainFrame` to `null` prevents access to a disposed frame? likely from disposing of the frame again.

Missed seeing the finally block is within the LaF loop. Looks fine then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992038099

From duke at openjdk.org  Wed Mar 12 18:15:05 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Mar 2025 18:15:05 GMT
Subject: RFR: 8351108: ImageIO.write(..) fails with exception when writing
 JPEG with IndexColorModel [v6]
In-Reply-To: <qt_Mj0-eaZ6PFhUIVRb1bvj_8IDDrNvMrfmsUoaIY24=.4fefc3b5-5d31-4ad3-b515-35898684c5fd@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
 <qt_Mj0-eaZ6PFhUIVRb1bvj_8IDDrNvMrfmsUoaIY24=.4fefc3b5-5d31-4ad3-b515-35898684c5fd@github.com>
Message-ID: <WFKV99-SUkODORqkuEj_VP3-7Jb-3r6JOjbxYIwu-qY=.729fff76-9b19-47af-bc9a-b9cdb5f4cb58@github.com>

On Tue, 11 Mar 2025 21:47:38 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/imageio/plugins/jpeg/JpegWriterWriteNonOpaqueIndexColorModelTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

@mickleness 
Your change (at version b0a0b75e16f239f7182b5b2923941c05529e8815) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23884#issuecomment-2718715619

From aivanov at openjdk.org  Wed Mar 12 18:19:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Mar 2025 18:19:04 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <XDMHm48SuROrMYewnVJYYwunBTeerB1mXOOWJF8TDxg=.887223e7-0334-47f2-9def-4d1b3f5fd88f@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

Looks good to me.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23964#pullrequestreview-2679460231

From duke at openjdk.org  Wed Mar 12 18:23:12 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 12 Mar 2025 18:23:12 GMT
Subject: RFR: 8351110: ImageIO.write for JPEG can write corrupt JPEG for
 certain thumbnail dimensions [v4]
In-Reply-To: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
References: <yLnpOXmJFeG2fWmOGaCU5vcAxRc4VCka5iInbGb9rOw=.aca3186a-3280-4fa7-8ad5-b215548748a8@github.com>
Message-ID: <ReXXIt2UQd8I6dHNBvyvIlh_WJ5-C_-7E-zXy28n6zs=.470df807-2a2c-4f44-9352-276dae313150@github.com>

> JPEG segments can only be 65535-bytes long. (The marker length is expressed as 2 bytes.) The problem in this ticket is that we were writing more than 65535 bytes to a segment, which later caused parsing errors when we tried to read the file back.
> 
> This includes 2 changes:
> 
> 1. We now clip the thumbnail width/height to fit within the available marker. We were already constraining the width & height to a max of 255. (Because the width & height are expressed as 1 byte.) So this new clipping is similar to something we were already doing, and we issue the same WARNING_THUMB_CLIPPED warning to the writer. (Does this require a CSR?)
> 
> 2. This adds a bounds check to `write2bytes`. IMO the bigger problem in this ticket was the `ImageIO.write(..)` caller thought they ended up with a valid JPEG. (We were violating the "do no harm / lose no data" doctrine.) Now if something like this ever comes up again: writing will fail with an IIOException. Technically you can argue this change is unnecessary because the new clipping avoids this error condition, but IMO including this safety net is an overall good thing to keep. If anyone disagrees I'm OK with removing it.
> 
> Separately:
> I included (and reversed) a commit in this branch that provides an alternate solution. That commit anticipates the overflow problem and switches to a JPEG-encoded thumbnail. From an end user perspective this "just works": they get a (slightly lossly) thumbnail of the original dimensions. But I assume it would be more controversial compared to the clipping approach, since the clipping approach has a strong precedent in this codebase.

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8351110: adding a few clarifying comments
 - 8351110: changing `catch` statement to support assertEquals's Error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23920/files
  - new: https://git.openjdk.org/jdk/pull/23920/files/5448bb2d..e16df900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23920&range=02-03

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23920/head:pull/23920

PR: https://git.openjdk.org/jdk/pull/23920

From honkar at openjdk.org  Wed Mar 12 18:49:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Mar 2025 18:49:54 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <BsXCzNkidWxzN1fLDMk5Dz9LHffKHtJLQFZPdVNft88=.d8b02ea4-1335-4acb-8c7f-47f96929e599@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

Marked as reviewed by honkar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23964#pullrequestreview-2679557502

From rmahajan at openjdk.org  Wed Mar 12 19:26:52 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 12 Mar 2025 19:26:52 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <-6wPIFXB_hmtLIVt1x1GCJJhI18QAPRfa9fHmeaU-VE=.df3078cc-29f0-4509-a973-2d27b0b5cf12@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
 <9mAjCZIVDXGZeY4m0kqc8Vu9n1hxWrBkOIzPSWTjCqo=.4040a130-9d52-490c-a8c3-262e12c38f02@github.com>
 <DMWcH7q-naGfl4TIXt-1EJMlm7ag7_7RaaYkhKuzKH8=.7bd3bdda-5330-43be-bc85-4ea8248dcf18@github.com>
 <QzRDrAVpk2tj5EunxOMDDScF1GEvB_BiAZnmmbiynkI=.68a8da51-02ea-440a-af99-b22b9974b9a8@github.com>
 <t5J3m2l6DN4uR7BLC1A-HfAe-V9mxHbFi4pswU6KAI8=.57b8ec08-1920-482e-8e17-1cfb3bbd7f00@github.com>
 <-6wPIFXB_hmtLIVt1x1GCJJhI18QAPRfa9fHmeaU-VE=.df3078cc-29f0-4509-a973-2d27b0b5cf12@github.com>
Message-ID: <WH73G42fLMSKh-wNW03ibCwvcvElAOj3teDuxQvEZ50=.13d43d84-83a5-49ac-8f16-1d83f02fbe41@github.com>

On Wed, 12 Mar 2025 17:46:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> mainFrame = new JFrame("Bug 8033699 - 9 Tests for Grouped / Non-Grouped Radio Buttons");
>> 
>> Makes sense? However, a generic title would be good enough. Something like _?Radio button focus tests?_. The current title is too long, it doesn't fit in the title bar of the frame (at least on Windows), therefore I see no point in making it comprehensive and long.
>> 
>>> I usually fix these when I touch the test anyway.
>> 
>> In majority of cases, I do too. Yet I tend not to change lines that I don't touch. From this point of view, additional changes aren't necessary ? none of the lines that don't fit into 80-column limit aren't touched.
>> 
>> The problem I see with additional refactoring is that it adds noise to the code review and it makes it harder to understand what the real, important changes are.
>> 
>> Use *your common sense*.
>> 
>>> Please limit to 80 cols wherever applicable
>> 
>> This is not applied strictly? I'm for following the 80-column limit where it doesn't reduce the readability. Yet I'm for stronger enforcement of 100-column limit. There are quite a few lines which are longer than 100 columns. The culprit is `KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner()` which accounts for 70 characters.
>> 
>> I'd like to make it shorter, and the focus manager can be cached after the first usage. At the same time, I'm unsure doing so in this code review is reasonable.
>
> In short, I'd rather avoid doing additional refactoring, except for changing the frame title if Rajat wants to, because _none of the lines that need updating are **not** touched by the current changes_.

I have filed a new bug to incorporate the suggestions here and re-factor test code separately - [JDK-8351884](https://bugs.openjdk.org/browse/JDK-8351884)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23964#discussion_r1992164170

From serb at openjdk.org  Wed Mar 12 19:29:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Mar 2025 19:29:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
Message-ID: <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>

On Tue, 11 Mar 2025 19:56:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
>> It just ensures that the JDK internally caches the original value for use in certain places.
>> 
>> Consider this program
>> 
>> public class jh {
>>   public static void main(String[] args) {
>>    String jhpstr = "java.home";
>>    String jhp1 = System.getProperty(jhpstr);
>>    System.setProperty(jhpstr, "foo");
>>    String jhp2 = System.getProperty("java.home");
>>    System.out.println(jhp1+" " +jhp2);
>>   }
>> } 
>> % java jh
>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home foo
>
>> There are two other exceptions that may be better suited that ISE in this case - [UnsupportedOperationException ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) and [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) but still IAE was chosen over them as it is existing and documented exception.
> 
> `UnsupportedOperationException` could be used.
> 
> `HeadlessException` extends `UnsupportedOperationException` and indicates a situation where a method cannot proceed because of the platform configuration.
> 
> `ProfileDataException` doesn't suit either because there's nothing wrong with the profile data in the case of built-in profiles.

> The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
> It just ensures that the JDK internally caches the original value for use in certain places.

Right. The application may attempt to change these java properties, but it won't affect the behavior of the JDK since the JDK internally will use the initially cached value of the property via StaticProperty.userDir()/userHome()/etc.

This is even specified similarly to what we want for color profiles.

>  * <strong>Changing a standard system property may have unpredictable results
     * unless otherwise specified.</strong>
     * Property values may be cached during initialization or on first use.
     * Setting a standard property after initialization using {@link #getProperties()},
     * {@link #setProperties(Properties)}, {@link #setProperty(String, String)}, or
     * {@link #clearProperty(String)} may not have the desired effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1992167456

From serb at openjdk.org  Wed Mar 12 19:33:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Mar 2025 19:33:06 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
Message-ID: <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>

On Wed, 12 Mar 2025 19:27:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> There are two other exceptions that may be better suited that ISE in this case - [UnsupportedOperationException ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) and [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) but still IAE was chosen over them as it is existing and documented exception.
>> 
>> `UnsupportedOperationException` could be used.
>> 
>> `HeadlessException` extends `UnsupportedOperationException` and indicates a situation where a method cannot proceed because of the platform configuration.
>> 
>> `ProfileDataException` doesn't suit either because there's nothing wrong with the profile data in the case of built-in profiles.
>
>> The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
>> It just ensures that the JDK internally caches the original value for use in certain places.
> 
> Right. The application may attempt to change these java properties, but it won't affect the behavior of the JDK since the JDK internally will use the initially cached value of the property via StaticProperty.userDir()/userHome()/etc.
> 
> This is even specified similarly to what we want for color profiles.
> 
>>  * <strong>Changing a standard system property may have unpredictable results
>      * unless otherwise specified.</strong>
>      * Property values may be cached during initialization or on first use.
>      * Setting a standard property after initialization using {@link #getProperties()},
>      * {@link #setProperties(Properties)}, {@link #setProperty(String, String)}, or
>      * {@link #clearProperty(String)} may not have the desired effect.

* Builtin color profiles may be cached during initialization or on first use. Changing a standard profiles after initialization using ICC_Profile.setData may not have the desired effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1992171181

From honkar at openjdk.org  Wed Mar 12 21:11:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Mar 2025 21:11:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
 <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
Message-ID: <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>

On Wed, 12 Mar 2025 19:30:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> The System Properties case isn't something I'd want to follow. It doesn't really make them read-only.
>>> It just ensures that the JDK internally caches the original value for use in certain places.
>> 
>> Right. The application may attempt to change these java properties, but it won't affect the behavior of the JDK since the JDK internally will use the initially cached value of the property via StaticProperty.userDir()/userHome()/etc.
>> 
>> This is even specified similarly to what we want for color profiles.
>> 
>>>  * <strong>Changing a standard system property may have unpredictable results
>>      * unless otherwise specified.</strong>
>>      * Property values may be cached during initialization or on first use.
>>      * Setting a standard property after initialization using {@link #getProperties()},
>>      * {@link #setProperties(Properties)}, {@link #setProperty(String, String)}, or
>>      * {@link #clearProperty(String)} may not have the desired effect.
>
> * Builtin color profiles may be cached during initialization or on first use. Changing a standard profiles after initialization using ICC_Profile.setData may not have the desired effect.

> > Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
> 
> But it also has its own disadvantages...

@mrserb  You mentioned earlier that there are disadvantages of using java properties approach, so using builtIn flag would be better then, correct?

>  I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps.

I wasn't able to find the previous discussion thread so I'm not sure what are the disadvantages. Can you please explain?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1992295739

From psadhukhan at openjdk.org  Thu Mar 13 03:07:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Mar 2025 03:07:55 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <3ANRlYjGqwwDC80Pd96LsOK1tD5BNBH15PaXCcW8iaY=.e84fe5ec-77b8-417f-9fda-519acc086788@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>
 <wV_NxwKTx6OjwmcxAtIcUFp1rDgBaw3jr-Vu85MdO_s=.aaafe7f7-05c8-417b-b161-475fcbb490f6@github.com>
 <3ANRlYjGqwwDC80Pd96LsOK1tD5BNBH15PaXCcW8iaY=.e84fe5ec-77b8-417f-9fda-519acc086788@github.com>
Message-ID: <plLY2XsmWy50HGIE6-MAjjbdQZQ-Zr9Stkn2qJm_o5k=.10d18067-36aa-42d9-87a4-2bcd7d55ac3a@github.com>

On Mon, 10 Mar 2025 13:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > FWIW the current fix isn't what I'd like to see.
> > > > Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??
> > > 
> > > 
> > > Since the Windows L&F check in Basic*UI class is a bone of contention, I have removed it and put the code in Windows specific class although there's around 200+ lines of code duplication as most of the required helper methods in BasicMenuItemUI class has private access.. CI run in windows is ok..
> > 
> > 
> > Can we move these helper methods into a utility class which has public access to both `Basic*UI` and `Windows*UI`? `SwingUtilities3`, or a new class?
> 
> OK..Moved..PR updated

Guess I have taken care of the problematic windows L&F check in Basic class and reduced the code duplication..
Any more comments @aivanov-jdk @prrace ? 

Wanted to get it in before test sprint if possible..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2719710156

From tr at openjdk.org  Thu Mar 13 05:15:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 13 Mar 2025 05:15:54 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
Message-ID: <wATY1kx5ljRL3VWMaLa2dK_byThHnrnlFJqoxQtKrdE=.6ddd3c43-1d35-4ad6-b42b-f4beb202f069@github.com>

On Wed, 5 Mar 2025 23:07:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
>> 
>> No open tests needed to be updated to accommodate this removal 
>> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
>> 
>> There will be a CSR (and probably a release note too).
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319192

LGTM

-------------

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23909#pullrequestreview-2680576854

From psadhukhan at openjdk.org  Thu Mar 13 05:23:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Mar 2025 05:23:54 GMT
Subject: RFR: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <8BQ1rrmkKI7ka2ZgLQNDHeTLHyg-uPQsxTIupgRIVm8=.89ad2936-b9c4-4874-9de4-8407b89452ac@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
 <uQuZybXMc_HcOlrNQh5AwTVwLB19mv_KoXIiIgJc0hQ=.b6fc4856-1706-4b1d-a97f-e3c9d70e586c@github.com>
 <DDihzSGwDeQ3A0j3HGcFqLxtV_53BlpNNWtXr4l6_Bk=.ecce5292-e9c7-4701-b051-2724b51bb546@github.com>
 <8BQ1rrmkKI7ka2ZgLQNDHeTLHyg-uPQsxTIupgRIVm8=.89ad2936-b9c4-4874-9de4-8407b89452ac@github.com>
Message-ID: <WMJdHMVjWpKhQpGB3N5cV_DMDyjitHI3Xupo3NbKSS8=.7157114b-d377-48bd-8aa7-9fc7bcdfd3bb@github.com>

On Thu, 6 Mar 2025 20:36:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java line 38:
>> 
>>> 36: import java.io.InputStream;
>>> 37: import java.net.URL;
>>> 38: import java.net.URLClassLoader;
>> 
>> Is URLClassLoader no longer used?
>
> seems so. I'll remove it.

URLCLassLoader still not removed it seems..I dont see its usage in the file..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23909#discussion_r1992807148

From psadhukhan at openjdk.org  Thu Mar 13 08:22:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Mar 2025 08:22:30 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling
Message-ID: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>

JTable.selectAll doesn't do anything if there are no rows or no columns. 
But it should still select all columns if there are no rows and the other way round. 
It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.

Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

-------------

Commit messages:
 - 4466930: JTable.selectAll boundary handling

Changes: https://git.openjdk.org/jdk/pull/24025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4466930
  Stats: 103 lines in 2 files changed: 98 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From ihse at openjdk.org  Thu Mar 13 09:31:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 13 Mar 2025 09:31:57 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build
In-Reply-To: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
Message-ID: <Dik9j8vcnWcHeil8vX6eMNJwnmA8I_JAUQsMKsEIyII=.fc2bfcc7-5a37-4c82-b41c-7a408f835067@github.com>

On Wed, 12 Mar 2025 14:52:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
> 
> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

Can you include a revert of JDK-8349751, which is not needed anymore after this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2720571221

From duke at openjdk.org  Thu Mar 13 10:02:59 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 10:02:59 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
 <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>
Message-ID: <ZIzL7K2Zb4GQwvZzIql_t3veZiQQHluz2shWq2MyL1c=.61f01918-d603-4a7d-8c34-bfd5aef7bb19@github.com>

On Wed, 12 Mar 2025 16:56:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? 

Yes, the current BSD port has the following in `libraries.m4`:

  if test "x$OPENJDK_TARGET_OS" = "xbsd"; then
    if test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.openbsd"; then
      ICONV_CFLAGS="-I/usr/local/include"
      ICONV_LDFLAGS="-L/usr/local/lib"
      ICONV_LIBS=-liconv
    elif test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.freebsd"; then
      ICONV_CFLAGS=-DLIBICONV_PLUG
      ICONV_LDFLAGS=
      ICONV_LIBS=
    else
      ICONV_CFLAGS=
      ICONV_LDFLAGS=
      ICONV_LIBS=
    fi
  else
    ICONV_CFLAGS=
    ICONV_LDFLAGS=
    ICONV_LIBS=-liconv
  fi

  AC_SUBST(ICONV_CFLAGS)
  AC_SUBST(ICONV_LDFLAGS)
  AC_SUBST(ICONV_LIBS)


So strictly speaking we only need `ICONV_CFLAGS` for FreeBSD, and `ICONV_LIBS` for aix and macosx. That is if we don't want to include OpenBSD support at this time.

> make/modules/jdk.jdwp.agent/Lib.gmk line 76:
> 
>> 74:         java.base:libjava, \
>> 75:     JDK_LIBS := java.base:libjvm, \
>> 76:     LIBS_linux := $(LIBDL), \
> 
> Something got wrong here. You should have kept the LIBS_linux line, and the new LIBS line should be `LIBS := $(ICONV_LIBS)`.

Ooops, I'll fix!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2720660907
PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1993169985

From duke at openjdk.org  Thu Mar 13 10:12:09 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 13 Mar 2025 10:12:09 GMT
Subject: Integrated: 8351108: ImageIO.write(..) fails with exception when
 writing JPEG with IndexColorModel
In-Reply-To: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
References: <9Ndvun3BlY3BQr1AOEkl2P2KxmFUEEMlqb-uSFcTaIU=.b63bd54c-7378-476f-adfe-3252062b78f7@github.com>
Message-ID: <WUvohp-dLCxu9EoYiAiTvn92j0mbYb809YJpwvRx46I=.41bf058f-4133-4b83-98c2-f8872e3bf40a@github.com>

On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
> 
> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
> 
> Instead:
> Now the ImageTypeSpecifier accurately describes the given BufferedImage.

This pull request has now been integrated.

Changeset: c18494d3
Author:    Jeremy Wood <mickleness at gmail.com>
URL:       https://git.openjdk.org/jdk/commit/c18494d3c9eebd9d97d95fbca712d59ccab2f124
Stats:     89 lines in 2 files changed: 87 ins; 0 del; 2 mod

8351108: ImageIO.write(..) fails with exception when writing JPEG with IndexColorModel

Reviewed-by: aivanov, prr, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/23884

From duke at openjdk.org  Thu Mar 13 11:39:14 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 11:39:14 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

snake66 has updated the pull request incrementally with one additional commit since the last revision:

  Unbreak libjdwp build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23995/files
  - new: https://git.openjdk.org/jdk/pull/23995/files/d4c4cca5..a9fdfef5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23995/head:pull/23995

PR: https://git.openjdk.org/jdk/pull/23995

From dgredler at openjdk.org  Thu Mar 13 12:01:58 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 13 Mar 2025 12:01:58 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <7fqKqfq0n5oyHNlT7EA7s9CJqLslvQ77YJUEI3vDdh4=.d2989738-fb46-431a-9c4c-5f3df8132a12@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

This PR is ready to be sponsored. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2721013612

From mbaesken at openjdk.org  Thu Mar 13 13:06:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 13:06:38 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
Message-ID: <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>

> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
> 
> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove AIX special handling from endian.h

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24009/files
  - new: https://git.openjdk.org/jdk/pull/24009/files/84740c96..e7941d37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24009/head:pull/24009

PR: https://git.openjdk.org/jdk/pull/24009

From ihse at openjdk.org  Thu Mar 13 13:06:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 13 Mar 2025 13:06:38 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
Message-ID: <aggXAprdH1ZydFX_oP6Jfp8VkDqTt2DC8OGTN7qfz2A=.c5d5e40a-48a0-48a9-a4bc-5d4a4f0ea786@github.com>

On Thu, 13 Mar 2025 13:03:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove AIX special handling from endian.h

This looks good to me.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2681818338

From mbaesken at openjdk.org  Thu Mar 13 13:06:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 13:06:39 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build
In-Reply-To: <Dik9j8vcnWcHeil8vX6eMNJwnmA8I_JAUQsMKsEIyII=.fc2bfcc7-5a37-4c82-b41c-7a408f835067@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <Dik9j8vcnWcHeil8vX6eMNJwnmA8I_JAUQsMKsEIyII=.fc2bfcc7-5a37-4c82-b41c-7a408f835067@github.com>
Message-ID: <g7uut2ZWBVnlBeDz4Sf2OBalw2K8hu-1Rx4wICGiBAU=.17cae4f1-6954-40ff-a591-582ab6ff67dd@github.com>

On Thu, 13 Mar 2025 09:29:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Can you include a revert of JDK-8349751, which is not needed anymore after this change?

Okay I removed the AIX code from endian.h .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2721177888

From ihse at openjdk.org  Thu Mar 13 13:31:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 13 Mar 2025 13:31:59 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
Message-ID: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>

On Thu, 13 Mar 2025 11:39:14 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unbreak libjdwp build

This looks good to me now.

Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2681916914
PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721263178

From duke at openjdk.org  Thu Mar 13 13:57:10 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 13:57:10 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
 <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>
Message-ID: <m1qZbz8m7JXwV475ZdqpyQjdr09P1ixMXWoBy3jHBkI=.9e6ebf20-7212-41b3-b909-1460982beab9@github.com>

On Thu, 13 Mar 2025 13:28:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> snake66 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unbreak libjdwp build
>
> Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it.

@magicus @erikj79 Thanks for the reviews and help!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721341294

From duke at openjdk.org  Thu Mar 13 13:57:12 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Mar 2025 13:57:12 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
Message-ID: <YYtIQEdikZ7ydFkm6anwQ1-vjxgXcBjuxbWEoapQapo=.bc49eb75-4e82-49bf-bce3-be3c5f7a0a7e@github.com>

On Thu, 13 Mar 2025 11:39:14 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unbreak libjdwp build

@snake66 
Your change (at version a9fdfef5f18c63deebd64f37825b8b733997c588) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721348961

From honkar at openjdk.org  Thu Mar 13 15:52:20 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Mar 2025 15:52:20 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47
Message-ID: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>

Upgraded Libpng to v1.6.47

-------------

Commit messages:
 - unused-function added for gcc
 - libpng upgrade

Changes: https://git.openjdk.org/jdk/pull/24021/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348598
  Stats: 4982 lines in 23 files changed: 1913 ins; 2285 del; 784 mod
  Patch: https://git.openjdk.org/jdk/pull/24021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021

PR: https://git.openjdk.org/jdk/pull/24021

From honkar at openjdk.org  Thu Mar 13 15:52:20 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Mar 2025 15:52:20 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47
In-Reply-To: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
Message-ID: <H0YFSzbS2q8XYstudVf2lWGxBaSCKF4MHKJcDd-tsGg=.61897818-de16-4514-a927-ac073c945f0a@github.com>

On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Upgraded Libpng to v1.6.47

make/modules/java.desktop/lib/ClientLibraries.gmk line 249:

> 247:       DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \
> 248:       DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \
> 249:       DISABLED_WARNINGS_clang_png.c := unused-function, \

This warning was disabled to fix the following build issue on linux and macOS.


open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function]
[2025-03-12T23:57:44,575Z]  1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name,
[2025-03-12T23:57:44,575Z]       | ^~~~~~~~~~~~~~~~~~~~~

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1993813117

From azvegint at openjdk.org  Thu Mar 13 16:31:19 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 13 Mar 2025 16:31:19 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <vVeHGgTDZR2GgosI-c2dAopuaTwiY6ujXA658I9SHGM=.49d0f9dd-4e54-4168-9b31-f9a89901cce3@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <vVeHGgTDZR2GgosI-c2dAopuaTwiY6ujXA658I9SHGM=.49d0f9dd-4e54-4168-9b31-f9a89901cce3@github.com>
Message-ID: <QGkiw4yMvqS3AgLkxjGiPgvdazNkjdlRkV6kjWOP7Ns=.b4fa221a-bee3-4cf7-81b5-e032d24b4e00@github.com>

On Mon, 3 Feb 2025 17:22:19 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - helper function
>>  - grab screen data on mouseMove
>
> src/java.desktop/share/classes/java/awt/Robot.java line 258:
> 
>> 256: 
>> 257:         if (leastXDiff > leastYDiff) {
>> 258:             peer.mouseMove(finX2, finY2);
> 
> Let's say I have the following display configuration on Linux. Since it uses Xinerama, it shares the same coordinate system. 
> 
> java.awt.Rectangle[x=0,y=0,width=3440,height=1440]
> java.awt.Rectangle[x=3440,y=0,width=1440,height=2560]
> 
> ![image](https://github.com/user-attachments/assets/1953442c-fa18-49a0-99eb-b633152d83f6)
> 
> When I try to move the mouse to `x=20000,y=200`, I see that it clamps to `x=3439,y=200` (a point between 2 screens), while before it was `x=4879,y=200`(a rightmost point).
> 
> The old behavior seems more logical to me.

Here are a few cases where it still seems to fail after the update:


Title: secondary above the primary
Cmd: xrandr --output DP-0 --primary --pos 0x1440 --rotate normal --preferred --output DP-2 --pos 0x0 --rotate normal --preferred

screen #0 java.awt.Rectangle[x=0,y=1440,width=3440,height=1440]
screen #1 java.awt.Rectangle[x=0,y=0,width=2560,height=1440]



x  20000 y    200 [moving to]
- x   2559 y    200 [actual location] # before fix
+ x   3439 y   1440 [actual location] # after fix


---


Title: primary above the secondary, right side aligned
Cmd: xrandr --output DP-0 --primary --pos 0x0 --rotate normal --preferred --output DP-2 --pos 880x1440 --rotate normal --preferred

screen #0 java.awt.Rectangle[x=0,y=0,width=3440,height=1440]
screen #1 java.awt.Rectangle[x=880,y=1440,width=2560,height=1440]



x    200 y  20000 [moving to]
- x    200 y   1439 [actual location]
+ x    880 y   2879 [actual location]


---


Title: secondary above the primary, right side aligned
Cmd: xrandr --output DP-0 --primary --pos 0x1440 --rotate normal --preferred --output DP-2 --pos 880x0 --rotate normal --preferred

screen #0 java.awt.Rectangle[x=0,y=1440,width=3440,height=1440]
screen #1 java.awt.Rectangle[x=880,y=0,width=2560,height=1440]



x -20000 y    200 [moving to]
- x    880 y    200 [actual location]
+ x      0 y   1440 [actual location]

x    200 y -20000 [moving to]
- x    200 y   1440 [actual location]
+ x    880 y      0 [actual location]

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1993898584

From duke at openjdk.org  Thu Mar 13 16:42:08 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Mar 2025 16:42:08 GMT
Subject: RFR: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <BPnDUaLDmiZ7xitlzWeJ8EZGePzicfgaC1gUyf-p6LE=.c3090720-d123-4eb2-a5a6-ce8e0090a328@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

@rajamah 
Your change (at version 65d95acf8d92dd46aa6ded1aaa4c3db5f66969a7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23964#issuecomment-2721931346

From erikj at openjdk.org  Thu Mar 13 16:57:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 13 Mar 2025 16:57:53 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47
In-Reply-To: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
Message-ID: <ArnfQF17Ltdy0TZmtQcZxW6cFSdpE39AdVo1jAOllRQ=.e3f125d8-d571-40a3-9675-0f40e1564dfe@github.com>

On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Upgraded Libpng to v1.6.47

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2682753294

From duke at openjdk.org  Thu Mar 13 16:58:03 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 16:58:03 GMT
Subject: Integrated: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <vdsWfr8gf1ZwPbul1FP0D2i8GKXAgkm7ejAy-QEvJr0=.249a439e-28ec-4827-80f8-80cefe67d93e@github.com>

On Tue, 11 Mar 2025 19:22:34 GMT, snake66 <duke at openjdk.org> wrote:

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

This pull request has now been integrated.

Changeset: 771e160d
Author:    Harald Eilertsen <haraldei at anduin.net>
URL:       https://git.openjdk.org/jdk/commit/771e160da4daa98bfe37bf1acba65454c088910c
Stats:     35 lines in 5 files changed: 25 ins; 2 del; 8 mod

8351323: Parameterize compiler and linker flags for iconv

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/23995

From rmahajan at openjdk.org  Thu Mar 13 17:12:05 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 13 Mar 2025 17:12:05 GMT
Subject: Integrated: 8280818: Expand bug8033699.java to iterate over all LaFs
In-Reply-To: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
References: <1Uyv-Zrp78wGQQgRq6EiAcsbzwG5YntMMGtIPTJawF4=.7e4c2316-86aa-4e85-81f8-55184c863a81@github.com>
Message-ID: <hXiyAe25t79KLMqUn1bj9f36ebhma5u98HcilG9sgMo=.51988c80-d00a-45eb-97cd-935bc1b5f7b0@github.com>

On Mon, 10 Mar 2025 14:48:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Added code to Iterates over all installed Look and Feel environments and added related exception handling.
> 
> Testing done.

This pull request has now been integrated.

Changeset: b50fe9b8
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b50fe9b8cc39730d3339e45a83b365ab3dd8a5da
Stats:     110 lines in 1 file changed: 56 ins; 40 del; 14 mod

8280818: Expand bug8033699.java to iterate over all LaFs

Reviewed-by: dnguyen, aivanov, honkar, abhiscxk

-------------

PR: https://git.openjdk.org/jdk/pull/23964

From honkar at openjdk.org  Thu Mar 13 17:24:43 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Mar 2025 17:24:43 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v2]
In-Reply-To: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
Message-ID: <5sGdMzQPXGXVMAIUeBZ9wLwKKRC6iDKNqzG4A48Osyo=.593739b1-42ee-47b2-b8df-2638743e1bc6@github.com>

> Upgraded Libpng to v1.6.47

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  header update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24021/files
  - new: https://git.openjdk.org/jdk/pull/24021/files/b8f10b8d..e1954bcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021

PR: https://git.openjdk.org/jdk/pull/24021

From honkar at openjdk.org  Thu Mar 13 17:30:33 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Mar 2025 17:30:33 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
Message-ID: <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>

> Upgraded Libpng to v1.6.47

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  header update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24021/files
  - new: https://git.openjdk.org/jdk/pull/24021/files/e1954bcb..2f0cea2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=01-02

  Stats: 82 lines in 16 files changed: 80 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021

PR: https://git.openjdk.org/jdk/pull/24021

From azvegint at openjdk.org  Thu Mar 13 18:59:52 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 13 Mar 2025 18:59:52 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>
Message-ID: <vB6qwCIoHMpHicO0QHk2OOc6QHf-PNnWZaCyBkh_7ls=.4737a2b3-bcb0-49f2-8f6b-308f1e92d79c@github.com>

On Thu, 13 Mar 2025 17:30:33 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Upgraded Libpng to v1.6.47
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   header update

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2683085368

From prr at openjdk.org  Thu Mar 13 19:54:57 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Mar 2025 19:54:57 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>
Message-ID: <LmE7YMXfGkWhHk5niW5xXgzGEnMfCVDsZ3xtsxrv1Lk=.ffd64dad-2979-4933-a814-ffcefda8fd06@github.com>

On Thu, 13 Mar 2025 17:30:33 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Upgraded Libpng to v1.6.47
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   header update

I was surprised by how many changes there are.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2683217837

From prr at openjdk.org  Thu Mar 13 20:02:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Mar 2025 20:02:53 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
Message-ID: <e8ANxGxl7Ig9p4jSFR7TYj1cUEU1Cr3hMj2-PndvHfQ=.300452c8-8e61-40d4-8a24-c921e3c57db5@github.com>

On Thu, 13 Mar 2025 13:06:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove AIX special handling from endian.h

Looks right to me, but I will do a test build.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2683234993

From prr at openjdk.org  Thu Mar 13 20:16:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Mar 2025 20:16:00 GMT
Subject: Integrated: 8319192: Remove
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
References: <6aV9AIyXMSFQUSCa0KRMzFhryw6_LkEsXzQDJCIAUU8=.fa806d96-49de-4248-96b2-812fa6af893b@github.com>
Message-ID: <ThMfSLQ0gbK4L5s-cPlXnf6e_DpTK5Vy48N6MAQCx3Q=.962e2467-5677-46bd-bd24-c41eecb801cb@github.com>

On Tue, 4 Mar 2025 23:41:36 GMT, Phil Race <prr at openjdk.org> wrote:

> Back in JDK 21 we deprecated-for-removal SynthLookAndFeel.load(URL) and targeted it to be removed under this bug ID in JDK 25 .. which is now here.
> 
> No open tests needed to be updated to accommodate this removal 
> I did find one closed manual test, written to explicitly test this API back when it was added, and I'll need to remove that, but it doesn't affect this PR.
> 
> There will be a CSR (and probably a release note too).

This pull request has now been integrated.

Changeset: aa047ee0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa047ee02472c65297cc8a153458e634c5e4f350
Stats:     126 lines in 3 files changed: 0 ins; 116 del; 10 mod

8319192: Remove javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)

Reviewed-by: azvegint, tr

-------------

PR: https://git.openjdk.org/jdk/pull/23909

From prr at openjdk.org  Thu Mar 13 20:28:03 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Mar 2025 20:28:03 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
Message-ID: <ZmfOtUDEr80TOkaXSgrB3Sp4VM2xL1lYFocKUJQ--Sw=.1ef4a721-8f63-48a0-a3ce-56a431e232cf@github.com>

On Tue, 11 Mar 2025 21:26:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   redudant stmt removed

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2683289164

From achung at openjdk.org  Thu Mar 13 20:30:02 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 13 Mar 2025 20:30:02 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
Message-ID: <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>

On Fri, 28 Feb 2025 03:51:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> To some extent, yes, but the Robot class is part of AWT, which is a platform-dependent toolkit.

The main problem we are trying to solve with this fix is that macOS behavior is incorrect in that it just reflects whatever value it was passed as the destination point for mouseMove.

If we set mouseMove to go to (10000,10000) and call MouseInfo.getPointerInfo().getLocation(), that then calls the native CGEventGetLocation which returns the (10000,10000) point, but the mouse pointer is still visible in the bottom right corner of the screen.

On Windows, the native API called is GetCursorPos, which does return the correct location of the mouse.

If we don?t clamp the mouse pointer to a screen, then there can?t be a good return value for getLocation() (note that the API spec for PointerInfo.getLocation() only allows returning null if there's no mouse). So we can?t just defer the behavior to the platform, clamping needs to be added somewhere in the JDK code.

We could add the clamping code in a few places:
1. In robot shared code
2. In CRobot macOS code
3. In MouseInfo.getPointerInfo().getLocation()

Do you have any opinions on where the code should be?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2722616951

From dgredler at openjdk.org  Thu Mar 13 20:30:06 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 13 Mar 2025 20:30:06 GMT
Subject: Integrated: 8270265: LineBreakMeasurer calculates incorrect line
 breaks with zero-width characters
In-Reply-To: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
Message-ID: <AAVdYZ128LKOa9gfa4coCVUkHj87E3rqxNtR38xjvXc=.652ef3a0-6290-4cfd-9d76-340eaa9187e0@github.com>

On Wed, 12 Feb 2025 23:53:43 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
> 
> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
> 
> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
> 
> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
> 
> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

This pull request has now been integrated.

Changeset: 7fc776e2
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fc776e2ace920a3b1b319c021e6d3d440305b5e
Stats:     23 lines in 6 files changed: 13 ins; 1 del; 9 mod

8270265: LineBreakMeasurer calculates incorrect line breaks with zero-width characters

Reviewed-by: achung, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23603

From duke at openjdk.org  Thu Mar 13 20:30:09 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Thu, 13 Mar 2025 20:30:09 GMT
Subject: Integrated: 8349350: Unable to print using InputSlot and OutputBin
 print attributes at the same time
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <fZ05mIO0E04Z57WAbBId9ZlbhHxT074WWqHY3SlNjpo=.b4f25b4d-242c-4ab4-aa1e-88e0ecbb4acc@github.com>

On Wed, 5 Feb 2025 07:03:26 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

This pull request has now been integrated.

Changeset: 3da5e3fe
Author:    Gennadiy Krivoshein <gennadiy.krivoshein at bell-sw.com>
URL:       https://git.openjdk.org/jdk/commit/3da5e3fe10350f9bf0ff8c6b8d9aad3f50646364
Stats:     270 lines in 4 files changed: 266 ins; 0 del; 4 mod

8349350: Unable to print using InputSlot and OutputBin print attributes at the same time

Reviewed-by: prr, kizune, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/23457

From prr at openjdk.org  Thu Mar 13 21:36:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Mar 2025 21:36:52 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <_9DZKVJmfSD4_7OM927qm8gdV99YNtis5ncMwZprxLA=.6787b262-250b-4253-888c-5844ef9bdf32@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

What is being done here in terms of calculations is imprecise, but the specific test here
(comparring known to be required memory vs theoretically available memory) should prevent cases of almost certain OOME, without claiming that there will be no OOME if the test passes.
That's it. Not perfect, because free memory can change in either direction.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23814#pullrequestreview-2683418235

From serb at openjdk.org  Fri Mar 14 00:02:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Mar 2025 00:02:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <-VpTIIutmIIh3baxOFDrIdfIBgDIRIr0-8QGcrU6A80=.713b71d9-97a8-414d-ae13-c4021cf35397@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
 <-VpTIIutmIIh3baxOFDrIdfIBgDIRIr0-8QGcrU6A80=.713b71d9-97a8-414d-ae13-c4021cf35397@github.com>
Message-ID: <cxuyKf9-LJk_xnHWi6-AiAiz2bYPeKaaq1ELDUHEiR4=.1eb9d977-c3b0-4077-bc66-294a7e098d95@github.com>

On Tue, 11 Mar 2025 22:11:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>I think @azuev-java has a valid point here. It might be better to check if enough memory is available upfront rather than end up with OOME later on.

I think this is the first use of the totalMemory/freeMemory combination in the JDK codebase. It?s essentially code that tries to emulate what the JVM already does best. If totalSize is trusted and we want to check it, we can simply allocate data - gc will have a chance to clean up memory and report whether allocation is possible or not we can catch that . This approach will work reliably in multithreaded code as well.

The current solution may throw an exception even when we could produce correct data, and it may pass in cases where we run into an OOM later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2722956952

From serb at openjdk.org  Fri Mar 14 00:15:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Mar 2025 00:15:53 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <OE-EFprNbh0-IZfEh-1xWmYtsxUqDdEMznueslUiV4I=.bfe9b794-d436-4de3-8f1a-c7b993e0d83c@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
 <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YO
 vFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
 <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>
 <5xSDhfirAFhWrkywEnGD20qpEI4Nqz45tgWvLoCIiWw=.2842c7e0-0b14-4423-9f4a-84fbc8a24599@github.com>
 <OE-EFprNbh0-IZfEh-1xWmYtsxUqDdEMznueslUiV4I=.bfe9b794-d436-4de3-8f1a-c7b993e0d83c@github.com>
Message-ID: <6JxQGRzi8WA4rBBgppxas3wSYTKSWxL_wfWolqmkNRQ=.bc2fe624-b97d-4395-8138-dde5dcccc87e@github.com>

On Sun, 9 Mar 2025 02:53:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> No because rendering of the soundbank would take time - probably seconds - and that will throw reproduction of the second MIDI file off the track. I just remind that the MIDI we are rendering can come from any source - including the connected hardware like MIDI keyboard - and adding random delays before playing a note - even if it's one quarter or one eighth of a second will definitely be audible.

But it's our own soundbank, so it doesn't seem like it would cause any delay when playing MIDI files using it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1994459804

From serb at openjdk.org  Fri Mar 14 01:26:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Mar 2025 01:26:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
 <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
 <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>
Message-ID: <nseVVyZSwxr2TtCJ9NQOzn5bRLC2qhGTzB2xthKFgQo=.5d393b34-fb1f-45df-a64d-a96b3544f9a5@github.com>

On Wed, 12 Mar 2025 21:09:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> * Builtin color profiles may be cached during initialization or on first use. Changing a standard profiles after initialization using ICC_Profile.setData may not have the desired effect.
>
>> > Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
>> 
>> But it also has its own disadvantages...
> 
> @mrserb  You mentioned earlier that there are disadvantages of using java properties approach, so using builtIn flag would be better then, correct?
> 
>>  I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps.
> 
> I wasn't able to find the previous discussion thread so I'm not sure what are the disadvantages. Can you please explain?

If we start from the beginning. The problem we are trying to solve is preventing changes to our standard profiles so that we can be sure one part of the application does not unexpectedly affect another. This could be achieved in two ways:

- Throw an exception if a standard profile is modified
- Ignore the requested change and use the default profile properties as is

For new applications, we could require always cloning the color profile before modification (via the updated specification); otherwise, the application must always check whether the profile is built-in or not.

However, for older applications, these two solutions lead to different outcomes:

- Throwing the new exception will most likely break the application
- Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate

The next question is: how big of an issue is this inaccuracy? For example, if we have an sRGB profile that rejects some modifications, we would still try to produce valid sRGB data during conversion.

So the trade-off is: broken applications vs. inaccurate (but still ICC-spec-compliant) conversions.

PS: By the way, why do we want to enforce this rule only for built-in profiles? Why can't a library create similar profiles and mark them as "read-only"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1994532183

From serb at openjdk.org  Fri Mar 14 01:51:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Mar 2025 01:51:57 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
Message-ID: <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>

On Thu, 13 Mar 2025 20:27:34 GMT, Alisen Chung <achung at openjdk.org> wrote:

>If we set mouseMove to go to (10000,10000) and call MouseInfo.getPointerInfo().getLocation(), that then calls the native CGEventGetLocation which returns the (10000,10000) point, but the mouse pointer is still visible in the bottom right corner of the screen.

But where is the actual mouse pointer located at this moment? If you press any mouse button (not necessarily using the robot), where will the click occur?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2723120279

From serb at openjdk.org  Fri Mar 14 02:05:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Mar 2025 02:05:52 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <H0YFSzbS2q8XYstudVf2lWGxBaSCKF4MHKJcDd-tsGg=.61897818-de16-4514-a927-ac073c945f0a@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <H0YFSzbS2q8XYstudVf2lWGxBaSCKF4MHKJcDd-tsGg=.61897818-de16-4514-a927-ac073c945f0a@github.com>
Message-ID: <qH6CUDpENP3y-NUoOTHztGpRQec1No_fUP5v5srk1Ek=.e27d038a-70f7-44cd-8c21-e1fa45b1c90a@github.com>

On Thu, 13 Mar 2025 15:45:12 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   header update
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 249:
> 
>> 247:       DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \
>> 248:       DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \
>> 249:       DISABLED_WARNINGS_clang_png.c := unused-function, \
> 
> This warning was disabled to fix the following build issue on linux and macOS.
> 
> 
> open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function]
> [2025-03-12T23:57:44,575Z]  1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name,
> [2025-03-12T23:57:44,575Z]       | ^~~~~~~~~~~~~~~~~~~~~

Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1994558215

From psadhukhan at openjdk.org  Fri Mar 14 02:50:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Mar 2025 02:50:16 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v2]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <3epbllurOgsccReVbsttnH97NTCeHQXlhpqhLGSpAiU=.60629a3b-f3e1-4ce2-b6b6-5172436adf07@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Get rowCount,columnCount upfront

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/958b39c4..196ba416

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Fri Mar 14 15:02:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Mar 2025 15:02:01 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
Message-ID: <nMNnXVJRP5akmphwJ0k6NXdR2e6Vm3-THnxizGZAGRE=.25f1e329-058e-4236-b22d-bfa7401fc531@github.com>

On Thu, 6 Mar 2025 18:59:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> There is a lot to absorb here. I don't want to get into line by line code discussion, we need to have the big picture right first.
> 
> (1) This affects all releases, right ? The evaluation in the bug report is non-existent.
> I expect to see a full description of how it came about (history) what the consequences are,
> what the options are etc. Without that the PR is in a vacuum.
> 
> (2) My rough understanding is that this was "observed" because of a change in Windows 11 vs earlier Windows versions
> with the highlighting of the radio button .. but the fix has some how become focused on the ImageIcon ?
> If I don't have this right, give me a clear and complete explanation of the issue (ie part of the missing evaluation)
> 
> Surely that isn't a Windows 10 vs Windows 11 issue ?? Unless it is an accidental by-product of some layout problem ?
> I am seeing code in the pre-fix side of the diff that does paint an icon .. so I am not sure I understand.
> If the same control in native windows doesn't allow such an icon, then we are within our rights to ignore it.
> There are a bunch of settings, such as b/g color etc that various L&Fs ignore if they aren't appropriate.
> Search the javax.swing javadoc for the word "ignore" and you'll find hundreds of matches.
> 
> I can't actually tell from the PR description what the inentention is
> "Added provision of drawing the radiobutton windows Skin even when imageIcon is present."
> 
> Does that mean it continues to ignore the imageicon - ie not render it ? But as I wrote there is something that looks to be painting an icon. Maybe we are talking about the "icon" that is actually the rendering of the radio button - not an application supplied imageicon ?
> I'd like 100% clarity here.
> 
> (3) Any fix requiring a CSR would be a problem - at least if it is SE spec significant, because it seems like this fix needs to be backported all the way to 8u. If there is a *better* fix that requires a CSR for the future, we can do that as a follow-on for JDK 25 only, but we should start with what can be backported, and do the better fix as a follow-on.
> 
> I'll deviate  slightly from my "I won't get in to lines for code here", and say that FWIW the current fix isn't what I'd like to see.
> Putting a check for Windows L&F in a BasicUI class ?? We had a similar issue with GTK some months ago and it was something that we managed to avoid. Isn't there a Windows L&F sub-class we can do this in ??
> 
> (4) We are not any time soon de-supporting Windows 10.
> Windows 10 is still supported by M...

@prrace I dont see checkmark/radio bullet with imageicon in WinGDI...
CheckMenuRadioItem is there in win32 API but is not called in our windows native. It does not have provision of having image icon passed to it.
In JDK, I can only see DrawFrameControl with DFCS_BUTTONCHECK/DFCS_BUTTONRADIO which is called from awt.
AWT spec has only CheckboxMenuItem and no RadioMenuItem and CheckboxMenuItem also does not have provision of drawing image icon, 
so it seems to be only Swing provision to have image icon alongside radio bullet/checkmark and getting Part.MP_POPUPCHECKBACKGROUND skin to show the background around icon/checkmark/bullet is not working in Windows11 as it was doing in WIndows10..
If we are not supposed to follow WIndows FileExplorer, not sure how to represent selection of the radiobutton/check menuitem

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2724960838

From jkern at openjdk.org  Fri Mar 14 15:47:25 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 14 Mar 2025 15:47:25 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
Message-ID: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>

After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.

Now with this change we can enable the statically linked launcher target again.
There are 3 things to do.
1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

-------------

Commit messages:
 - JDK-8352064

Changes: https://git.openjdk.org/jdk/pull/24062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352064
  Stats: 66 lines in 5 files changed: 60 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From prr at openjdk.org  Fri Mar 14 16:30:08 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Mar 2025 16:30:08 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <nMNnXVJRP5akmphwJ0k6NXdR2e6Vm3-THnxizGZAGRE=.25f1e329-058e-4236-b22d-bfa7401fc531@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <nMNnXVJRP5akmphwJ0k6NXdR2e6Vm3-THnxizGZAGRE=.25f1e329-058e-4236-b22d-bfa7401fc531@github.com>
Message-ID: <pxNILcHmaDam6r4bf9rXYQrt7KVuwZLCgdIXEhtV5bA=.291ad900-7e8e-425f-90a4-6b85ff0e68c6@github.com>

On Fri, 14 Mar 2025 14:59:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>  CheckMenuRadioItem is there in win32 API

Ok.
 > but is not called in our windows native.
> It does not have provision of having image icon passed to it. 

I don't see how either of these matters.
I'm sure there are lots of windows controls we don't use in AWT. Swing is much richer.
For an extreme example, how would you compare the GDI table component to Swing's ?
As I said off-line, you just need to write a small native program to verify how it should render.

And if there's no provision for an image icon, then the Swing Windows L&F doesn't need to support it either
We don't (shouldn't) chase what Windows File Explorer does. That's not representative. It is a prominent
app and likely heavily customised in its drawing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2725181969

From erikj at openjdk.org  Fri Mar 14 17:38:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Mar 2025 17:38:58 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 116:

> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \

The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:

Suggestion:

#    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \


You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1996001131

From honkar at openjdk.org  Fri Mar 14 17:40:08 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Mar 2025 17:40:08 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <qH6CUDpENP3y-NUoOTHztGpRQec1No_fUP5v5srk1Ek=.e27d038a-70f7-44cd-8c21-e1fa45b1c90a@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <H0YFSzbS2q8XYstudVf2lWGxBaSCKF4MHKJcDd-tsGg=.61897818-de16-4514-a927-ac073c945f0a@github.com>
 <qH6CUDpENP3y-NUoOTHztGpRQec1No_fUP5v5srk1Ek=.e27d038a-70f7-44cd-8c21-e1fa45b1c90a@github.com>
Message-ID: <YFmbHCfgq0rjPb60vS_3ahmudU_mAfcoUSrEwc4_uO8=.ea0e9d59-49f7-46fb-9d97-12dc74622f6c@github.com>

On Fri, 14 Mar 2025 02:02:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> make/modules/java.desktop/lib/ClientLibraries.gmk line 249:
>> 
>>> 247:       DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \
>>> 248:       DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \
>>> 249:       DISABLED_WARNINGS_clang_png.c := unused-function, \
>> 
>> This warning was disabled to fix the following build issue on linux and macOS.
>> 
>> 
>> open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function]
>> [2025-03-12T23:57:44,575Z]  1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name,
>> [2025-03-12T23:57:44,575Z]       | ^~~~~~~~~~~~~~~~~~~~~
>
> Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream.

In libconfig.h Ln#120 the undef is commented out - `/*#undef PNG_READ_iCCP_SUPPORTED*/` but I don't see it defined.

@prrace  do we define it in libconfig.h and remove the warning from disabled section in ClientLibraries.gmk? In Updating.txt , I see a note on libconfig.h, it is heavily modified for JDK and a define stmt can be added on need basis.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1996000410

From aivanov at openjdk.org  Fri Mar 14 18:49:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Mar 2025 18:49:55 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <plLY2XsmWy50HGIE6-MAjjbdQZQ-Zr9Stkn2qJm_o5k=.10d18067-36aa-42d9-87a4-2bcd7d55ac3a@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <W1Z80Vn2TAKO3Hz7tsjoFUNnA8QpPBgLfkhtkZHA2Ec=.41b574eb-e8b9-473d-a0f7-5d9560a224e3@github.com>
 <wV_NxwKTx6OjwmcxAtIcUFp1rDgBaw3jr-Vu85MdO_s=.aaafe7f7-05c8-417b-b161-475fcbb490f6@github.com>
 <3ANRlYjGqwwDC80Pd96LsOK1tD5BNBH15PaXCcW8iaY=.e84fe5ec-77b8-417f-9fda-519acc086788@github.com>
 <plLY2XsmWy50HGIE6-MAjjbdQZQ-Zr9Stkn2qJm_o5k=.10d18067-36aa-42d9-87a4-2bcd7d55ac3a@github.com>
Message-ID: <cvpEmMt2_96i_AfHwtqwIkEFEcfd9aop5w0BywAL5K8=.b90b2e08-8538-4401-a33f-063b953af785@github.com>

On Thu, 13 Mar 2025 03:04:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Can we move these helper methods into a utility class which has public access to both `Basic*UI` and `Windows*UI`? `SwingUtilities3`, or a new class?
> > 
> > OK..Moved..PR updated
> 
> Guess I have taken care of the problematic windows L&F check in Basic class and reduced the code duplication.. Any more comments @aivanov-jdk?

Thank you!

I'm sorry, I've been unable to look at the changes thoroughly, and there are many changes now.

I looked at [the screenshot](https://github.com/openjdk/jdk/pull/23324#pullrequestreview-2677986364) that @kumarabhi006 attached, I still think the text of the menu items that have no icon should move to right and align with menu items that have icons.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2725497063

From aivanov at openjdk.org  Fri Mar 14 19:30:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Mar 2025 19:30:55 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v18]
In-Reply-To: <pxNILcHmaDam6r4bf9rXYQrt7KVuwZLCgdIXEhtV5bA=.291ad900-7e8e-425f-90a4-6b85ff0e68c6@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <UAkE4q1A2wCCWDNn9BzeCFpOZjMGaqbbjve1uYKh2Ow=.74f093d6-77da-4898-8bf2-8694760eef62@github.com>
 <pSaWd8LzjH1CNrhj52Davi4B3IHJOmk9XGG3o1ktR-0=.6be68746-bef1-4606-84c8-e822f88dc68f@github.com>
 <nMNnXVJRP5akmphwJ0k6NXdR2e6Vm3-THnxizGZAGRE=.25f1e329-058e-4236-b22d-bfa7401fc531@github.com>
 <pxNILcHmaDam6r4bf9rXYQrt7KVuwZLCgdIXEhtV5bA=.291ad900-7e8e-425f-90a4-6b85ff0e68c6@github.com>
Message-ID: <U0ju583DxXZ6F4FiUGSwJ_bhtUbiutG--j0jjYpFpdU=.eeb1b96e-9071-4580-9040-e27ef3fdd421@github.com>

On Fri, 14 Mar 2025 16:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace I dont see checkmark/radio bullet with imageicon in WinGDI...
>> CheckMenuRadioItem is there in win32 API but is not called in our windows native. It does not have provision of having image icon passed to it.
>> In JDK, I can only see DrawFrameControl with DFCS_BUTTONCHECK/DFCS_BUTTONRADIO which is called from awt.
>> AWT spec has only CheckboxMenuItem and no RadioMenuItem and CheckboxMenuItem also does not have provision of drawing image icon, 
>> so it seems to be only Swing provision to have image icon alongside radio bullet/checkmark and getting Part.MP_POPUPCHECKBACKGROUND skin to show the background around icon/checkmark/bullet is not working in Windows11 as it was doing in WIndows10..
>> If we are not supposed to follow WIndows FileExplorer, not sure how to represent selection of the radiobutton/check menuitem
>
>>  CheckMenuRadioItem is there in win32 API
> 
> Ok.
>  > but is not called in our windows native.
>> It does not have provision of having image icon passed to it. 
> 
> I don't see how either of these matters.
> I'm sure there are lots of windows controls we don't use in AWT. Swing is much richer.
> For an extreme example, how would you compare the GDI table component to Swing's ?
> As I said off-line, you just need to write a small native program to verify how it should render.
> 
> And if there's no provision for an image icon, then the Swing Windows L&F doesn't need to support it either
> We don't (shouldn't) chase what Windows File Explorer does. That's not representative. It is a prominent
> app and likely heavily customised in its drawing.

> @prrace I dont see checkmark/radio bullet with imageicon in WinGDI...\
> CheckMenuRadioItem is there in win32 API but is not called in our windows native. It does not have provision of having image icon passed to it.

The check-mark displayed next to a menu item can be customised by using `hbmpChecked` and `hbmpUnchecked` of [`MENUITEMINFO`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-menuiteminfow) structure.

Yet there's no way in Win32 to display a check-mark (or radio-bullet) _and_ an icon, to the best of my knowledge.

AWT supports displaying a check-mark in a menu item but it does not support displaying a radio-bullet to indicate a set of mutually exclusive options which are usually represented with radio buttons in the interface.

> For an extreme example, how would you compare the GDI table component to Swing's ?\
> As I said off-line, you just need to write a small native program to verify how it should render.

I wanted to play around with native Win32 menus to explore the features it supports.

> And if there's no provision for an image icon

Win32 API allows adding an icon, or rather a bitmap in Win32 terms, to a menu item using `hbmpItem` member of `MENUITEMINFO` and setting `MIIM_BITMAP` flag in `fMask`.

The usage of this member can be seen in window menu, the one displayed by right-clicking a title bar of a window, for *Restore*, *Minimise*, *Maximise*, and *Close* commands.

> then the Swing Windows L&F doesn't need to support it either

Yet, as I said previously, I don't think it's possible to display both a custom icon _and_ a check-mark or radio-bullet mark at the same time.

> We don't (shouldn't) chase what Windows File Explorer does. That's not representative. It is a prominent
app and likely heavily customised in its drawing.

I agree that File Explorer in Windows 11 isn't representative. File Explorer uses many features provided by newer set of APIs. I also agree the *View* menu in File Explorer is likely custom-drawn even if Win32 menu API is used.

---

Windows 11 has changed the skin that corresponds to `Part.MP_POPUPCHECKBACKGROUND` so that it's no longer different for a selected check-mark. Other Win32 apps which use the same approach to display an icon for a menu item that can be selected should also be affected.

Shall we do nothing and just close the bug as *Not an Issue*?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2725574600

From honkar at openjdk.org  Fri Mar 14 21:25:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Mar 2025 21:25:53 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <qH6CUDpENP3y-NUoOTHztGpRQec1No_fUP5v5srk1Ek=.e27d038a-70f7-44cd-8c21-e1fa45b1c90a@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <H0YFSzbS2q8XYstudVf2lWGxBaSCKF4MHKJcDd-tsGg=.61897818-de16-4514-a927-ac073c945f0a@github.com>
 <qH6CUDpENP3y-NUoOTHztGpRQec1No_fUP5v5srk1Ek=.e27d038a-70f7-44cd-8c21-e1fa45b1c90a@github.com>
Message-ID: <6ygTo-i9hMI4V4ZEXf2MACpCTEkLbes9HEIMyDQ0RYI=.7d749748-7a5f-4a74-b83e-90690f460e50@github.com>

On Fri, 14 Mar 2025 02:02:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> make/modules/java.desktop/lib/ClientLibraries.gmk line 249:
>> 
>>> 247:       DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \
>>> 248:       DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \
>>> 249:       DISABLED_WARNINGS_clang_png.c := unused-function, \
>> 
>> This warning was disabled to fix the following build issue on linux and macOS.
>> 
>> 
>> open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function]
>> [2025-03-12T23:57:44,575Z]  1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name,
>> [2025-03-12T23:57:44,575Z]       | ^~~~~~~~~~~~~~~~~~~~~
>
> Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream.

@mrserb I see, what you meant is that the function `png_icc_profile_error` should be guarded with PNG_READ_iCCP_SUPPORTED instead of PNG_iCCP_SUPPORTED. Reported it to upstream - https://github.com/pnggroup/libpng/issues/668

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1996304716

From achung at openjdk.org  Sat Mar 15 00:20:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 15 Mar 2025 00:20:01 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
Message-ID: <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>

On Fri, 14 Mar 2025 01:48:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But where is the actual mouse pointer located at this moment? If you press any mouse button (not necessarily using the robot), where will the click occur?

The click occurs at the edge of the screen. You can run the test attached with the screenshot mode on (this will display the mouse location) and once the test is finished the mouse will display coordinates at the edge of the screen. If you move any windows onto the edge of the screen where the mouse appears to end up and run the test again, then do a simple manual click, that window will gain focus. So the actual mouse pointer isn't at (10000,10000) but rather at the edge of the screen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2726048504

From kizune at openjdk.org  Sat Mar 15 01:56:01 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 15 Mar 2025 01:56:01 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <6JxQGRzi8WA4rBBgppxas3wSYTKSWxL_wfWolqmkNRQ=.bc2fe624-b97d-4395-8138-dde5dcccc87e@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <NXWY0Ongzd0nw4O7yDQzHkNUEN9KUGT-XVPJEJ-hDZ8=.25c096df-a2a8-4419-a8a9-1a56f3c377aa@github.com>
 <VYhP29po9aRwdB5dl4Ot8H5qCRin4fR2n9KKzraLhuc=.4820aa3e-81b3-4890-a237-8b7e0244ca21@github.com>
 <rUx19WWbXNKuPUXLLRweIZVYSGS0zarhnB-MniaRF5w=.7f635a2f-48dd-4b1e-8427-2cd3db4f7945@github.com>
 <jb-n1U5sVDHzBl9e74GXpbzQgIlkfqOocixAX3wAHSw=.33c1d759-d848-40a1-ad8b-1fe458bbb681@github.com>
 <wRuL32VDAQTQvVNFubY6a_t3thVpD9_PoCvBNl_kmYk=.58fd0093-1d0a-49ec-b3c4-5e686bfd3402@github.com>
 <iVCALdE0o5vr8q0l_3RDtfiXc-JxIEjZYkATGjMeOuI=.df21791e-9252-4956-a8aa-ea086ee5798d@github.com>
 <SlSgLlio_jt7ktzNE8PqQnBY3qbjlDdmL1V-i89B7hc=.40627fb3-b23c-4e90-810c-7cf55351c5a8@github.com>
 <pfk38N6HcTIsI3zI-cURmfRha6dr50MImAZAw-XFtFY=.54fe6ddd-1044-4640-ae26-20e6be3cb15c@github.com>
 <I0kKRPkxTkyRqboWQ-N3yJ8nOoRh9BdUnXkYVVaPPGM=.794d2d2c-adba-4755-b3d0-519b7ef342c9@github.com>
 <Ut681h6n_Jn4ZBNBJxlsr8iLhXULxEPX3YO
 vFT6aPBM=.53b516f2-2e02-4e55-8fe3-73acf0bb8719@github.com>
 <1JWbgjxrc_NVepe6GLS1-Omq1UjJ5VwUwkthKiny9ps=.5b35768d-9043-467d-9421-85097c538fe8@github.com>
 <5xSDhfirAFhWrkywEnGD20qpEI4Nqz45tgWvLoCIiWw=.2842c7e0-0b14-4423-9f4a-84fbc8a24599@github.com>
 <OE-EFprNbh0-IZfEh-1xWmYtsxUqDdEMznueslUiV4I=.bfe9b794-d436-4de3-8f1a-c7b993e0d83c@github.com>
 <6JxQGRzi8WA4rBBgppxas3wSYTKSWxL_wfWolqmkNRQ=.bc2fe624-b97d-4395-8138-dde5dcccc87e@github.com>
Message-ID: <-_3vds00B0aPBAWkhX52jAnAhl1JNzxpVb-3PU2Sbag=.ab9051d2-000f-43dd-a4a0-b4fb4d343149@github.com>

On Fri, 14 Mar 2025 00:13:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But it's our own soundbank, so it doesn't seem like it would cause any delay when playing MIDI files using it.

Not really sure what you mean by this. We have a soundbank A constructed from MIDI file using the default soundbank with software synthesizer. It can be used to play another MIDI source. It can be used to substitute any instrument (or multitude of instruments) multiple times in the said MIDI source. Rendering it takes time. In order to use it we will have to render it. Means multiple parallel renders of the soundbank A to play MIDI source if we delay rendering until it is actually needed - that can cause delays in the place where delays are not anticipated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1996500508

From markus at headcrashing.eu  Sat Mar 15 18:25:27 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sat, 15 Mar 2025 19:25:27 +0100
Subject: RFC: java.awt.Desktop methods should accept Path in addition to File
Message-ID: <c1e94bb9-7a2d-42b8-8659-1352ef1843e4@headcrashing.eu>

Since Java 7 there is java.nio.file.Path as a modern alternative to 
java.io.File. Many APIs in OpenJDK make use of Path already, but not 
java.awt.Desktop. This forces authors of new desktop applications to 
convert to File explicitly. While it is understood there are not masses 
of such applications newly authored, still there are some, and their 
authors contacted me regarding this.

I would be happy to provide a PR which adds alternative signatures 
allowing to pass Path directly. The change would be very small hence 
quick to review, mostly cheap to maintain, and at most risk-free, as it 
simply internalizes code that otherwise would exist externally.

Comments appreciated!

Regards

-Markus Karg


From davidalayachew at gmail.com  Sun Mar 16 03:02:26 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 15 Mar 2025 23:02:26 -0400
Subject: RFC: java.awt.Desktop methods should accept Path in addition to
 File
In-Reply-To: <c1e94bb9-7a2d-42b8-8659-1352ef1843e4@headcrashing.eu>
References: <c1e94bb9-7a2d-42b8-8659-1352ef1843e4@headcrashing.eu>
Message-ID: <CAA9v-_PqsdVyPLvWPijrPzCx4m3eY8ApCfKMSR2eS_4VbbK-DQ@mail.gmail.com>

Hello Markus Karg,

I spend a lot of my time making Swing apps. I can certainly relate to the
pain of your compatriots.

Truthfully though, I don't see any significant benefit, other than writing
one less method per situation. A vast majority of my IO work is already
pretty specialized, so, while annoying, it's not really something that I do
so much of that this method would benefit me greatly.

Essentially, I would like to avoid adding more to the API than there
already is, barring any fairly powerful new additions. I'd like to say that
Pattern-Matching will be an example of something that justifies adding to
the API.

If it were me, I would actually turn it around and find situations that are
worth perturbing the API, then strongly suggest that those new API's use
Path, encouraging this since there is that little translator method
toFile(). Turn your opponent's argument against them, basically lol.

Granted, that's still not an easy task, but I suspect that you will have
momentum in your favor that way.

On Sat, Mar 15, 2025, 2:26?PM Markus KARG <markus at headcrashing.eu> wrote:

> Since Java 7 there is java.nio.file.Path as a modern alternative to
> java.io.File. Many APIs in OpenJDK make use of Path already, but not
> java.awt.Desktop. This forces authors of new desktop applications to
> convert to File explicitly. While it is understood there are not masses
> of such applications newly authored, still there are some, and their
> authors contacted me regarding this.
>
> I would be happy to provide a PR which adds alternative signatures
> allowing to pass Path directly. The change would be very small hence
> quick to review, mostly cheap to maintain, and at most risk-free, as it
> simply internalizes code that otherwise would exist externally.
>
> Comments appreciated!
>
> Regards
>
> -Markus Karg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250315/c74a18a1/attachment.htm>

From mvs at openjdk.org  Sun Mar 16 09:03:37 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Sun, 16 Mar 2025 09:03:37 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms where
 Action.MAIL is not supported
Message-ID: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>

**Issue**
java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported

**Reason**
In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 

**Fix**
Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.

**Testing**
This is a manual test, so it is tested locally and found to be working fine.

-------------

Commit messages:
 - 8352109: java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported

Changes: https://git.openjdk.org/jdk/pull/24072/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352109
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24072/head:pull/24072

PR: https://git.openjdk.org/jdk/pull/24072

From markus at headcrashing.eu  Sun Mar 16 09:18:25 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 16 Mar 2025 10:18:25 +0100
Subject: RFC: java.awt.Desktop methods should accept Path in addition to
 File
In-Reply-To: <CAA9v-_PqsdVyPLvWPijrPzCx4m3eY8ApCfKMSR2eS_4VbbK-DQ@mail.gmail.com>
References: <c1e94bb9-7a2d-42b8-8659-1352ef1843e4@headcrashing.eu>
 <CAA9v-_PqsdVyPLvWPijrPzCx4m3eY8ApCfKMSR2eS_4VbbK-DQ@mail.gmail.com>
Message-ID: <74b21291-ecb6-46f3-94b1-63177a03cc7d@headcrashing.eu>

Thank you, David. Understood your opinion.

In fact, it would be MY sole time and effort to add and maintain that 
Path-based API variants (not yours or anybody else's), so why NOT 
allowing me to do that? In this area, will do THAT or nothing at all, in 
fact. This thread is NOT about what to ask me for alternatively. So you 
finally chose NOTHING? Can't see the benefit of that for my or anybody 
else's community.

-Markus


Am 16.03.2025 um 04:02 schrieb David Alayachew:
> Hello?Markus Karg,
>
> I spend a lot of my time making Swing apps. I can certainly relate to 
> the pain of your compatriots.
>
> Truthfully though, I don't see any significant benefit, other than 
> writing one less method per situation. A vast majority of my IO work 
> is already pretty specialized, so, while annoying, it's not really 
> something that I do so much of that this method would benefit me greatly.
>
> Essentially, I would like to avoid adding more to the API than there 
> already is, barring any fairly powerful new additions. I'd like to say 
> that Pattern-Matching will be an example of something that justifies 
> adding to the API.
>
> If it were me, I would actually turn it around and find situations 
> that are worth perturbing the API, then strongly suggest that those 
> new API's use Path, encouraging this since there is that little 
> translator method toFile(). Turn your opponent's argument against 
> them, basically lol.
>
> Granted, that's still not an easy task, but I suspect that you will 
> have momentum in your favor that way.
>
> On Sat, Mar 15, 2025, 2:26?PM Markus KARG <markus at headcrashing.eu> wrote:
>
>     Since Java 7 there is java.nio.file.Path as a modern alternative to
>     java.io.File. Many APIs in OpenJDK make use of Path already, but not
>     java.awt.Desktop. This forces authors of new desktop applications to
>     convert to File explicitly. While it is understood there are not
>     masses
>     of such applications newly authored, still there are some, and their
>     authors contacted me regarding this.
>
>     I would be happy to provide a PR which adds alternative signatures
>     allowing to pass Path directly. The change would be very small hence
>     quick to review, mostly cheap to maintain, and at most risk-free,
>     as it
>     simply internalizes code that otherwise would exist externally.
>
>     Comments appreciated!
>
>     Regards
>
>     -Markus Karg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250316/5b9f2d03/attachment.htm>

From davidalayachew at gmail.com  Sun Mar 16 16:14:07 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 16 Mar 2025 12:14:07 -0400
Subject: RFC: java.awt.Desktop methods should accept Path in addition to
 File
In-Reply-To: <74b21291-ecb6-46f3-94b1-63177a03cc7d@headcrashing.eu>
References: <c1e94bb9-7a2d-42b8-8659-1352ef1843e4@headcrashing.eu>
 <CAA9v-_PqsdVyPLvWPijrPzCx4m3eY8ApCfKMSR2eS_4VbbK-DQ@mail.gmail.com>
 <74b21291-ecb6-46f3-94b1-63177a03cc7d@headcrashing.eu>
Message-ID: <CAA9v-_O-cAY2UwUMJogH8QJF0vk9H+GeJdmjkpJ6K3mR3E6CrA@mail.gmail.com>

By all means, try your luck. I only suggest to provide an alternative path.

As a minor correction though, the primary purpose of this mailing list (and
this thread, by extension) is to give feedback on existing features,
including their pain points. If someone suggests an API change in response
to a pain point, it is, in fact, the goal of this thread to evaluate those
ideas, and suggest alternatives if the proposed idea doesn't appear to be
the best fit. It may not have been your intention when making this thread,
but that is how this mailing list works.

Try not to take this response or my original one as a complete dismissal of
your idea. It's simply me giving feedback on how well your idea meets
certain needs.

I feel like there are better alternatives, but I don't think your idea is
bad. I bring all of this up because I have been involved in this community
for about 5 years now, and I've seen ideas like yours (in fact, your idea
exactly! Now that I think about it...) get rejected for the reasons I
stated, and more.


On Sun, Mar 16, 2025, 5:18?AM Markus KARG <markus at headcrashing.eu> wrote:

> Thank you, David. Understood your opinion.
>
> In fact, it would be MY sole time and effort to add and maintain that
> Path-based API variants (not yours or anybody else's), so why NOT allowing
> me to do that? In this area, will do THAT or nothing at all, in fact. This
> thread is NOT about what to ask me for alternatively. So you finally chose
> NOTHING? Can't see the benefit of that for my or anybody else's community.
>
> -Markus
>
>
> Am 16.03.2025 um 04:02 schrieb David Alayachew:
>
> Hello Markus Karg,
>
> I spend a lot of my time making Swing apps. I can certainly relate to the
> pain of your compatriots.
>
> Truthfully though, I don't see any significant benefit, other than writing
> one less method per situation. A vast majority of my IO work is already
> pretty specialized, so, while annoying, it's not really something that I do
> so much of that this method would benefit me greatly.
>
> Essentially, I would like to avoid adding more to the API than there
> already is, barring any fairly powerful new additions. I'd like to say that
> Pattern-Matching will be an example of something that justifies adding to
> the API.
>
> If it were me, I would actually turn it around and find situations that
> are worth perturbing the API, then strongly suggest that those new API's
> use Path, encouraging this since there is that little translator method
> toFile(). Turn your opponent's argument against them, basically lol.
>
> Granted, that's still not an easy task, but I suspect that you will have
> momentum in your favor that way.
>
> On Sat, Mar 15, 2025, 2:26?PM Markus KARG <markus at headcrashing.eu> wrote:
>
>> Since Java 7 there is java.nio.file.Path as a modern alternative to
>> java.io.File. Many APIs in OpenJDK make use of Path already, but not
>> java.awt.Desktop. This forces authors of new desktop applications to
>> convert to File explicitly. While it is understood there are not masses
>> of such applications newly authored, still there are some, and their
>> authors contacted me regarding this.
>>
>> I would be happy to provide a PR which adds alternative signatures
>> allowing to pass Path directly. The change would be very small hence
>> quick to review, mostly cheap to maintain, and at most risk-free, as it
>> simply internalizes code that otherwise would exist externally.
>>
>> Comments appreciated!
>>
>> Regards
>>
>> -Markus Karg
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250316/c9874630/attachment.htm>

From dholmes at openjdk.org  Mon Mar 17 06:43:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 06:43:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.

I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2728361931

From jkern at openjdk.org  Mon Mar 17 10:04:56 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 10:04:56 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
Message-ID: <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>

On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> make/StaticLibs.gmk line 116:
> 
>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
> 
> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
> 
> Suggestion:
> 
> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
> 
> 
> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998375442

From duke at openjdk.org  Mon Mar 17 10:47:06 2025
From: duke at openjdk.org (snake66)
Date: Mon, 17 Mar 2025 10:47:06 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
Message-ID: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>

On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??
>
>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
> 
> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

> > Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

I'm happy to test this, if you want. Won't have time this week, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2729033496

From psadhukhan at openjdk.org  Mon Mar 17 12:40:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Mar 2025 12:40:07 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <tezoTHXN0OXpk8-nYHA_l4jzhsBIVzHnz67gTu5AsTc=.655cf3d1-b527-4b26-ae27-5d26bcd7bc46@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

Native program to render radiobutton with image (bitmap) icon


#include <windows.h>
#include <string>

#define IDM_RADIO1 1001
#define IDM_RADIO2 1002
#define IDM_RADIO3 1003

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) {
    static TCHAR szAppName[] = TEXT("RadioMenuDemo");
    HWND hwnd;
    MSG msg;
    WNDCLASS wndclass;

    wndclass.style = CS_HREDRAW | CS_VREDRAW;
    wndclass.lpfnWndProc = WndProc;
    wndclass.cbClsExtra = 0;
    wndclass.cbWndExtra = 0;
    wndclass.hInstance = hInstance;
    wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
    wndclass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
    wndclass.lpszMenuName = NULL;
    wndclass.lpszClassName = szAppName;

    RegisterClass(&wndclass);

    hwnd = CreateWindow(szAppName, TEXT("Radio Menu Demo"),
        WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, CW_USEDEFAULT,
        400, 300,
        NULL, NULL, hInstance, NULL);

    ShowWindow(hwnd, iCmdShow);
    UpdateWindow(hwnd);

    while (GetMessage(&msg, NULL, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
    static HMENU hMainMenu, hRadioSubMenu;

    switch (message) {
    case WM_CREATE: {
        // Create main menu
        hMainMenu = CreateMenu();
        hRadioSubMenu = CreatePopupMenu();

        // Configure menu items using MENUITEMINFO
        MENUITEMINFO mii = { 0 };
        mii.cbSize = sizeof(MENUITEMINFO);
        mii.fMask = MIIM_FTYPE | MIIM_STRING | MIIM_ID | MIIM_BITMAP | MIIM_CHECKMARKS;

        // First radio item
        mii.fType = MFT_RADIOCHECK;
        std::wstring wstr1 = L"Radio Option 1";
        LPWSTR lp1 = (LPWSTR)wstr1.c_str();
        mii.dwTypeData = lp1;
        mii.cch = (UINT)strlen((const char *)lp1);
        mii.wID = IDM_RADIO1;
        mii.fState = MFS_CHECKED;

        HDC hdc = GetDC(hwnd);
        HBITMAP hBitmap = CreateCompatibleBitmap(hdc, 16, 16);
        HDC memDC = CreateCompatibleDC(hdc);
        //HGDIOBJ oldObj = SelectObject(memDC, hBitmap);
        HBRUSH hBrush = CreateSolidBrush(RGB(255, 0, 0));
        RECT rect = { 0, 0, 16, 16 };
        FillRect(memDC, &rect, hBrush);
        mii.hbmpItem = hBitmap;
        InsertMenuItem(hRadioSubMenu, 0, TRUE, &mii);

        // Second radio item
        std::wstring wstr2 = L"Radio Option 2";
        LPWSTR lp2 = (LPWSTR)wstr2.c_str();
        mii.dwTypeData = lp2;
        mii.cch = (UINT)strlen((const char *)lp2);
        mii.wID = IDM_RADIO2;
        InsertMenuItem(hRadioSubMenu, 1, TRUE, &mii);

        // Third radio item
        std::wstring wstr3 = L"Radio Option 3";
        LPWSTR lp3 = (LPWSTR)wstr3.c_str();
        mii.dwTypeData = lp3;
        mii.cch = (UINT)strlen((const char *)lp3);
        mii.wID = IDM_RADIO3;
        mii.hbmpItem = NULL;
        InsertMenuItem(hRadioSubMenu, 2, TRUE, &mii);

        // Add submenu to main menu
        AppendMenu(hMainMenu, MF_POPUP, (UINT_PTR)hRadioSubMenu, L"Options");
        SetMenu(hwnd, hMainMenu);

        // Set initial checked item using CheckMenuRadioItem
        CheckMenuRadioItem(hRadioSubMenu,
            IDM_RADIO1, IDM_RADIO3,  // Group range
            IDM_RADIO1,              // Initial selection
            MF_BYCOMMAND);           // Identifier type
        return 0;
    }

    case WM_COMMAND:
        switch (LOWORD(wParam)) {
        case IDM_RADIO1:
        case IDM_RADIO2:
        case IDM_RADIO3:
            // Update radio selection
            CheckMenuRadioItem(hRadioSubMenu,
                IDM_RADIO1, IDM_RADIO3,
                LOWORD(wParam), MF_BYCOMMAND);
            break;
        }
        return 0;

    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;
    }
    return DefWindowProc(hwnd, message, wParam, lParam);
}




It shows either icon or radio bullet in this program in WIndows 11

![image](https://github.com/user-attachments/assets/860022da-91c4-4c68-b39e-b5a543cfc2b2)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2729336165

From jkern at openjdk.org  Mon Mar 17 13:13:53 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 13:13:53 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
Message-ID: <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>

On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> make/StaticLibs.gmk line 116:
>> 
>>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
>> 
>> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
>> 
>> Suggestion:
>> 
>> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
>> 
>> 
>> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.
>
> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998701815

From erikj at openjdk.org  Mon Mar 17 13:16:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 13:16:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
Message-ID: <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>

On Mon, 17 Mar 2025 13:11:14 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?
>
> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

Looks like this variable is misspelled (missing "S").

DEPS := $(STATIC_LIB_FILE), \

Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998708773

From jkern at openjdk.org  Mon Mar 17 15:03:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 15:03:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
Message-ID: <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>

On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.
>
> Looks like this variable is misspelled (missing "S").
> 
> DEPS := $(STATIC_LIB_FILE), \
> 
> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

Ups, thank you for giving me the 'S'. But nevertheless if I make with
`make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998959519

From honkar at openjdk.org  Mon Mar 17 16:54:14 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 17 Mar 2025 16:54:14 GMT
Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3]
In-Reply-To: <LmE7YMXfGkWhHk5niW5xXgzGEnMfCVDsZ3xtsxrv1Lk=.ffd64dad-2979-4933-a814-ffcefda8fd06@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
 <FcGhig4c7cfSwKZ3qRtLL5gPIVB9IFVsfX9E4rJPpNQ=.9e9de55a-dc14-42e3-9017-05bac224e50b@github.com>
 <LmE7YMXfGkWhHk5niW5xXgzGEnMfCVDsZ3xtsxrv1Lk=.ffd64dad-2979-4933-a814-ffcefda8fd06@github.com>
Message-ID: <4_QJjFc10KjzY7epVf_sSsh5eCbCjBdB39jLoFTE09s=.99e862b8-419d-43d2-8cbf-49a80c3be8a1@github.com>

On Thu, 13 Mar 2025 19:52:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   header update
>
> I was surprised by how many changes there are.

@prrace 
> I was surprised by how many changes there are.

Yes, it was definitively more compared to last update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24021#issuecomment-2730214678

From honkar at openjdk.org  Mon Mar 17 16:54:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 17 Mar 2025 16:54:15 GMT
Subject: Integrated: JDK-8348598 : Update Libpng to 1.6.47
In-Reply-To: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
References: <NJZirLpUA1Bh_8DF964uzHS5xn8AZjdrGN_h2SPFR-s=.000ac376-a7e3-4591-859b-9f85514696c2@github.com>
Message-ID: <SXAJgCz-0PoB2iwARpptAqME-CZ6jkZLaTH9hcvG4xc=.7076d7cf-4ec1-4f7b-8a1f-e59eb52a9c5b@github.com>

On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Upgraded Libpng to v1.6.47

This pull request has now been integrated.

Changeset: 6b82b42a
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b82b42a2116900b2125e03c1ffa0824d6062757
Stats:     4890 lines in 20 files changed: 1906 ins; 2195 del; 789 mod

8348598: Update Libpng to 1.6.47

Reviewed-by: azvegint, prr, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/24021

From abhiscxk at openjdk.org  Tue Mar 18 05:27:08 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Mar 2025 05:27:08 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v2]
In-Reply-To: <3epbllurOgsccReVbsttnH97NTCeHQXlhpqhLGSpAiU=.60629a3b-f3e1-4ce2-b6b6-5172436adf07@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <3epbllurOgsccReVbsttnH97NTCeHQXlhpqhLGSpAiU=.60629a3b-f3e1-4ce2-b6b6-5172436adf07@github.com>
Message-ID: <c_nqZye9JlUVAtf0kgCq2QH2etN1g_OP9UArGEFT4xw=.a2765b61-2c83-45ae-8d50-417a9a8616c0@github.com>

On Fri, 14 Mar 2025 02:50:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rowCount,columnCount upfront

If there are no rows  then most probably `selectAll` will select `column headers`.. right?

I don't understand why do we want to select all columns if there are no rows or vice-versa ?
Does it return any useful details?

Few changes can be done in the fix and test code (if fix is applicable)

src/java.desktop/share/classes/javax/swing/JTable.java line 2199:

> 2197:             SwingUtilities2.setLeadAnchorWithoutSelection(selModel, oldLead, oldAnchor);
> 2198: 
> 2199:             selModel.setValueIsAdjusting(false);

Recently added code is a subset of the code block in `if block`. Duplicate code can be refactored with helper methods.

src/java.desktop/share/classes/javax/swing/JTable.java line 2206:

> 2204:             oldAnchor = getAdjustedIndex(selModel.getAnchorSelectionIndex(), false);
> 2205: 
> 2206:             setColumnSelectionInterval(0, getColumnCount()-1);

Suggestion:

            setColumnSelectionInterval(0, getColumnCount() - 1);

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 43:

> 41: 
> 42:         // TableModel with no rows, but 10 columns
> 43:         DefaultTableModel data = new DefaultTableModel(0, 10);

Proposed fix tries to handle two cases:
1. rowCount > 0 and columnCount = 0
2. columnCount > 0 and rowCount = 0

but test code covers only second case (rowCount = 0).

Test should be extended to verify both cases.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24025#pullrequestreview-2692980379
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000216763
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000216991
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000224539

From psadhukhan at openjdk.org  Tue Mar 18 05:59:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Mar 2025 05:59:01 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v3]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <-5fmMci4f9egaF8B1SZcZTGrrG37VjwrPg6Y12U0-qY=.00942812-345c-4627-81e4-3070e8233495@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Code duplication removed, subtest added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/196ba416..b2a8c8e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=01-02

  Stats: 108 lines in 2 files changed: 63 ins; 41 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Tue Mar 18 05:59:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Mar 2025 05:59:02 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v2]
In-Reply-To: <c_nqZye9JlUVAtf0kgCq2QH2etN1g_OP9UArGEFT4xw=.a2765b61-2c83-45ae-8d50-417a9a8616c0@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <3epbllurOgsccReVbsttnH97NTCeHQXlhpqhLGSpAiU=.60629a3b-f3e1-4ce2-b6b6-5172436adf07@github.com>
 <c_nqZye9JlUVAtf0kgCq2QH2etN1g_OP9UArGEFT4xw=.a2765b61-2c83-45ae-8d50-417a9a8616c0@github.com>
Message-ID: <Mst3L1htYJ0KZ1bCONBqEp48DuXHGg_S91oV4gq7g-k=.46ca2984-446d-432c-b835-9946025cf587@github.com>

On Tue, 18 Mar 2025 05:24:39 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> If there are no rows then most probably `selectAll` will select `column headers`.. right?
> 
> I don't understand why do we want to select all columns if there are no rows or vice-versa ? Does it return any useful details?
> 
> Few changes can be done in the fix and test code (if fix is applicable)

Spec says "Selects all rows, columns, and cells in the table." so it should mean we should select all available cells in the "table" and not header, which is separately handled via JTableHeader..

> src/java.desktop/share/classes/javax/swing/JTable.java line 2199:
> 
>> 2197:             SwingUtilities2.setLeadAnchorWithoutSelection(selModel, oldLead, oldAnchor);
>> 2198: 
>> 2199:             selModel.setValueIsAdjusting(false);
> 
> Recently added code is a subset of the code block in `if block`. Duplicate code can be refactored with helper methods.

Duplication removed

> test/jdk/javax/swing/JTable/TestTableSelectAll.java line 43:
> 
>> 41: 
>> 42:         // TableModel with no rows, but 10 columns
>> 43:         DefaultTableModel data = new DefaultTableModel(0, 10);
> 
> Proposed fix tries to handle two cases:
> 1. rowCount > 0 and columnCount = 0
> 2. columnCount > 0 and rowCount = 0
> 
> but test code covers only second case (rowCount = 0).
> 
> Test should be extended to verify both cases.

Extended..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24025#issuecomment-2731758311
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000259177
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000259518

From abhiscxk at openjdk.org  Tue Mar 18 06:49:07 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Mar 2025 06:49:07 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v2]
In-Reply-To: <Mst3L1htYJ0KZ1bCONBqEp48DuXHGg_S91oV4gq7g-k=.46ca2984-446d-432c-b835-9946025cf587@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <3epbllurOgsccReVbsttnH97NTCeHQXlhpqhLGSpAiU=.60629a3b-f3e1-4ce2-b6b6-5172436adf07@github.com>
 <c_nqZye9JlUVAtf0kgCq2QH2etN1g_OP9UArGEFT4xw=.a2765b61-2c83-45ae-8d50-417a9a8616c0@github.com>
 <Mst3L1htYJ0KZ1bCONBqEp48DuXHGg_S91oV4gq7g-k=.46ca2984-446d-432c-b835-9946025cf587@github.com>
Message-ID: <Tcc81hTWKG0odB0oAgjJiSqv0F3dt7VWVO8C6z8_esQ=.1c4403cd-bbfe-4a87-9897-7b2bf55236d5@github.com>

On Tue, 18 Mar 2025 05:55:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > If there are no rows then most probably `selectAll` will select `column headers`.. right?
> > I don't understand why do we want to select all columns if there are no rows or vice-versa ? Does it return any useful details?
> > Few changes can be done in the fix and test code (if fix is applicable)
> 
> Spec says "Selects all rows, columns, and cells in the table." so it should mean we should select all available cells in the "table" and not header, which is separately handled via JTableHeader..

Ok.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24025#issuecomment-2731855186

From abhiscxk at openjdk.org  Tue Mar 18 06:49:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Mar 2025 06:49:12 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v3]
In-Reply-To: <-5fmMci4f9egaF8B1SZcZTGrrG37VjwrPg6Y12U0-qY=.00942812-345c-4627-81e4-3070e8233495@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <-5fmMci4f9egaF8B1SZcZTGrrG37VjwrPg6Y12U0-qY=.00942812-345c-4627-81e4-3070e8233495@github.com>
Message-ID: <n5ARsKffiBTf4iKLj9EI0QzoAJo3hyDa9IKsLLaRB8g=.04ad06f8-d2a0-4485-8bd2-d5a20a993408@github.com>

On Tue, 18 Mar 2025 05:59:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code duplication removed, subtest added

src/java.desktop/share/classes/javax/swing/JTable.java line 2154:

> 2152:         int oldAnchor = getAdjustedIndex(selModel.getAnchorSelectionIndex(), true);
> 2153: 
> 2154:         setRowSelectionInterval(0, rowCount-1);

Suggestion:

        setRowSelectionInterval(0, rowCount - 1);

src/java.desktop/share/classes/javax/swing/JTable.java line 2168:

> 2166:         int oldAnchor = getAdjustedIndex(selModel.getAnchorSelectionIndex(), false);
> 2167: 
> 2168:         setColumnSelectionInterval(0, columnCount-1);

Suggestion:

        setColumnSelectionInterval(0, columnCount - 1);

src/java.desktop/share/classes/javax/swing/JTable.java line 2182:

> 2180:         int oldLead;
> 2181:         int oldAnchor;
> 2182:         ListSelectionModel selModel;

Unused variable oldLead, oldAnchor, selModel

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 45:

> 43: 
> 44:     private static void testColumnSelect() {
> 45:         boolean colSelNoRow, colSelWithRow;

Can be declare on separate lines.

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 62:

> 60:         // After selectAll(), I would expect all columns to be selected, no matter
> 61:         // whether there are rows or not.
> 62:         System.out.println("Column 0 is selected: "+ colSelNoRow);

Suggestion:

        System.out.println("Column 0 is selected: " + colSelNoRow);

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 69:

> 67: 
> 68:         colSelWithRow = table.isColumnSelected(0);
> 69:         System.out.println("Column 0 is selected: "+ colSelWithRow);

Suggestion:

        System.out.println("Column 0 is selected: " + colSelWithRow);

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 77:

> 75: 
> 76:     private static void testRowSelect() {
> 77:         boolean rowSelNoColumn, rowSelWithColumn;

Can be declare on separate lines.

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 84:

> 82:         JTable table = new JTable(data);
> 83: 
> 84:         // columns can be selected

Suggestion:

        // rows can be selected

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 94:

> 92:         // After selectAll(), I would expect all rows to be selected, no matter
> 93:         // whether there are columns or not.
> 94:         System.out.println("Row 0 is selected: "+ rowSelNoColumn);

Suggestion:

        System.out.println("Row 0 is selected: " + rowSelNoColumn);

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 100:

> 98: 
> 99:         rowSelWithColumn = table.isRowSelected(0);
> 100:         System.out.println("Row 0 is selected: "+ rowSelWithColumn);

Suggestion:

        System.out.println("Row 0 is selected: " + rowSelWithColumn);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000310414
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000311674
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000311989
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000312998
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000316147
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000316380
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000317018
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000317445
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000317739
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000317890

From psadhukhan at openjdk.org  Tue Mar 18 06:56:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Mar 2025 06:56:57 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/b2a8c8e1..c8451558

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=02-03

  Stats: 15 lines in 2 files changed: 2 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Tue Mar 18 06:56:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Mar 2025 06:56:57 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v3]
In-Reply-To: <n5ARsKffiBTf4iKLj9EI0QzoAJo3hyDa9IKsLLaRB8g=.04ad06f8-d2a0-4485-8bd2-d5a20a993408@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <-5fmMci4f9egaF8B1SZcZTGrrG37VjwrPg6Y12U0-qY=.00942812-345c-4627-81e4-3070e8233495@github.com>
 <n5ARsKffiBTf4iKLj9EI0QzoAJo3hyDa9IKsLLaRB8g=.04ad06f8-d2a0-4485-8bd2-d5a20a993408@github.com>
Message-ID: <wdV5z1ZvS8iSZPj21f3OhVoGPcAB-bUKzk703zFYoY4=.67e405d3-2119-42c4-a757-69b0fc231a62@github.com>

On Tue, 18 Mar 2025 06:39:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code duplication removed, subtest added
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 2182:
> 
>> 2180:         int oldLead;
>> 2181:         int oldAnchor;
>> 2182:         ListSelectionModel selModel;
> 
> Unused variable oldLead, oldAnchor, selModel

removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2000328218

From mvs at openjdk.org  Tue Mar 18 06:59:07 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 18 Mar 2025 06:59:07 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <xoe9TGiQ-mAaEOnunbGt8yjBBAwa8ncqMQGyIBZehS8=.c3a72e5c-2706-4732-a95b-2d3c3d082bc9@github.com>

On Sun, 16 Mar 2025 08:56:24 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

Any volunteer for a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24072#issuecomment-2731880339

From abhiscxk at openjdk.org  Tue Mar 18 07:08:09 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Mar 2025 07:08:09 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
Message-ID: <d0AoE1x-Jj9xbL23Lp6ASZEJNsEGnV35Hl8a533qEYU=.ea01edad-7d21-451d-aadb-9618a6720bed@github.com>

On Tue, 18 Mar 2025 06:56:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

Current changes look good now.

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24025#pullrequestreview-2693234914

From shade at openjdk.org  Tue Mar 18 08:47:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 08:47:18 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <h5IPLDyLFqKAQELwQhWXhsgJx2t2kRoTJfxP6z2FnAY=.b712d64d-fb82-4551-ba3d-734b4596d1b7@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

Looking at this from the GC perspective...

What I am concerned here is really hooking up to "observed" heap stats. It guesses what GC does, and it is not great for the non-core JDK code. Checking for `maxMemory` alone might be fine, it is straight up `CollectedHeap::max_capacity`, which is essentially Xmx. But checking on `freeMemory` is basically throwing ourselves at the mercy of GC doing prompt reclamations. I can envision the scenario where a super-lazy GC would delay the collection until the single-digit% of total memory is free, but the actual GC cycle would throw away a lot of garbage.

I.e. I think I can construct the case where:


maxMemory = 2048M (Xmx)
totalMemory = 2048M (actually expanded heap size)
freeMemory = 64M (lazy GC)
<floating garbage> = (2G - delta)


Then:


long maximumHeapSize = (long) ((Runtime.getRuntime().maxMemory() -
                    (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())) * 0.9); 


...computes to measly 57M (check my math) and thus throws OOME prematurely.

So, I would say:
 1. Throw OOME on > maxMemory, because there is no practical way GC would be able to satisfy the allocation.
 2. Proceed to allocate otherwise, and let GC to either deal with it -- by triggering cleanup -- or throw OOME to indicate a failure of doing so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2732136470

From jkern at openjdk.org  Tue Mar 18 10:47:07 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 10:47:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
 <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
Message-ID: <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>

On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Looks like this variable is misspelled (missing "S").
>> 
>> DEPS := $(STATIC_LIB_FILE), \
>> 
>> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.
>
> Ups, thank you for giving me the 'S'. But nevertheless if I make with
> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

I did not get the SetupExecute function, even if I strip it down to a simple example

$(eval $(call SetupExecute, generate_export_list, \
    INFO := Generating export list for static libs, \
    DEPS := /path/libjli.a, \
    OUTPUT_FILE := /path/libjli.a.exp, \
    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
))

$(java): $(STATIC_LIB_FILES) /path/libjli.a.exp

I still get
`gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
`
Why does make not recognize, that the rule is in my
 `call SetupExecute, generate_export_list,`
macro?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000736109

From jwaters at openjdk.org  Tue Mar 18 11:35:17 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 18 Mar 2025 11:35:17 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <kM3dEzHhdbQyraiWxsUe2Xjy898dz1YJ-jGL3kHGMB8=.c5e25c80-d7c4-4981-ab3c-d890a4b17bbf@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

Keep open please

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2732871765

From ihse at openjdk.org  Tue Mar 18 12:12:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:12:13 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <VFAbug4SzdYGjO_SeLsr2OGWch5d7lQfEfSMXNp31do=.365c784a-93d4-4c39-85ed-548e24fc7984@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 112:

> 110: $(STATIC_LIB_EXPORT_FILES): $(STATIC_LIB_FILES)
> 111: 	$(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@
> 112: #$(eval $(call SetupExecute, generate_export_list, \

I think there are multiple issues at hand here.

1) There is a current bug in SetupExecute that requires you to execute any command with redirection in a subshell, that is, you need to wrap the COMMAND in `(` ... `)`.

2) STATIC_LIB_EXPORT_FILES is not a single file, it is a list of file. So what you have written above is not a single recipe, it is a multi-file recipe template. But it's weird, it will evaluate to like:
libjvm.so.exp libjava.so.exp libjli.so.exp: libjvm.so libjava.so libjli.so
which makes no sense, since you do not need to have a dependency to  libjava.so libjli.so for libjvm.so.exp.

What you really want is to have a single rule per library that creates the corresponding exp file for that library, and which is dependent only on that library.

Or, possibly, you can just concatenate the export of all libraries into a single file. It will make the final linker command line simpler, since you would only need a single `-Wl,-bE:<the export file>`, but it is potentially worse for an incremental rebuild, since all native libraries need to be re-scanned for exported functions.

My preferred solution would to make this explicit by creating a loop over STATIC_LIB_FILES, and doing a SetupExecute for each such lib. Then you can get it down to something like:

$(foreach lib, $(STATIC_LIB_FILES), \
  $(eval $(call SetupExecute, generate_export_list_$(lib),
      INFO := Generating export list for $(lib), \
      DEPS :=  $(lib), \
      OUTPUT_FILE := $(lib).exp, \
      COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | sort -u > $(lib).exp ), \
  ) \
  $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \
)

make/StaticLibs.gmk line 136:

> 134: ))
> 135: 
> 136: $(java): $(STATIC_LIB_FILES) $(if $(call isTargetOs, aix), $(STATIC_LIB_EXPORT_FILES))

This is just clunky. Leave the original line, and add:

ifeq ($(call isTargetOs, aix), true)
  $(java): $(STATIC_LIB_EXPORT_FILES)
endif

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000901430
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000904229

From ihse at openjdk.org  Tue Mar 18 12:15:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:15:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
 <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
 <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>
Message-ID: <SQgrvqJ1O64cqR7aL_pXoimBpmB2Yy2dSwCz_gc0_qk=.a5eaf8ff-02a5-48d2-81da-b737cb8ef95d@github.com>

On Tue, 18 Mar 2025 10:44:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Ups, thank you for giving me the 'S'. But nevertheless if I make with
>> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list
>
> I did not get the SetupExecute to function, even if I strip it down to a simple example
> 
> $(eval $(call SetupExecute, generate_export_list, \
>     INFO := Generating export list for static libs, \
>     DEPS := /path/libjli.a, \
>     OUTPUT_FILE := /path/libjli.a.exp, \
>     COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
> ))
> 
> $(java): $(STATIC_LIB_FILES) /path/libjli.a.exp
> 
> I still get
> `gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
> `
> Why does make not recognize, that the rule is in my
>  `call SetupExecute, generate_export_list,`
> macro?

This is likely due to the missing subshell. There is an enhancement filed to fix this automatically but it has unfortunately not been prioritized: https://bugs.openjdk.org/browse/JDK-8233115

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000909674

From abaya at openjdk.org  Tue Mar 18 13:49:10 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 18 Mar 2025 13:49:10 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <5Ld_eZtMc8k6o-f2ql-bDZxOwHKWu4r6tVKWGNhyK6A=.fac27063-f1a7-4607-86cb-152df79ec782@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>
 <5Ld_eZtMc8k6o-f2ql-bDZxOwHKWu4r6tVKWGNhyK6A=.fac27063-f1a7-4607-86cb-152df79ec782@github.com>
Message-ID: <KcBclLYQ8zAc2ZDCkzKTAgScmVJQfyREPM9F0QeEdeM=.9b17d10e-16de-4ff3-ae6b-e930ed7e78f9@github.com>

On Wed, 26 Feb 2025 18:35:31 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Enhancment step 3
>>  - Enhancement - step 2
>>  - enhancement - step 1
>
> src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java line 983:
> 
>> 981:         Image img = getLWGC().createAcceleratedImage(getTarget(), scaledWidth, scaledHeight);
>> 982:         if(ScaleX == 1 || ScaleY == 1)
>> 983:             return img;
> 
> Should this be `&&` instead of `||`?

Yes It should

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r2001090575

From duke at openjdk.org  Tue Mar 18 15:19:06 2025
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Mar 2025 15:19:06 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <O3dew-LzNUZm_tspRcQO1bQmwjIv8rLYhAwwqDYu9CI=.5b5c2946-4e69-49df-9259-7ccf6b2663a9@github.com>

On Sun, 16 Mar 2025 08:56:24 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

LGTM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24072#issuecomment-2733631990

From jkern at openjdk.org  Tue Mar 18 16:18:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:18:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v2]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <fhpXOopQR_7IjqVcK6H0DdpeeFVf_wAS48NzS_hbIBU=.a726fb32-a173-4680-a3f0-19da5670bacf@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  following Magnus proposals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/48668be6..6e76f114

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00-01

  Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From jkern at openjdk.org  Tue Mar 18 16:21:14 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:21:14 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <IHrNDLGrQ5s-8yrsiXRmqLOyo6K9RuSE_5AXkfgDSx8=.ce6b3994-d912-4ddf-b654-6e7f5e6cc6d7@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

I applied all of magnus proposals, but I still get
`gmake[3]: *** No rule to make target '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/native/java.base/libverify/static/libverify.a.exp', needed by '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/static-native/launcher/java'.  Stop.`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2733873645

From honkar at openjdk.org  Tue Mar 18 17:10:14 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 18 Mar 2025 17:10:14 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <nseVVyZSwxr2TtCJ9NQOzn5bRLC2qhGTzB2xthKFgQo=.5d393b34-fb1f-45df-a64d-a96b3544f9a5@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
 <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
 <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>
 <nseVVyZSwxr2TtCJ9NQOzn5bRLC2qhGTzB2xthKFgQo=.5d393b34-fb1f-45df-a64d-a96b3544f9a5@github.com>
Message-ID: <yPdaWzVqxjjx1ew6xYfdsZ6fD9TflLTAZinrXdjjhhM=.2e6abdca-2493-4bea-9034-f436eb4a18e7@github.com>

On Fri, 14 Mar 2025 01:24:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
>>> 
>>> But it also has its own disadvantages...
>> 
>> @mrserb  You mentioned earlier that there are disadvantages of using java properties approach, so using builtIn flag would be better then, correct?
>> 
>>>  I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps.
>> 
>> I wasn't able to find the previous discussion thread so I'm not sure what are the disadvantages. Can you please explain?
>
> If we start from the beginning. The problem we are trying to solve is preventing changes to our standard profiles so that we can be sure one part of the application does not unexpectedly affect another. This could be achieved in two ways:
> 
> - Throw an exception if a standard profile is modified
> - Ignore the requested change and use the default profile properties as is
> 
> For new applications, we could require always cloning the color profile before modification (via the updated specification); otherwise, the application must always check whether the profile is built-in or not.
> 
> However, for older applications, these two solutions lead to different outcomes:
> 
> - Throwing the new exception will most likely break the application
> - Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate
> 
> The next question is: how big of an issue is this inaccuracy? For example, if we have an sRGB profile that rejects some modifications, we would still try to produce valid sRGB data during conversion.
> 
> So the trade-off is: broken applications vs. inaccurate (but still ICC-spec-compliant) conversions.
> 
> PS: By the way, why do we want to enforce this rule only for built-in profiles? Why can't a library create similar profiles and mark them as "read-only"?

@mrserb 

> The app may obtain a profile from some place and use it for some images or pixels. Then, if the app wants to tweak the rendering intent for some reason, what should it do?
> 
> Clone the profile and then change the intent?

The app would follow the above approach.
There is only one step extra with this fix - creating a copy of built-in profile and then modifying it.


byte[] builtInData = ICC_Profile.getInstance(ColorSpace.CS_sRGB).getData(); // get the byte array representation of BuiltIn- profile
ICCProfile newProfile = ICC_Profile.getInstance(builtInData) // create a new profile
newProfile.setData(...)



> However, for older applications, these two solutions lead to different outcomes:
> Throwing the new exception will most likely break the application

The chances of breaking an existing application is minimal since API usage for setData() was checked and not many were found and moreover they were not called on built-in profiles.


>Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate

This does not seem viable because the user in unaware as to whether setData() worked or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2001540142

From kizune at openjdk.org  Tue Mar 18 17:13:16 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Mar 2025 17:13:16 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <i-XY_G_ryW44oe16zHoWVDtKUEPF-jqbSX1uaWjJPSg=.566a2840-b032-4fb3-a234-d74278c89e25@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

> * Throw OOME on > maxMemory, because there is no practical way GC would be able to satisfy the allocation.
> * Proceed to allocate otherwise, and let GC to either deal with it -- by triggering cleanup -- or throw OOME to indicate a failure of doing so.

The idea of the fix is strictly specific to the code in the sound bank loader. It takes into account that
1. To avoid huge memory allocations in one go the code grabs memory incrementally as it renders the audio data
2. It is not practical to load sound bank that requires a lot of memory to be freed by GC because what are you going to do next? To use loaded sound bank to render MIDI you will need another large pool of memory comparable to the amount allocated to the sound bank itself so 90% of the available memory is very conservative.

Bottom line - i do not think that catching OOME and re-throwing it as a checked exception down to the client code is a good idea and gradually allocating more than 90% of currently available memory - potentially suffocating other threads - i would say not the greatest idea either. In this particular scenario. Not a universal solution but for this specific application i would rather do that check before i go into the gluttony mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734075145

From shade at openjdk.org  Tue Mar 18 17:34:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 17:34:09 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <i-XY_G_ryW44oe16zHoWVDtKUEPF-jqbSX1uaWjJPSg=.566a2840-b032-4fb3-a234-d74278c89e25@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
 <i-XY_G_ryW44oe16zHoWVDtKUEPF-jqbSX1uaWjJPSg=.566a2840-b032-4fb3-a234-d74278c89e25@github.com>
Message-ID: <yOaLiddkp3D5Wb3kGrVl5DaR7usR56X4HPrNfSJTrog=.bd0af16a-2dae-46bd-9239-316186ad3abf@github.com>

On Tue, 18 Mar 2025 17:10:58 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> It is not practical to load sound bank that requires a lot of memory to be freed by GC because what are you going to do next? To use loaded sound bank to render MIDI you will need another large pool of memory comparable to the amount allocated to the sound bank itself so 90% of the available memory is very conservative.

Sounds like (pun intended) my example did not land :)

Let's continue with my example. In that example, I think we established the current check would throw OOME when sound bank in >57M. Suppose the bank was 128M. In my example, there is 2G of floating garbage in the heap. Once GC hits, it is likely a lot of that floating garbage gets cleaned up. Suppose GC managed to clean up 1G. Cool, we need more memory -- "large pool of memory comparable to the amount allocated to the sound bank itself" -- so another 128M? Now the heap has 1024M+2*128M = 1280M out of total 2048M. Very comfortable heap conditions! But instead, we are throwing OOME. I think this behavior goes against common sense.

Note that arbitrarily lazy GC may end up pushing the checked limit arbitrarily low, and the code would start throwing OOME on very small sound banks, AFAICS. In other words, this reliability check, as written now, is actively hostile to reliability!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734139561

From shade at openjdk.org  Tue Mar 18 17:40:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 17:40:09 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
Message-ID: <8Xid5MjxUHhFtyq3zfjMwl-ojZJaWC2S7LY0GPsTsu4=.0b913901-5164-44cd-8a95-0290fe0c0ed9@github.com>

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

I emphasize the problem is with relying on `freeMemory`. That thing is not trustworthy to make the call you want to make. Only GC knows how much memory there is _actually free_, and it often knows only after attempting a GC cycle. If you want to get some headroom for both sound bank allocation and the subsequent rendering, then maybe the limit should be `maxMemory / <const>`, where divisor is some small integer. But `freeMemory` should not be in the equation if you want reliability, AFAIU.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734159467

From aivanov at openjdk.org  Tue Mar 18 17:56:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Mar 2025 17:56:10 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <UMZR7z6HLgkchOLaunywMoNtnoaVeRKha5Ydn-9HaCw=.20b0a577-2a8f-46a6-b241-18f0258434e8@github.com>

On Sun, 16 Mar 2025 08:56:24 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

Bump the copyright year, too.

test/jdk/java/awt/Desktop/MailTest.java line 63:

> 61:             PassFailJFrame.forcePass();
> 62:             return;
> 63:         }

A better and could be to move these checks into the `main` method and return right away without using `PassFailJFrame` at all. This would avoid creating and showing the UI before immediately disposing of it.

A `jtreg.SkippedException` could be thrown instead of passing the test ? this way we'll be able to know if the test is never in an environment where it does perform the test actions.

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24072#pullrequestreview-2695655305
PR Review Comment: https://git.openjdk.org/jdk/pull/24072#discussion_r2001645783

From mvs at openjdk.org  Tue Mar 18 18:37:09 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 18 Mar 2025 18:37:09 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v2]
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <Ge5xqaL0Rh9UeUFzzKBhP2vnoIAeQEM1xELBiQxQ_14=.908eb12c-619c-4a1a-93ea-382a4e7950f0@github.com>

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Added SkippedException instead of forcePass(), Changed the position of imports, formatting changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24072/files
  - new: https://git.openjdk.org/jdk/pull/24072/files/d2f8e394..502d659b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24072&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24072&range=00-01

  Stats: 42 lines in 1 file changed: 20 ins; 19 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24072/head:pull/24072

PR: https://git.openjdk.org/jdk/pull/24072

From mvs at openjdk.org  Tue Mar 18 18:37:11 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 18 Mar 2025 18:37:11 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v2]
In-Reply-To: <UMZR7z6HLgkchOLaunywMoNtnoaVeRKha5Ydn-9HaCw=.20b0a577-2a8f-46a6-b241-18f0258434e8@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
 <UMZR7z6HLgkchOLaunywMoNtnoaVeRKha5Ydn-9HaCw=.20b0a577-2a8f-46a6-b241-18f0258434e8@github.com>
Message-ID: <TiXRMCU7ViUcMfixHR0XdhewN46qQosxNSwlWkuXQhE=.2ced8e34-2d21-46c2-8206-6cecd9d7f67b@github.com>

On Tue, 18 Mar 2025 17:52:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed : Added SkippedException instead of forcePass(), Changed the position of imports, formatting changes
>
> test/jdk/java/awt/Desktop/MailTest.java line 63:
> 
>> 61:             PassFailJFrame.forcePass();
>> 62:             return;
>> 63:         }
> 
> A better and could be to move these checks into the `main` method and return right away without using `PassFailJFrame` at all. This would avoid creating and showing the UI before immediately disposing of it.
> 
> A `jtreg.SkippedException` could be thrown instead of passing the test ? this way we'll be able to know if the test is never in an environment where it does perform the test actions.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24072#discussion_r2001737399

From aivanov at openjdk.org  Tue Mar 18 20:41:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Mar 2025 20:41:08 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v2]
In-Reply-To: <Ge5xqaL0Rh9UeUFzzKBhP2vnoIAeQEM1xELBiQxQ_14=.908eb12c-619c-4a1a-93ea-382a4e7950f0@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
 <Ge5xqaL0Rh9UeUFzzKBhP2vnoIAeQEM1xELBiQxQ_14=.908eb12c-619c-4a1a-93ea-382a4e7950f0@github.com>
Message-ID: <Yq9Shep_S4NCcW5zX2cK-5NUxRhtvE-b-DiR-3dGzBk=.d7de3f2c-e50d-4e62-a35f-b533dcc1b188@github.com>

On Tue, 18 Mar 2025 18:37:09 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> **Issue**
>> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
>> 
>> **Reason**
>> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
>> 
>> **Fix**
>> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
>> 
>> **Testing**
>> This is a manual test, so it is tested locally and found to be working fine.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Added SkippedException instead of forcePass(), Changed the position of imports, formatting changes

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/Desktop/MailTest.java line 106:

> 104:         if (!desktop.isSupported(Desktop.Action.MAIL)) {
> 105:             String errorMessage = "Action.MAIL is not supported.";
> 106:             throw new SkippedException(errorMessage);

Since the error message is used only once, you can inline the message to the constructor.

You may inline `Desktop.getDesktop().isSupported(Desktop.Action.MAIL)` without introducing a local variable if you like.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24072#pullrequestreview-2696204855
PR Review Comment: https://git.openjdk.org/jdk/pull/24072#discussion_r2001964021

From kizune at openjdk.org  Tue Mar 18 21:14:09 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Mar 2025 21:14:09 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError [v4]
In-Reply-To: <yOaLiddkp3D5Wb3kGrVl5DaR7usR56X4HPrNfSJTrog=.bd0af16a-2dae-46bd-9239-316186ad3abf@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <iO9Sk2P-m65P2uNGfQUXOqGVBNPLEpQpY6MGowAm0D0=.0d2486d2-311e-4e1f-b41c-5a461b975d29@github.com>
 <i-XY_G_ryW44oe16zHoWVDtKUEPF-jqbSX1uaWjJPSg=.566a2840-b032-4fb3-a234-d74278c89e25@github.com>
 <yOaLiddkp3D5Wb3kGrVl5DaR7usR56X4HPrNfSJTrog=.bd0af16a-2dae-46bd-9239-316186ad3abf@github.com>
Message-ID: <h3muk_4zQOE9hCn_ZKC_cz26vOrgJUCqwoFAhQMH_0Q=.c5c78f1b-fd50-4f34-8412-1c47fd3a0b69@github.com>

On Tue, 18 Mar 2025 17:31:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Sounds like (pun intended) my example did not land :)

No, i totally understand your point - it is quite possible that calculating currently available memory size might be detrimental because of the possibility that GC might free up that space when we actually request it - but this is not a critical functionality and the potential damage of suffocating VM with the repeated requests of +1M for potentially 4G sound bank - when we do know that we only have 3G of free memory - heavily outweighs the potential border-line case when we can load the sound bank - maybe - if GC will finds the resources but we were a little paranoid and throwing a checked exception that customer will take into account and the execution of the main program may continue.

Conclusion: i know the risks and i am willing to take them, reliability concern is noted but it is the case where being cautious and a tiny bit paranoid makes more sense. Again, for this exact use case. Plus there is a workaround: user can just increase the maximum heap size if he finds that some specific sound bank causes this kind of a problem. If you find out that you need to generate 4G sound bank - add 4G of heap and you will be fine just fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734741051

From mvs at openjdk.org  Wed Mar 19 02:41:48 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 19 Mar 2025 02:41:48 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v3]
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <XH4i7edQ1U_IISVFill0SfiqMnAdj-7WwK2gNCXgKSY=.ce381471-4fd5-423e-8976-51c2beff1430@github.com>

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Removed unwanted variable, made the error message inline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24072/files
  - new: https://git.openjdk.org/jdk/pull/24072/files/502d659b..650f5885

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24072&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24072&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24072/head:pull/24072

PR: https://git.openjdk.org/jdk/pull/24072

From mvs at openjdk.org  Wed Mar 19 02:41:48 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 19 Mar 2025 02:41:48 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v2]
In-Reply-To: <Yq9Shep_S4NCcW5zX2cK-5NUxRhtvE-b-DiR-3dGzBk=.d7de3f2c-e50d-4e62-a35f-b533dcc1b188@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
 <Ge5xqaL0Rh9UeUFzzKBhP2vnoIAeQEM1xELBiQxQ_14=.908eb12c-619c-4a1a-93ea-382a4e7950f0@github.com>
 <Yq9Shep_S4NCcW5zX2cK-5NUxRhtvE-b-DiR-3dGzBk=.d7de3f2c-e50d-4e62-a35f-b533dcc1b188@github.com>
Message-ID: <RGfH6iqWZVBS-rL5p09PmtcKZehRrscxpsrmqVgBnKw=.b380bf14-a8c5-4b61-9272-8ffb142a29df@github.com>

On Tue, 18 Mar 2025 20:37:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed : Added SkippedException instead of forcePass(), Changed the position of imports, formatting changes
>
> test/jdk/java/awt/Desktop/MailTest.java line 106:
> 
>> 104:         if (!desktop.isSupported(Desktop.Action.MAIL)) {
>> 105:             String errorMessage = "Action.MAIL is not supported.";
>> 106:             throw new SkippedException(errorMessage);
> 
> Since the error message is used only once, you can inline the message to the constructor.
> 
> You may inline `Desktop.getDesktop().isSupported(Desktop.Action.MAIL)` without introducing a local variable if you like.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24072#discussion_r2002311621

From tr at openjdk.org  Wed Mar 19 06:08:14 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 19 Mar 2025 06:08:14 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
Message-ID: <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>

On Tue, 18 Mar 2025 06:56:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

src/java.desktop/share/classes/javax/swing/JTable.java line 2162:

> 2160:     }
> 2161: 
> 2162:     private void selectColumns(TableColumnModel  columnModel, int columnCount) {

Should we check whether column selection is allowed before selecting columns? Because by default only row selection is enabled.

src/java.desktop/share/classes/javax/swing/JTable.java line 2188:

> 2186:         }
> 2187:         if (rowCount > 0 && columnCount > 0) {
> 2188:             selectRows(selectionModel, rowCount);

Any reason for passing selectionModel(s) as parameters ? Anyhow they are class variables and can be used directly right ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002483403
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002482305

From psadhukhan at openjdk.org  Wed Mar 19 06:22:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 06:22:47 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v5]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <EVjeJn2Dgjnx660bXjwuKkSgWVdpXiXmTB0HkqexIhU=.eb692e54-76c2-4950-a779-2f17d781ae97@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use local var for selectionModel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/c8451558..144e7bdc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=03-04

  Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Wed Mar 19 06:22:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 06:22:47 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
Message-ID: <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>

On Wed, 19 Mar 2025 06:05:01 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Formatting
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 2162:
> 
>> 2160:     }
>> 2161: 
>> 2162:     private void selectColumns(TableColumnModel  columnModel, int columnCount) {
> 
> Should we check whether column selection is allowed before selecting columns? Because by default only row selection is enabled.

No, as told earlier, selectAll selects all cells...
WHere do you see only row selection is enabled? In SwingSet2 JTable, if you do ctrl+A which is equivalent to selectAll, all cells gets selected..

> src/java.desktop/share/classes/javax/swing/JTable.java line 2188:
> 
>> 2186:         }
>> 2187:         if (rowCount > 0 && columnCount > 0) {
>> 2188:             selectRows(selectionModel, rowCount);
> 
> Any reason for passing selectionModel(s) as parameters ? Anyhow they are class variables and can be used directly right ?

Yes, good catch..we need to use local variable as done in old code and not modify the class variables..Modified to store the instance variable in local and use that..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002496054
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002494510

From tr at openjdk.org  Wed Mar 19 07:26:07 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 19 Mar 2025 07:26:07 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
Message-ID: <UXlYKl4uzaWbgyCWIPazW8k1gX2A9XR_Ae-n7Hs6Tg0=.b7076f31-91ec-4e71-8e6e-2732d8514b74@github.com>

On Wed, 19 Mar 2025 06:17:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 2188:
>> 
>>> 2186:         }
>>> 2187:         if (rowCount > 0 && columnCount > 0) {
>>> 2188:             selectRows(selectionModel, rowCount);
>> 
>> Any reason for passing selectionModel(s) as parameters ? Anyhow they are class variables and can be used directly right ?
>
> Yes, good catch..we need to use local variable as done in old code and not modify the class variables..Modified to store the instance variable in local and use that..

[Here](https://github.com/openjdk/jdk/blob/577ede73d8e916bac9050d3bee80d2f18cc833a7/src/java.desktop/share/classes/javax/swing/JTable.java#L5629)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002620303

From tr at openjdk.org  Wed Mar 19 07:33:10 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 19 Mar 2025 07:33:10 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
Message-ID: <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>

On Wed, 19 Mar 2025 06:19:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 2162:
>> 
>>> 2160:     }
>>> 2161: 
>>> 2162:     private void selectColumns(TableColumnModel  columnModel, int columnCount) {
>> 
>> Should we check whether column selection is allowed before selecting columns? Because by default only row selection is enabled.
>
> No, as told earlier, selectAll selects all cells...
> WHere do you see only row selection is enabled? In SwingSet2 JTable, if you do ctrl+A which is equivalent to selectAll, all cells gets selected..

[Here](https://github.com/openjdk/jdk/blob/577ede73d8e916bac9050d3bee80d2f18cc833a7/src/java.desktop/share/classes/javax/swing/JTable.java#L5629)

>> src/java.desktop/share/classes/javax/swing/JTable.java line 2188:
>> 
>>> 2186:         }
>>> 2187:         if (rowCount > 0 && columnCount > 0) {
>>> 2188:             selectRows(selectionModel, rowCount);
>> 
>> Any reason for passing selectionModel(s) as parameters ? Anyhow they are class variables and can be used directly right ?
>
> Yes, good catch..we need to use local variable as done in old code and not modify the class variables..Modified to store the instance variable in local and use that..

I didn't mean that, I meant the other way. This would still modify the class variable right? And why do you want to use local variable ? Since you are getting selectionIndex, I don't think local variable would be helpful here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002625512
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002629941

From psadhukhan at openjdk.org  Wed Mar 19 07:33:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 07:33:10 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
Message-ID: <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>

On Wed, 19 Mar 2025 07:26:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> No, as told earlier, selectAll selects all cells...
>> WHere do you see only row selection is enabled? In SwingSet2 JTable, if you do ctrl+A which is equivalent to selectAll, all cells gets selected..
>
> [Here](https://github.com/openjdk/jdk/blob/577ede73d8e916bac9050d3bee80d2f18cc833a7/src/java.desktop/share/classes/javax/swing/JTable.java#L5629)

ok..But selectAll selects all cells as per the spec Spec says "Selects all rows, columns, and cells in the table..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002627276

From psadhukhan at openjdk.org  Wed Mar 19 07:36:09 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 07:36:09 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
Message-ID: <1XP8LQ5GuqAqH6A4AteqTH7lebVpz8_dexjai58fXJM=.dc7ccc9a-f975-4217-a7d1-123eced9277f@github.com>

On Wed, 19 Mar 2025 07:30:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Yes, good catch..we need to use local variable as done in old code and not modify the class variables..Modified to store the instance variable in local and use that..
>
> I didn't mean that, I meant the other way. This would still modify the class variable right? And why do you want to use local variable ? Since you are getting selectionIndex, I don't think local variable would be helpful here.

THis is the way it was done previously where also the action was done on local var..please see previous code....the selectionIndex was obtained from selectionModel class var..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002635993

From psadhukhan at openjdk.org  Wed Mar 19 07:48:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 07:48:07 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>
Message-ID: <9bFWr4Z3PqZQMRatTqP2HUed92eIguFCi8VhYBdOJyI=.049b9051-f6ff-4a9e-9c4a-682c5e9717b3@github.com>

On Wed, 19 Mar 2025 07:28:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [Here](https://github.com/openjdk/jdk/blob/577ede73d8e916bac9050d3bee80d2f18cc833a7/src/java.desktop/share/classes/javax/swing/JTable.java#L5629)
>
> ok..But selectAll selects all cells as per the spec Spec says "Selects all rows, columns, and cells in the table..

In SwingSet2 JTable demo before the fix also, you can see only "rowSelection" is enabled, but selectAll selects all cells in the table so selectAll overrides that setting..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002653757

From tr at openjdk.org  Wed Mar 19 08:55:06 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 19 Mar 2025 08:55:06 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <9bFWr4Z3PqZQMRatTqP2HUed92eIguFCi8VhYBdOJyI=.049b9051-f6ff-4a9e-9c4a-682c5e9717b3@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>
 <9bFWr4Z3PqZQMRatTqP2HUed92eIguFCi8VhYBdOJyI=.049b9051-f6ff-4a9e-9c4a-682c5e9717b3@github.com>
Message-ID: <6CxorBzrnpT7W0v15NZHBgOzAnc2YnhXNxe0xE8uECo=.76292b3d-ea98-4041-840c-5643c8e1d590@github.com>

On Wed, 19 Mar 2025 07:45:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> ok..But selectAll selects all cells as per the spec Spec says "Selects all rows, columns, and cells in the table..
>
> In SwingSet2 JTable demo before the fix also, you can see only "rowSelection" is enabled, but selectAll selects all cells in the table so selectAll overrides that setting..

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002776987

From tr at openjdk.org  Wed Mar 19 08:55:07 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 19 Mar 2025 08:55:07 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <1XP8LQ5GuqAqH6A4AteqTH7lebVpz8_dexjai58fXJM=.dc7ccc9a-f975-4217-a7d1-123eced9277f@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <1XP8LQ5GuqAqH6A4AteqTH7lebVpz8_dexjai58fXJM=.dc7ccc9a-f975-4217-a7d1-123eced9277f@github.com>
Message-ID: <ke4OiKsCYAOYidu1OFUmPg17i612lA-IVtXUX563x1E=.43bbf649-7a53-4114-a775-180b27854f6a@github.com>

On Wed, 19 Mar 2025 07:33:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I didn't mean that, I meant the other way. This would still modify the class variable right? And why do you want to use local variable ? Since you are getting selectionIndex, I don't think local variable would be helpful here.
>
> THis is the way it was done previously where also the action was done on local var..please see previous code....the selectionIndex was obtained from selectionModel class var..
> 
>> And why do you want to use local variable ? I don't think local variable would be helpful here.
> 
> I disagree..Using class variable directly might cause synchronization issue which is mitigated by using local var..

I meant w.r.t modifications applied to class and local reference. If both are pointing to same variable you can minimise passing it as parameter in methods selectColumns/Rows. Just a suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2002776307

From perini.davide at dpsoftware.org  Wed Mar 19 10:45:54 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Wed, 19 Mar 2025 11:45:54 +0100
Subject: jpackage and Wix 5
In-Reply-To: <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>
References: <af28d9a1161adf30dcf0b2d180a02177@dpsoftware.org>
 <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>
Message-ID: <163dabab-ddb8-4029-bede-9bd3227851f4@dpsoftware.org>



Il 19/03/2025 11:19, Davide Perini ha scritto:
> I add some context:
>
> I installed wix 5 using the donet command globally,
> wix is in the path but when I try to run my jpackage command I get 
> this error:
>
> jpackage -i ./target --type exe --main-class 
> org.dpsoftware.JavaFXStarter --main-jar 
> FireflyLuciferin-jar-with-dependencies.jar --icon 
> ./data/img/luciferin_logo.ico
> ?--win-menu --win-menu-group Ambilight --copyright "Davide Perini" 
> --name "Firefly Luciferin"? --vendor DPsoftware --win-dir-chooser 
> --win-shortcut --win-per-user-install --win-shortcut 
> --win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
>
>
> java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none, 
> -intermediatefolder, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj, 
> -ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
> .wixext, -b, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\
> Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
> dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl, 
> -culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d, 
> JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d, 
> JpProductCode=e0be8901-8911-3da4
> -83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d, 
> JpAllowDowngrades=yes, -d, 
> JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin\Firefly Luciferin.exe, -d, JpAp
> pSizeKb=409283, -d, JpAppVersion=1.0, -d, 
> JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d, 
> JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d, 
> JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
> T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx 
>
> f, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
> age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi] 
> in 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin exited with 144 code
>
>
> Il 19/03/2025 10:12, Davide Perini ha scritto:
>>
>> Hi there,
>>
>> I'm using jpackage along with Wix3.
>>
>> The command I use to generate my .exe is:
>> ? ? ? ? ? jpackage -i ../../target --type exe --main-class 
>> org.dpsoftware.JavaFXStarter --main-jar 
>> FireflyLuciferin-jar-with-dependencies.jar --icon 
>> ../../data/img/java_fast_screen_capture_logo.ico --win-menu 
>> --win-menu-group Luciferin --copyright "Davide Perini" --name 
>> "Firefly Luciferin" ?--vendor DPsoftware --win-dir-chooser 
>> --win-shortcut --win-per-user-install --win-upgrade-uuid myuuid 
>> --app-version "${{steps.get-id.outputs.id}}" --win-shortcut 
>> --win-shortcut-prompt --java-options "-XX:+UseZGC 
>> -XX:+UseStringDeduplication -Xms64m -Xmx1024m 
>> --add-modules=jdk.incubator.vector"
>>
>> How can I move it to Wix5 using Java 24?
>>
>> Is there a guide/documentation that help in migrating from Wix 3 to 
>> Wix 5?
>>
>> Thanks
>> Davide
>>
>


From ngubarkov at openjdk.org  Wed Mar 19 11:29:42 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 19 Mar 2025 11:29:42 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride
Message-ID: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>

8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride

-------------

Commit messages:
 - 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride

Changes: https://git.openjdk.org/jdk/pull/24111/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352407
  Stats: 54 lines in 2 files changed: 17 ins; 35 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24111/head:pull/24111

PR: https://git.openjdk.org/jdk/pull/24111

From psadhukhan at openjdk.org  Wed Mar 19 12:03:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 12:03:08 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <ke4OiKsCYAOYidu1OFUmPg17i612lA-IVtXUX563x1E=.43bbf649-7a53-4114-a775-180b27854f6a@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <1XP8LQ5GuqAqH6A4AteqTH7lebVpz8_dexjai58fXJM=.dc7ccc9a-f975-4217-a7d1-123eced9277f@github.com>
 <ke4OiKsCYAOYidu1OFUmPg17i612lA-IVtXUX563x1E=.43bbf649-7a53-4114-a775-180b27854f6a@github.com>
Message-ID: <9Pe-oKKzgDE4hjAGOD2lHBRM8BHeCq0YuCBzsN3w1mw=.6b670497-efea-4bad-b69c-1af7e74fa0c1@github.com>

On Wed, 19 Mar 2025 08:52:08 GMT, Tejesh R <tr at openjdk.org> wrote:

>> THis is the way it was done previously where also the action was done on local var..please see previous code....the selectionIndex was obtained from selectionModel class var..
>> 
>>> And why do you want to use local variable ? I don't think local variable would be helpful here.
>> 
>> I disagree..Using class variable directly might cause synchronization issue which is mitigated by using local var..
>
> I meant w.r.t modifications applied to class and local reference. If both are pointing to same variable you can minimise passing it as parameter in methods selectColumns/Rows. Just a suggestion.

Thank you for your suggestion but I will like to keep it this way as it was done in previous code as even though they are pointing to same variable, directly modifying class instance variable is fraught with danger so its better to act on local var as it was done previously..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2003165834

From ngubarkov at openjdk.org  Wed Mar 19 13:06:56 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 19 Mar 2025 13:06:56 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride [v2]
In-Reply-To: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
Message-ID: <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>

> 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  The previous approach was wrong for non-pixel interleaving.
  
  Just align the buffer size to the pixel stride instead, should be better.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24111/files
  - new: https://git.openjdk.org/jdk/pull/24111/files/3a6e6638..af41b338

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24111&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24111&range=00-01

  Stats: 55 lines in 1 file changed: 38 ins; 15 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24111/head:pull/24111

PR: https://git.openjdk.org/jdk/pull/24111

From psadhukhan at openjdk.org  Wed Mar 19 13:30:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 13:30:42 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v6]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <0BAcwSXxkGYYaBdnmSw9xygil8rqZ_97HTlrA26isHQ=.c7e5d9cd-9cd5-4137-be1a-303ec2fe1867@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove param

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/144e7bdc..207c96fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=04-05

  Stats: 13 lines in 1 file changed: 2 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Wed Mar 19 13:30:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 13:30:42 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <9Pe-oKKzgDE4hjAGOD2lHBRM8BHeCq0YuCBzsN3w1mw=.6b670497-efea-4bad-b69c-1af7e74fa0c1@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <1XP8LQ5GuqAqH6A4AteqTH7lebVpz8_dexjai58fXJM=.dc7ccc9a-f975-4217-a7d1-123eced9277f@github.com>
 <ke4OiKsCYAOYidu1OFUmPg17i612lA-IVtXUX563x1E=.43bbf649-7a53-4114-a775-180b27854f6a@github.com>
 <9Pe-oKKzgDE4hjAGOD2lHBRM8BHeCq0YuCBzsN3w1mw=.6b670497-efea-4bad-b69c-1af7e74fa0c1@github.com>
Message-ID: <O9E5VMjOBfWeXLavSBGVd270k1GYn1OgME4UxHILp_o=.52eb1231-921f-4343-8962-c8a751b442ea@github.com>

On Wed, 19 Mar 2025 12:00:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I meant w.r.t modifications applied to class and local reference. If both are pointing to same variable you can minimise passing it as parameter in methods selectColumns/Rows. Just a suggestion.
>
> Thank you for your suggestion but I will like to keep it this way as it was done in previous code as even though they are pointing to same variable, directly modifying class instance variable is fraught with danger so its better to act on local var as it was done previously..

Modified to remove the param and made it more ocalised.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2003329004

From psadhukhan at openjdk.org  Wed Mar 19 13:49:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 13:49:29 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add check for rowselection and columnselection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/207c96fa..50c27140

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From psadhukhan at openjdk.org  Wed Mar 19 13:49:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Mar 2025 13:49:29 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <6CxorBzrnpT7W0v15NZHBgOzAnc2YnhXNxe0xE8uECo=.76292b3d-ea98-4041-840c-5643c8e1d590@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>
 <9bFWr4Z3PqZQMRatTqP2HUed92eIguFCi8VhYBdOJyI=.049b9051-f6ff-4a9e-9c4a-682c5e9717b3@github.com>
 <6CxorBzrnpT7W0v15NZHBgOzAnc2YnhXNxe0xE8uECo=.76292b3d-ea98-4041-840c-5643c8e1d590@github.com>
Message-ID: <SltYF2IPfsvDV9pIMvN6aDuxqDfDhVmhy81Ga5DLnxU=.f8535c7b-af22-4759-a0c9-abc1096bfde0@github.com>

On Wed, 19 Mar 2025 08:52:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In SwingSet2 JTable demo before the fix also, you can see only "rowSelection" is enabled, but selectAll selects all cells in the table so selectAll overrides that setting..
>
> Ok.

Added columnSelection check..SwingSet2 selectAll selection can be viewed as selecting all rows which can be perceived as selecting all cells, so to be safe added the check..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2003371971

From aivanov at openjdk.org  Wed Mar 19 14:47:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Mar 2025 14:47:09 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v3]
In-Reply-To: <XH4i7edQ1U_IISVFill0SfiqMnAdj-7WwK2gNCXgKSY=.ce381471-4fd5-423e-8976-51c2beff1430@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
 <XH4i7edQ1U_IISVFill0SfiqMnAdj-7WwK2gNCXgKSY=.ce381471-4fd5-423e-8976-51c2beff1430@github.com>
Message-ID: <8jfIHXoL_ObF9-GAF5cKfv5w9eKouMIgKSYXTVD-3Cs=.20345a03-7a85-4b7a-a277-9ab00c4ece51@github.com>

On Wed, 19 Mar 2025 02:41:48 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> **Issue**
>> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
>> 
>> **Reason**
>> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
>> 
>> **Fix**
>> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
>> 
>> **Testing**
>> This is a manual test, so it is tested locally and found to be working fine.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Removed unwanted variable, made the error message inline

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24072#pullrequestreview-2698785002

From duke at openjdk.org  Wed Mar 19 15:08:09 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Mar 2025 15:08:09 GMT
Subject: RFR: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported [v3]
In-Reply-To: <XH4i7edQ1U_IISVFill0SfiqMnAdj-7WwK2gNCXgKSY=.ce381471-4fd5-423e-8976-51c2beff1430@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
 <XH4i7edQ1U_IISVFill0SfiqMnAdj-7WwK2gNCXgKSY=.ce381471-4fd5-423e-8976-51c2beff1430@github.com>
Message-ID: <8xcJC1G_ANCkJCiLXfMJ9NdlrR6lzHoZl6fxznFVcVs=.bcfcce64-712e-439c-bec5-98b01d24cc43@github.com>

On Wed, 19 Mar 2025 02:41:48 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> **Issue**
>> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
>> 
>> **Reason**
>> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
>> 
>> **Fix**
>> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
>> 
>> **Testing**
>> This is a manual test, so it is tested locally and found to be working fine.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Removed unwanted variable, made the error message inline

@manukumarvs 
Your change (at version 650f58854165d8f4e0358e4433baa7bd9c8491c3) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24072#issuecomment-2736985916

From mvs at openjdk.org  Wed Mar 19 15:28:17 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 19 Mar 2025 15:28:17 GMT
Subject: Integrated: 8352109: java/awt/Desktop/MailTest.java fails in platforms
 where Action.MAIL is not supported
In-Reply-To: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
References: <q7pWLzH3R20S0lG2bNUFkAeAjSa-6-K0K-kUtEbonqs=.ae615d12-d208-4a20-94f8-e348dc8c5b65@github.com>
Message-ID: <j8TM6HyWQP-GfDmVEudaZlmPRA_r5neyaC10XdNVtGQ=.a959998b-d3a1-44fc-ade7-5f66b4e3daaf@github.com>

On Sun, 16 Mar 2025 08:56:24 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> **Issue**
> java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
> 
> **Reason**
> In `MailTest.java`, there is a condition check(`if (!desktop.isSupported(Desktop.Action.MAIL))`) which will force pass the test if the corresponding 'Action' is not supported by the platform. But, apparently, this is not working good and the code flow went past this and fails in desktop.mail() method with an UnsupportedOperationException. 
> 
> **Fix**
> Even though we are calling `PassFailJFrame.forcePass()` if the 'Action.MAIL' is unsupported, the PassFailJFrame just count downs a latch and the actual action will be taken later only(in `awaitAndCheck()`). But at the meantime, the desktop.mail() call gets executed in the constructor of MailTest() and it will result in an UnsupportedOperationException. So, the fix is to return from the constructor immediately if the operation is 'unsupported'.
> 
> **Testing**
> This is a manual test, so it is tested locally and found to be working fine.

This pull request has now been integrated.

Changeset: c7f33388
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7f333888be052aa37fe878bfc2785fc47fbeaaa
Stats:     37 lines in 1 file changed: 17 ins; 17 del; 3 mod

8352109: java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24072

From rmarchenko at openjdk.org  Wed Mar 19 17:15:19 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 19 Mar 2025 17:15:19 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
Message-ID: <E0pPIrYAFvc9_dxfpXYVwu5_Qesusbrz80X-_NWDxNw=.92d2f3a2-9597-414f-a699-2722119eed29@github.com>

On Fri, 28 Feb 2025 10:09:30 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments 2

I updated the PR description. Could you review, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2737443037

From kizune at openjdk.org  Wed Mar 19 20:08:17 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 19 Mar 2025 20:08:17 GMT
Subject: Integrated: 8350813: Rendering of bulky sound bank from MIDI sequence
 can cause OutOfMemoryError
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <CVZPEjX8fmVl57uXD38Iw_kQ8fY2cxUZN3o42oPI7kI=.3ee83678-4bed-4086-944b-0bdf81554999@github.com>

On Wed, 26 Feb 2025 22:26:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

This pull request has now been integrated.

Changeset: fcc2a242
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcc2a24291d499f7149debad1250903ddc369d91
Stats:     61 lines in 2 files changed: 60 ins; 0 del; 1 mod

8350813: Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError

Reviewed-by: honkar, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23814

From kizune at openjdk.org  Wed Mar 19 20:38:07 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 19 Mar 2025 20:38:07 GMT
Subject: RFR: 8347321: [ubsan] CGGlyphImages.m:553:30: runtime error: nan
 is outside the range of representable values of type 'unsigned long'
In-Reply-To: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
References: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
Message-ID: <gof84flu9kD3RaCmYMTWZqqRDp-hYt9XpVhZ3zc_3es=.7ac3ab9c-f061-4ac4-8226-076741cbc7ec@github.com>

On Mon, 3 Mar 2025 05:57:33 GMT, Phil Race <prr at openjdk.org> wrote:

> The font tests that fail use non-finite or NaN float values.
> In such cases, no visible rendering is expected and the NaNTransform test does pass with empty shapes, but we can filter out these invalid floats before they get to native.
> The macOS class that handles the font strike can check for these and replace them.
> Since you can't observe a difference unless you can get ubsan to work (not easy) and that is a build option, so not something we can use in testing, there' s no regression test update here.

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23855#pullrequestreview-2700128396

From psadhukhan at openjdk.org  Thu Mar 20 03:47:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 03:47:07 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v4]
In-Reply-To: <SltYF2IPfsvDV9pIMvN6aDuxqDfDhVmhy81Ga5DLnxU=.f8535c7b-af22-4759-a0c9-abc1096bfde0@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <ZmZB9Y71eLla_IDwmr9CKfQze0tbmh5biYhUAebW4_0=.890eda37-416c-4c4f-839f-6f0cca82b7a1@github.com>
 <215hIdFxykJt1JzhvGFYLulzKP-06sTf-Lzl2dq43N4=.a0869ee8-0a78-4e4c-8676-69cb4d94c0f7@github.com>
 <uEtGWopmIQ99qXpmFzWTUoIYkivBOj6EKLqu6zxOBac=.76095bcf-57b1-40cc-aa67-f3dee356d758@github.com>
 <LLFkziyy9KQ3pG1PNH6Ld4nbBMHvEAgLkDkGM4ssRgc=.ebcde2c1-2686-43b6-ac67-20d3a7bd0fb7@github.com>
 <vLV916e08YvXY9mZh0iQUnXJDn9ER8F4cO9yQDONImg=.50d8d53b-9db6-4375-8074-41f802f0ce27@github.com>
 <9bFWr4Z3PqZQMRatTqP2HUed92eIguFCi8VhYBdOJyI=.049b9051-f6ff-4a9e-9c4a-682c5e9717b3@github.com>
 <6CxorBzrnpT7W0v15NZHBgOzAnc2YnhXNxe0xE8uECo=.76292b3d-ea98-4041-840c-5643c8e1d590@github.com>
 <SltYF2IPfsvDV9pIMvN6aDuxqDfDhVmhy81Ga5DLnxU=.f8535c7b-af22-4759-a0c9-abc1096bfde0@github.com>
Message-ID: <YFONuzMGX1DmAJfGSBtbLklLt9AlyLqbA-hzTjug5lg=.6e7df128-b5c4-4727-91fe-fee51523bc84@github.com>

On Wed, 19 Mar 2025 13:46:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Added columnSelection check..SwingSet2 selectAll selection can be viewed as selecting all rows which can be perceived as selecting all cells, so to be safe added the check..

Moreover, It is seen that by unchecking "rowSelection" check selectAll didnt allow cell selection so it doesnt override the row/column selection-allowed setting..so added the columnSelectionAllowed check before selecting columns and similarly for rows..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004762807

From tr at openjdk.org  Thu Mar 20 05:17:09 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 20 Mar 2025 05:17:09 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
Message-ID: <KSaV95YsUgIfGdpDJaEStZoOLF-JWt5jxKtcpfOzEgs=.c757e912-566f-4fb1-b62f-94c13afd4d29@github.com>

On Wed, 19 Mar 2025 13:49:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add check for rowselection and columnselection

src/java.desktop/share/classes/javax/swing/JTable.java line 2190:

> 2188:         if (rowCount > 0 && columnCount > 0) {
> 2189:             selectRows(rowCount);
> 2190:             selectColumns(columnCount);

Here the checks are missing. Both row and column selection allowed check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004823571

From psadhukhan at openjdk.org  Thu Mar 20 05:17:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 05:17:10 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <KSaV95YsUgIfGdpDJaEStZoOLF-JWt5jxKtcpfOzEgs=.c757e912-566f-4fb1-b62f-94c13afd4d29@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
 <KSaV95YsUgIfGdpDJaEStZoOLF-JWt5jxKtcpfOzEgs=.c757e912-566f-4fb1-b62f-94c13afd4d29@github.com>
Message-ID: <w1vn3PZ3UZOH0M2BITny-4GeBfmGw_UhaZvoxrS2FmE=.82c22c78-8f10-4756-b927-3534570d05ab@github.com>

On Thu, 20 Mar 2025 05:12:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add check for rowselection and columnselection
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 2190:
> 
>> 2188:         if (rowCount > 0 && columnCount > 0) {
>> 2189:             selectRows(rowCount);
>> 2190:             selectColumns(columnCount);
> 
> Here the checks are missing. Both row and column selection allowed check.

I know but it is not there in the code before the fix too..THere's no bug raised for that in JBS so I would like to continue with that for now so that we dont get any difference in behavior..I added the check in the new code..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004825477

From tr at openjdk.org  Thu Mar 20 05:30:13 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 20 Mar 2025 05:30:13 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
Message-ID: <izczJrPYGaovmmAAGbQ22-SVpiDOyndKWIv-7UrPvBM=.8b5407de-a043-45f4-942b-4ff3546355ec@github.com>

On Wed, 19 Mar 2025 13:49:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add check for rowselection and columnselection

src/java.desktop/share/classes/javax/swing/JTable.java line 2198:

> 2196:             if (getColumnSelectionAllowed()) {
> 2197:                 selectColumns(columnCount);
> 2198:             }

Can we simplify the code from line 2188 - 2198, since the intension is to selectRows/Columns if its available.
`
if (rowCount > 0 ) { 

        if (getRowSelectionAllowed()) { 

                selectRows(rowCount);

            }

        } else if (columnCount > 0 ) {

            if (getColumnSelectionAllowed()) {

                selectColumns(columnCount);

            }`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004835032

From psadhukhan at openjdk.org  Thu Mar 20 05:35:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 05:35:13 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <izczJrPYGaovmmAAGbQ22-SVpiDOyndKWIv-7UrPvBM=.8b5407de-a043-45f4-942b-4ff3546355ec@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
 <izczJrPYGaovmmAAGbQ22-SVpiDOyndKWIv-7UrPvBM=.8b5407de-a043-45f4-942b-4ff3546355ec@github.com>
Message-ID: <0_pZrDJqhR16MLeXz1FN4JJ6T5CmPewZeaQ-wCljpok=.1822d3b6-7183-4997-8aaf-bc6702253e36@github.com>

On Thu, 20 Mar 2025 05:27:59 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add check for rowselection and columnselection
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 2198:
> 
>> 2196:             if (getColumnSelectionAllowed()) {
>> 2197:                 selectColumns(columnCount);
>> 2198:             }
> 
> Can we simplify the code from line 2188 - 2198, since the intension is to selectRows/Columns if its available.
> `
> if (rowCount > 0 ) { 
> 
>         if (getRowSelectionAllowed()) { 
> 
>                 selectRows(rowCount);
> 
>             }
> 
>         } else if (columnCount > 0 ) {
> 
>             if (getColumnSelectionAllowed()) {
> 
>                 selectColumns(columnCount);
> 
>             }`

No that might change the existing behavior and JCK expectation for row>0 and column>0 if we introduce the check..
SO, I will like to keep it as it is..

You can raise a followon bug if you would like it to be worked on later..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004838801

From tr at openjdk.org  Thu Mar 20 06:29:09 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 20 Mar 2025 06:29:09 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <0_pZrDJqhR16MLeXz1FN4JJ6T5CmPewZeaQ-wCljpok=.1822d3b6-7183-4997-8aaf-bc6702253e36@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
 <izczJrPYGaovmmAAGbQ22-SVpiDOyndKWIv-7UrPvBM=.8b5407de-a043-45f4-942b-4ff3546355ec@github.com>
 <0_pZrDJqhR16MLeXz1FN4JJ6T5CmPewZeaQ-wCljpok=.1822d3b6-7183-4997-8aaf-bc6702253e36@github.com>
Message-ID: <37IlwQwLVshxWC0J4XeZ3fIvVD94frOtJmIm2EP3CZc=.e8fd6817-2418-465f-8d76-36c262e14624@github.com>

On Thu, 20 Mar 2025 05:32:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 2198:
>> 
>>> 2196:             if (getColumnSelectionAllowed()) {
>>> 2197:                 selectColumns(columnCount);
>>> 2198:             }
>> 
>> Can we simplify the code from line 2188 - 2198, since the intension is to selectRows/Columns if its available.
>> `
>> if (rowCount > 0 ) { 
>> 
>>         if (getRowSelectionAllowed()) { 
>> 
>>                 selectRows(rowCount);
>> 
>>             }
>> 
>>         } else if (columnCount > 0 ) {
>> 
>>             if (getColumnSelectionAllowed()) {
>> 
>>                 selectColumns(columnCount);
>> 
>>             }`
>
> No that might change the existing behavior and JCK expectation for row>0 and column>0 if we introduce the check..
> SO, I will like to keep it as it is..
> 
> You can raise a followon bug if you would like it to be worked on later..

Sure, raising a follow up bug makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004901773

From tr at openjdk.org  Thu Mar 20 06:40:10 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 20 Mar 2025 06:40:10 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
Message-ID: <qNjls69ZxWoV-KSxdOqQmxKtVjoqejX4fdlyk2LRus0=.2d54e0a1-17c8-46de-aa16-aaf9206790bf@github.com>

On Wed, 19 Mar 2025 13:49:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add check for rowselection and columnselection

Looks good to me.

-------------

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24025#pullrequestreview-2701439784

From abhiscxk at openjdk.org  Thu Mar 20 07:46:11 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Mar 2025 07:46:11 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v7]
In-Reply-To: <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <wPHXGza7iTDqY87Qgm9xwbJhkS6DJuBpKL4bmOrkKBU=.6c94c9d4-a9d1-4ecf-91a4-52d36e31f549@github.com>
Message-ID: <3PgORrkW452qzT0kxqZdT7fsTOgzU7v76FYi_wH8Qno=.bdd37aaa-4e66-4dce-82e7-9ddb9229262a@github.com>

On Wed, 19 Mar 2025 13:49:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add check for rowselection and columnselection

src/java.desktop/share/classes/javax/swing/JTable.java line 2192:

> 2190:             selectColumns(columnCount);
> 2191:         } else if (rowCount > 0 && columnCount == 0) {
> 2192:             if (getRowSelectionAllowed()) {

`getRowSelectionAllowed()` condition check can be merged into else if.

src/java.desktop/share/classes/javax/swing/JTable.java line 2196:

> 2194:             }
> 2195:         } else if (columnCount > 0  && rowCount == 0) {
> 2196:             if (getColumnSelectionAllowed()) {

`getColumnSelectionAllowed()` condition check can be merged into else if.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004989869
PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2004990315

From psadhukhan at openjdk.org  Thu Mar 20 07:59:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 07:59:49 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v8]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Merge condition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/50c27140..6de933ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=06-07

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From abhiscxk at openjdk.org  Thu Mar 20 08:09:11 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Mar 2025 08:09:11 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v8]
In-Reply-To: <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>
Message-ID: <V2UMqGdjpyNz-KiFyRlJAlf1iJMi8_jVh063ASJjfUs=.89026b19-85de-46aa-99a2-700a3f79dfe5@github.com>

On Thu, 20 Mar 2025 07:59:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge condition

test/jdk/javax/swing/JTable/TestTableSelectAll.java line 27:

> 25:  * @test
> 26:  * @bug 4466930
> 27:  * @key headful

Does it require headful tag ?

I ran without headful tag and test still passed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2005017286

From abhiscxk at openjdk.org  Thu Mar 20 08:18:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Mar 2025 08:18:12 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v8]
In-Reply-To: <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>
Message-ID: <WbjeUyQpxwHyyxAxJJ0giT_G0rDU7UtI2FVYu_hCsnY=.2be103c9-4ece-44e6-9304-0fba469e2881@github.com>

On Thu, 20 Mar 2025 07:59:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge condition

Thanks @prsadhuk for clarifying headful doubt offline.

LGTM.

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24025#pullrequestreview-2701637838

From psadhukhan at openjdk.org  Thu Mar 20 09:18:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 09:18:55 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v9]
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <aZIEhZUt32zgPINgszK9pmlK2W2KHi8pm8HsKKwl9nk=.a0628def-b3c7-41ed-b7f6-faba63d2a8ac@github.com>

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove headful

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24025/files
  - new: https://git.openjdk.org/jdk/pull/24025/files/6de933ad..370386be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24025&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24025/head:pull/24025

PR: https://git.openjdk.org/jdk/pull/24025

From abhiscxk at openjdk.org  Thu Mar 20 09:29:11 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Mar 2025 09:29:11 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v9]
In-Reply-To: <aZIEhZUt32zgPINgszK9pmlK2W2KHi8pm8HsKKwl9nk=.a0628def-b3c7-41ed-b7f6-faba63d2a8ac@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <aZIEhZUt32zgPINgszK9pmlK2W2KHi8pm8HsKKwl9nk=.a0628def-b3c7-41ed-b7f6-faba63d2a8ac@github.com>
Message-ID: <PLo8Urgapy4YZ_FWEv-j3Mn8lDEQDaGRE3bw5c9jOuI=.739ea606-0178-4bf2-981d-d4a14c2de6dd@github.com>

On Thu, 20 Mar 2025 09:18:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JTable.selectAll doesn't do anything if there are no rows or no columns. 
>> But it should still select all columns if there are no rows and the other way round. 
>> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
>> 
>> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove headful

Marked as reviewed by abhiscxk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24025#pullrequestreview-2701871264

From psadhukhan at openjdk.org  Thu Mar 20 09:29:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 09:29:12 GMT
Subject: RFR: 4466930: JTable.selectAll boundary handling [v8]
In-Reply-To: <V2UMqGdjpyNz-KiFyRlJAlf1iJMi8_jVh063ASJjfUs=.89026b19-85de-46aa-99a2-700a3f79dfe5@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
 <EwPp8UEvNub2ueV_eXk0vTjNvYjDb9eQyQOMxgkEGqI=.080c9dfc-133b-4702-83b6-2fdbf8ef0998@github.com>
 <V2UMqGdjpyNz-KiFyRlJAlf1iJMi8_jVh063ASJjfUs=.89026b19-85de-46aa-99a2-700a3f79dfe5@github.com>
Message-ID: <1L2YjWvr3mFDCoq4RjtLR4MUklPGV11mnV3tGOGwF8w=.f77379c0-4b69-4cd5-b965-51ef716eebe5@github.com>

On Thu, 20 Mar 2025 08:05:49 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge condition
>
> test/jdk/javax/swing/JTable/TestTableSelectAll.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 4466930
>> 27:  * @key headful
> 
> Does it require headful tag ?
> 
> I ran without headful tag and test still passed.

Removed headful..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24025#discussion_r2005161514

From psadhukhan at openjdk.org  Thu Mar 20 09:32:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Mar 2025 09:32:16 GMT
Subject: Integrated: 4466930: JTable.selectAll boundary handling
In-Reply-To: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
References: <GkzveybBlvhPt8AeaW9vJWTg7q0VTAXCBW6VVEwkhpU=.db16774f-5c8a-47d2-9cde-45c0f4de9346@github.com>
Message-ID: <mLSuzeixVGXN45VA581_5VYPgi6lNwI6aAVJZmtbyMI=.746675a5-e885-4b51-ac25-1268c3023464@github.com>

On Thu, 13 Mar 2025 08:17:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTable.selectAll doesn't do anything if there are no rows or no columns. 
> But it should still select all columns if there are no rows and the other way round. 
> It is seen that isColumnSelected() will return false for all columns after calling selectAll() if there happened to be no rows.
> 
> Fix is made to select all columns even if there are no rows and similarly for rows if there are no columns.

This pull request has now been integrated.

Changeset: 96305e09
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96305e0953a2a3b41bc32b1c584a1a29901a37fd
Stats:     161 lines in 2 files changed: 132 ins; 13 del; 16 mod

4466930: JTable.selectAll boundary handling

Reviewed-by: abhiscxk, tr

-------------

PR: https://git.openjdk.org/jdk/pull/24025

From ihse at openjdk.org  Thu Mar 20 12:41:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 12:41:16 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
 <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>
Message-ID: <XyhYFDGqhNF3GGb25Ii26L_8rLp2U-U6Mwetq-DVbgI=.26a4edcb-4894-45f8-bc7c-39fbe6cbb359@github.com>

On Mon, 17 Mar 2025 10:44:30 GMT, snake66 <duke at openjdk.org> wrote:

>>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
>> 
>> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
>> 
>>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
>> 
>> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.
>
>> > Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
>> 
>> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
> I'm happy to test this, if you want. Won't have time this week, though.

@snake66 No need, I'm already on it: https://github.com/openjdk/jdk/pull/24130

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740320801

From ihse at openjdk.org  Thu Mar 20 12:41:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 12:41:17 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
Message-ID: <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>

On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??
>
>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
> 
> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

@dholmes-ora 
> I have a vague recollection that at one time -pthread set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

Is there any gain then in changing away from `-lpthread`? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740323348

From ihse at openjdk.org  Thu Mar 20 13:20:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 13:20:48 GMT
Subject: RFR: 8352510: Don't reset LCMS_CFLAGS
Message-ID: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>

In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250.

The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up.

-------------

Commit messages:
 - 8352510: Don't reset LCMS_CFLAGS

Changes: https://git.openjdk.org/jdk/pull/24131/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352510
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24131/head:pull/24131

PR: https://git.openjdk.org/jdk/pull/24131

From mbaesken at openjdk.org  Thu Mar 20 13:22:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Mar 2025 13:22:08 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <e8ANxGxl7Ig9p4jSFR7TYj1cUEU1Cr3hMj2-PndvHfQ=.300452c8-8e61-40d4-8a24-c921e3c57db5@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
 <e8ANxGxl7Ig9p4jSFR7TYj1cUEU1Cr3hMj2-PndvHfQ=.300452c8-8e61-40d4-8a24-c921e3c57db5@github.com>
Message-ID: <KOd3vSX6qyWSuZT3pOXwA3b-85L2sUU4emKz5qJ8Vwg=.57a36aad-0a2e-4c4a-a27b-25ca4653826a@github.com>

On Thu, 13 Mar 2025 20:00:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Looks right to me, but I will do a test build.

Was the test build successful ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2740436693

From jkern at openjdk.org  Thu Mar 20 14:30:58 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 20 Mar 2025 14:30:58 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  added needed include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/6e76f114..200c36f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From jkern at openjdk.org  Thu Mar 20 14:38:09 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 20 Mar 2025 14:38:09 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <I7Xtl9mMYoDJyfVcmBklzoqmF3gM8ITZqVAKUSEqgjQ=.7219a63f-7069-48b1-8384-e1d0390856b4@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

I found the problem:
`include Execute.gmk`
was missing. Now in the same directory beside the three files e.g.

libjli.a
BUILD_LIBJLI_run_ar.cmdline
BUILD_LIBJLI_run_ar

I also get 

libjli.a.exp
_generate_export_list_libjli.a_exec.cmdline
_generate_export_list_libjli.a_exec

So I think point 3 of the PR description is solved, although I find the name `_generate_export_list_libjli.a_exec` a little bit to long.

The next point to work on is No. 2 of the PR description (3 `dladdr()` implementations spread over the code). Who can help me out with a review and a tip in which direction I should go?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2740683211

From erikj at openjdk.org  Thu Mar 20 16:02:08 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Mar 2025 16:02:08 GMT
Subject: RFR: 8352510: Don't reset LCMS_CFLAGS
In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
Message-ID: <4Kz-WIZcYbj0VGM-RfiAqjQyraz5wXESStJ6cDFZT44=.72b46bfe-56ba-4900-ac52-d7336c6c406e@github.com>

On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250.
> 
> The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24131#pullrequestreview-2703307744

From serb at openjdk.org  Thu Mar 20 19:53:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Mar 2025 19:53:14 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <yPdaWzVqxjjx1ew6xYfdsZ6fD9TflLTAZinrXdjjhhM=.2e6abdca-2493-4bea-9034-f436eb4a18e7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
 <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
 <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>
 <nseVVyZSwxr2TtCJ9NQOzn5bRLC2qhGTzB2xthKFgQo=.5d393b34-fb1f-45df-a64d-a96b3544f9a5@github.com>
 <yPdaWzVqxjjx1ew6xYfdsZ6fD9TflLTAZinrXdjjhhM=.2e6abdca-2493-4bea-9034-f436eb4a18e7@github.com>
Message-ID: <yXkGyGE4PUKWxzfeslFUJMiPHV7XhCkdZe3yYU3byX4=.f263e811-effb-42ef-9895-f1126dd4c5a4@github.com>

On Tue, 18 Mar 2025 17:07:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> If we start from the beginning. The problem we are trying to solve is preventing changes to our standard profiles so that we can be sure one part of the application does not unexpectedly affect another. This could be achieved in two ways:
>> 
>> - Throw an exception if a standard profile is modified
>> - Ignore the requested change and use the default profile properties as is
>> 
>> For new applications, we could require always cloning the color profile before modification (via the updated specification); otherwise, the application must always check whether the profile is built-in or not.
>> 
>> However, for older applications, these two solutions lead to different outcomes:
>> 
>> - Throwing the new exception will most likely break the application
>> - Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate
>> 
>> The next question is: how big of an issue is this inaccuracy? For example, if we have an sRGB profile that rejects some modifications, we would still try to produce valid sRGB data during conversion.
>> 
>> So the trade-off is: broken applications vs. inaccurate (but still ICC-spec-compliant) conversions.
>> 
>> PS: By the way, why do we want to enforce this rule only for built-in profiles? Why can't a library create similar profiles and mark them as "read-only"?
>
> @mrserb 
> 
>> The app may obtain a profile from some place and use it for some images or pixels. Then, if the app wants to tweak the rendering intent for some reason, what should it do?
>> 
>> Clone the profile and then change the intent?
> 
> The app would follow the above approach.
> There is only one step extra with this fix - creating a copy of built-in profile and then modifying it.
> 
> 
> byte[] builtInData = ICC_Profile.getInstance(ColorSpace.CS_sRGB).getData(); // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(builtInData) // create a new profile
> newProfile.setData(...)
> 
> 
> 
>> However, for older applications, these two solutions lead to different outcomes:
>> Throwing the new exception will most likely break the application
> 
> The chances of breaking an existing application is minimal since API usage for setData() was checked and not many were found and moreover they were not called on built-in profiles.
> 
> 
>>Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate
> 
> This does not seem viable option because the user in unaware as to whether setData() worked or not.

ok, it might be useful to mention this in the release notes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006347247

From serb at openjdk.org  Thu Mar 20 19:59:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Mar 2025 19:59:13 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
Message-ID: <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>

On Tue, 11 Mar 2025 21:26:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   redudant stmt removed

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 40:

> 38: 
> 39:     public static void main(String[] args) {
> 40:         System.out.println("CASE 1: Testing BuiltIn Profile");

I suggest to add the cases when both(BuiltIn and Custom) profiles are tested after serialisation->deserialisation.

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 50:

> 48: 
> 49:     private static void updateProfile(boolean isBuiltIn) {
> 50:         ICC_Profile builtInProfile = ICC_Profile.getInstance(ColorSpace.CS_sRGB);

It would be good to check all types of BuiltIn profiles to prove that it works in case we decide to implement/change some them differently(w/o cache for example).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006354501
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006355768

From bpb at openjdk.org  Thu Mar 20 20:40:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Mar 2025 20:40:46 GMT
Subject: RFR: 8152293: Incomplete fraction reduction in getValueAsString() for
 TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL
Message-ID: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>

Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms in the conversion of `RATIONAL` and `SRATIONAL` field values to a string. Also, add a test.

-------------

Commit messages:
 - 8152293: Incomplete fraction reduction in getValueAsString() for TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL

Changes: https://git.openjdk.org/jdk/pull/24141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8152293
  Stats: 193 lines in 2 files changed: 170 ins; 20 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24141/head:pull/24141

PR: https://git.openjdk.org/jdk/pull/24141

From honkar at openjdk.org  Thu Mar 20 21:05:12 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Mar 2025 21:05:12 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v11]
In-Reply-To: <yXkGyGE4PUKWxzfeslFUJMiPHV7XhCkdZe3yYU3byX4=.f263e811-effb-42ef-9895-f1126dd4c5a4@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <bI4qv0BwCQOmzOgy6CwEyL9EE_fGlpZiOQXz90MNdUM=.b1a9bda7-ce8c-4bb2-81e2-0b9bdcce23f7@github.com>
 <xABqg5Jsm1FgAuYWYjOmU0sP4yaMd6JK01iOpqHcCdA=.ee856ee2-7554-4a9b-904e-2dd5751139d6@github.com>
 <I7hUyEwunJkPFUH8X7ZkoHKoVLiFyLLlGeblwA3yQyI=.860569bb-e313-413c-8d19-e00baf9edcaa@github.com>
 <i0GqqOl_HElN4BoCL84frWrllTVrpguzAoSNVgLVXSQ=.f9274ad9-a6c6-4939-b34b-d751ec21257f@github.com>
 <six_ZrqW9dDAFqCKq-bztV6yZxZkET1VpK89OyFhplc=.2ea4d5bf-4ce6-4abc-a4c8-7e5f232df4fa@github.com>
 <bXLhMyawXNZ-WFQbCfd3oBJPDRrZwYcRtBhX3d1gspM=.bf6c62a1-39e5-45a2-a6c8-2ac45b8984f6@github.com>
 <tjiAdxPSLfCuiPZAHwHoq5yVRoA549CKqxq9NjgKUwI=.9fa018b7-0b89-43e5-82ce-e49f558b3f0d@github.com>
 <jJiWOsQiWqCjtDRGWNKZj3a-d85zoYGC3JUZRgyNOgM=.8721f793-6951-4f75-857c-4d15e8438c55@github.com>
 <vKNe_q-2cLnVNtH4RXWAJzQv4FoUdfE9OUOw2LL-dCY=.8cb170ca-8532-4866-a3a2-b39ce1fa7c1d@github.com>
 <y_73fO5mCLBrmycWIyyTnyGT7oMas9LytLl
 0blEhntY=.8d6f39b2-7020-40b1-9022-5e18573299e9@github.com>
 <8kbQBI0f9LbNnlDUbbhyPBChA3lPTkQ2igl0XwvMRxc=.c46d2a51-adf7-4cb9-b8b7-dd0d32bea019@github.com>
 <3bh741wRHBiUc530W3_4_U2HAKXFJ5nnTg5uFx1C340=.bc890624-f89c-4d9a-9a12-83a31b39318d@github.com>
 <PYXso5o0ix1bCrSEBU2mk86IpX-sRVi14yFAWYuc8mk=.e3daaef4-908f-4ed7-95bb-49bc51343522@github.com>
 <ke0-dQMEYVp97RtltI4UvRJkhIpGCx-kw2dakXq_LU0=.02f96fd7-0b3a-4997-861b-bb50b258e782@github.com>
 <nseVVyZSwxr2TtCJ9NQOzn5bRLC2qhGTzB2xthKFgQo=.5d393b34-fb1f-45df-a64d-a96b3544f9a5@github.com>
 <yPdaWzVqxjjx1ew6xYfdsZ6fD9TflLTAZinrXdjjhhM=.2e6abdca-2493-4bea-9034-f436eb4a18e7@github.com>
 <yXkGyGE4PUKWxzfeslFUJMiPHV7XhCkdZe3yYU3byX4=.f263e811-effb-42ef-9895-f1126dd4c5a4@github.com>
Message-ID: <qc87Rbg9sMVYGBEPLpPpVXRWvC20j_BM_xosuyLdYpc=.99dedb82-1939-43f1-bf10-3cfff8a1ef4f@github.com>

On Thu, 20 Mar 2025 19:50:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb 
>> 
>>> The app may obtain a profile from some place and use it for some images or pixels. Then, if the app wants to tweak the rendering intent for some reason, what should it do?
>>> 
>>> Clone the profile and then change the intent?
>> 
>> The app would follow the above approach.
>> There is only one step extra with this fix - creating a copy of built-in profile and then modifying it.
>> 
>> 
>> byte[] builtInData = ICC_Profile.getInstance(ColorSpace.CS_sRGB).getData(); // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(builtInData) // create a new profile
>> newProfile.setData(...)
>> 
>> 
>> 
>>> However, for older applications, these two solutions lead to different outcomes:
>>> Throwing the new exception will most likely break the application
>> 
>> The chances of breaking an existing application is minimal since API usage for setData() was checked and not many were found and moreover they were not called on built-in profiles.
>> 
>> 
>>>Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate
>> 
>> This does not seem viable option because the user in unaware as to whether setData() worked or not.
>
> ok, it might be useful to mention this in the release notes.

Sure. Noted. I'll update the release notes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006449828

From bpb at openjdk.org  Thu Mar 20 21:09:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Mar 2025 21:09:06 GMT
Subject: RFR: 8152293: Incomplete fraction reduction in getValueAsString()
 for TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL
In-Reply-To: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
References: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
Message-ID: <vn7VMLWVS0RVozyDJrvIAaMgj3bE6lUnZkOmJMdq8mQ=.c1e1776f-df1c-41d9-8766-93223e115464@github.com>

On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms in the conversion of `RATIONAL` and `SRATIONAL` field values to a string. Also, add a test.

If this change is deemed acceptable, then a CSR will be filed to remove the following sentence from the specification of `TIFFField.getValueAsString`:

If the numerator of a TIFFTag.TIFF_RATIONAL or TIFF_SRATIONAL is an integral
multiple of the denominator, then the value is represented as "q/1" where q
is the quotient of the numerator and denominator.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24141#issuecomment-2741661485

From aivanov at openjdk.org  Thu Mar 20 21:12:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Mar 2025 21:12:14 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
Message-ID: <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>

On Fri, 28 Feb 2025 10:09:30 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments 2

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 81:

> 79:         if (!isInitedToIsGetter && this.readList != null) {
> 80:             for (MethodInfo info : this.readList) {
> 81:                 if ((this.read == null) || (!info.method.isDefault() && this.read.type.isAssignableFrom(info.type))) {

Suggestion:

                if ((this.read == null) || (!info.method.isDefault()
                                            && this.read.type.isAssignableFrom(info.type))) {

To avoid a rather long line; wrapping at `||` is also an option.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 235:

> 233:         default public void setFoo(String num) {
> 234:         }
> 235:     }

Suggestion:

    public interface A5 {
        public default void setParentFoo(Integer num) {
        }
        public default void setFoo(String num) {
        }
    }

The `public` keyword should precede the `default` keyword in the list of method modifiers.

This applies to `A8` and `B8` too.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 319:

> 317:     public static void testScenario7() {
> 318:         verifyMethods(D7.class,
> 319:             "public void DefaultMethodBeanPropertyTest$D7.setValue(java.lang.Runnable)"

`getValue` is not included because there's no implementation for it, right?

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 409:

> 407:                     + expected.stream()
> 408:                             .map(Object::toString)
> 409:                             .collect(Collectors.joining("\n  ")));

Suggestion:

                    + expected.stream()
                              .map(Object::toString)
                              .collect(Collectors.joining("\n  ")));

The dots in chained calls were aligned; they remain aligned for `actual` but aren't aligned for `expected`.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 417:

> 415:             final Set<String> expected = new HashSet<>(Arrays.asList(methodNames));
> 416:             final Set<String> actual = Arrays
> 417:                     .stream(Introspector.getBeanInfo(type).getPropertyDescriptors())

Suggestion:

                    .stream(Introspector.getBeanInfo(type)
                                        .getPropertyDescriptors())

It may be better this way, the call to `getPropertyDescriptors` is clearly visible.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 418:

> 416:             final Set<String> actual = Arrays
> 417:                     .stream(Introspector.getBeanInfo(type).getPropertyDescriptors())
> 418:                     .flatMap(pd -> Arrays.stream(new Method[]{pd.getReadMethod(), pd.getWriteMethod()}))

Suggestion:

                    .flatMap(pd -> Stream.of(pd.getReadMethod(), pd.getWriteMethod()))

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 419:

> 417:                     .stream(Introspector.getBeanInfo(type).getPropertyDescriptors())
> 418:                     .flatMap(pd -> Arrays.stream(new Method[]{pd.getReadMethod(), pd.getWriteMethod()}))
> 419:                     .filter(method -> method != null)

Suggestion:

                    .filter(Objects::nonNull)

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 432:

> 430:             final Set<String> expected = new HashSet<>(Arrays.asList(methodNames));
> 431:             final Set<String> actual = Arrays
> 432:                     .stream(Introspector.getBeanInfo(type, Object.class).getMethodDescriptors())

Suggestion:

                    .stream(Introspector.getBeanInfo(type, Object.class)
                                        .getMethodDescriptors())

-------------

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2704062570
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006457546
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006426422
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006437794
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006445627
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006454544
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006450570
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006451061
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2006455315

From honkar at openjdk.org  Thu Mar 20 21:13:12 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Mar 2025 21:13:12 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
 <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>
Message-ID: <wfqgA-9WhzF1OFNsU8UE4sOo1Cn9ETpKd6ChBVEct-I=.0a8d5a97-bc4e-4d34-a9da-abeb7f6add5e@github.com>

On Thu, 20 Mar 2025 19:55:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   redudant stmt removed
>
> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 40:
> 
>> 38: 
>> 39:     public static void main(String[] args) {
>> 40:         System.out.println("CASE 1: Testing BuiltIn Profile");
> 
> I suggest to add the cases when both(BuiltIn and Custom) profiles are tested after serialisation->deserialisation.

Good point. Agreed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006459358

From azvegint at openjdk.org  Thu Mar 20 21:33:06 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Mar 2025 21:33:06 GMT
Subject: RFR: 8352510: Don't reset LCMS_CFLAGS
In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
Message-ID: <UYLlAQdZjqOuxEyeL8tU8eZk5Yo-pmpMMlRLNgwRIBw=.0ee410b0-db3a-4cc7-b645-1a8eb88bbb1c@github.com>

On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250.
> 
> The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up.

The [discussion](https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250) mentions another [JBS issue](https://bugs.openjdk.org/browse/JDK-8329173), which I believe should be closed as duplicate of the 8352510.

-------------

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24131#pullrequestreview-2704166553

From azvegint at openjdk.org  Thu Mar 20 21:41:06 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Mar 2025 21:41:06 GMT
Subject: RFR: 8347321: [ubsan] CGGlyphImages.m:553:30: runtime error: nan
 is outside the range of representable values of type 'unsigned long'
In-Reply-To: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
References: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
Message-ID: <2mxQ3AzG9tIwgH9cJ8ndns3EjV0JbaYmo7hKqB-gzZI=.c93cb63c-4258-4932-9544-4a71d51f1cc3@github.com>

On Mon, 3 Mar 2025 05:57:33 GMT, Phil Race <prr at openjdk.org> wrote:

> The font tests that fail use non-finite or NaN float values.
> In such cases, no visible rendering is expected and the NaNTransform test does pass with empty shapes, but we can filter out these invalid floats before they get to native.
> The macOS class that handles the font strike can check for these and replace them.
> Since you can't observe a difference unless you can get ubsan to work (not easy) and that is a build option, so not something we can use in testing, there' s no regression test update here.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23855#pullrequestreview-2704182567

From azvegint at openjdk.org  Thu Mar 20 22:07:09 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Mar 2025 22:07:09 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
Message-ID: <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>

On Thu, 13 Mar 2025 13:06:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove AIX special handling from endian.h

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104:

> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) {
> 1103: }
> 1104: 

Suggestion:



This doesn't seem necessary since this method should only be called if `loadPipewire` returns true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006524200

From ihse at openjdk.org  Thu Mar 20 22:22:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 22:22:09 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
 <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>
Message-ID: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com>

On Thu, 20 Mar 2025 22:04:19 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove AIX special handling from endian.h
>
> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104:
> 
>> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) {
>> 1103: }
>> 1104: 
> 
> Suggestion:
> 
> 
> 
> This doesn't seem necessary since this method should only be called if `loadPipewire` returns true.

To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006540766

From ihse at openjdk.org  Thu Mar 20 22:25:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 22:25:07 GMT
Subject: RFR: 8329173: LCMS_CFLAGS from configure are lost
In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
Message-ID: <T6I82RhwPsKunNH19Gw5GZEUY127Va5biuHMBjHzzB8=.96a2d413-c79c-41eb-818e-75a3b4d45b97@github.com>

On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250.
> 
> The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up.

Oh, I missed that. Actually, I think we can stick to the guideline that the older bug has priority, and close the new one as a dup instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24131#issuecomment-2741795833

From azvegint at openjdk.org  Thu Mar 20 22:28:08 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Mar 2025 22:28:08 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
 <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>
 <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com>
Message-ID: <GDtt8PF6ghHIO-PUGnNfABhxNSj1E2PPu_9m4orQ0jE=.758bd091-2ce1-4101-8b1d-ce577911acc4@github.com>

On Thu, 20 Mar 2025 22:19:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104:
>> 
>>> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) {
>>> 1103: }
>>> 1104: 
>> 
>> Suggestion:
>> 
>> 
>> 
>> This doesn't seem necessary since this method should only be called if `loadPipewire` returns true.
>
> To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that?

I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006546267

From ihse at openjdk.org  Thu Mar 20 22:28:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 22:28:11 GMT
Subject: Integrated: 8329173: LCMS_CFLAGS from configure are lost
In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com>
Message-ID: <L_a3iq6kK9zp71f0jwGZ9DeIFHdVfoO5USwbgtQgOuA=.33e5810c-f916-438a-80e8-15320c60181a@github.com>

On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250.
> 
> The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up.

This pull request has now been integrated.

Changeset: 06ba6cf3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/06ba6cf3a137a6cdf572a876a46d18e51c248451
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8329173: LCMS_CFLAGS from configure are lost

Reviewed-by: erikj, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/24131

From ihse at openjdk.org  Thu Mar 20 22:48:08 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 22:48:08 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <GDtt8PF6ghHIO-PUGnNfABhxNSj1E2PPu_9m4orQ0jE=.758bd091-2ce1-4101-8b1d-ce577911acc4@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
 <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>
 <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com>
 <GDtt8PF6ghHIO-PUGnNfABhxNSj1E2PPu_9m4orQ0jE=.758bd091-2ce1-4101-8b1d-ce577911acc4@github.com>
Message-ID: <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com>

On Thu, 20 Mar 2025 22:25:49 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that?
>
> I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods.

Ah, I see. I agree, that it makes more sense to either include all native methods, or skip all that are never called. Adding a dummy implementation of one but not all seems ... weird.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006566872

From honkar at openjdk.org  Fri Mar 21 00:56:44 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Mar 2025 00:56:44 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v18]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <vHv9VvVRD4IDLFdqYywsv-yGU4VzAzNVuitbvDItZh0=.ca820280-e7e8-48a1-af3a-0aa9fe8de2c2@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  updated test to check for all builtIn profiles, serial-deserialization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/bc5e9755..05d0783d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=16-17

  Stats: 65 lines in 1 file changed: 47 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Fri Mar 21 00:56:44 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Mar 2025 00:56:44 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <wfqgA-9WhzF1OFNsU8UE4sOo1Cn9ETpKd6ChBVEct-I=.0a8d5a97-bc4e-4d34-a9da-abeb7f6add5e@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
 <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>
 <wfqgA-9WhzF1OFNsU8UE4sOo1Cn9ETpKd6ChBVEct-I=.0a8d5a97-bc4e-4d34-a9da-abeb7f6add5e@github.com>
Message-ID: <R_gsK1leGXIVnyudXl7YSCCPX8eR87LTzyVxffcVvXE=.2592d829-455a-47a8-9bf3-5203cd82400c@github.com>

On Thu, 20 Mar 2025 21:10:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 40:
>> 
>>> 38: 
>>> 39:     public static void main(String[] args) {
>>> 40:         System.out.println("CASE 1: Testing BuiltIn Profile");
>> 
>> I suggest to add the cases when both(BuiltIn and Custom) profiles are tested after serialisation->deserialisation.
>
> Good point. Agreed.

Updated the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006671941

From honkar at openjdk.org  Fri Mar 21 00:56:44 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Mar 2025 00:56:44 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
 <sXbTrPVc8Z8l_209c1nfOQoIbLrW3tgLq0FA8xZZMG0=.ae5c0a29-1394-4eff-8ad8-e9ecc8502c83@github.com>
Message-ID: <6L_WlJgIWElFMPsgTP4LHWSo0_MgTDqg2zuxNtt2o10=.6ceb84f3-0a89-4316-84d9-8c74e3da37a9@github.com>

On Thu, 20 Mar 2025 19:56:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   redudant stmt removed
>
> test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 50:
> 
>> 48: 
>> 49:     private static void updateProfile(boolean isBuiltIn) {
>> 50:         ICC_Profile builtInProfile = ICC_Profile.getInstance(ColorSpace.CS_sRGB);
> 
> It would be good to check all types of BuiltIn profiles to prove that it works in case we decide to implement/change some them differently(w/o cache for example).

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2006671703

From dholmes at openjdk.org  Fri Mar 21 03:20:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 03:20:22 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
 <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>
Message-ID: <oO-zMm8UBBW6kmetvoS96HZtfW5muMCUKehouJ9iZnI=.2fe3b007-5780-439e-aec1-acdcd6210ce1@github.com>

On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is there any gain then in changing away from -lpthread? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..."

True - what we have works and using `-pthread` might subtly change things.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2742145168

From rmarchenko at openjdk.org  Fri Mar 21 07:32:17 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 07:32:17 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
Message-ID: <aTA01tQTz2GkVIpb8a0ebDVeHIIInjzXFnM0doJpIy0=.ab7e789b-2049-4ace-87e0-531713737ee9@github.com>

On Thu, 20 Mar 2025 20:58:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing review comments 2
>
> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 409:
> 
>> 407:                     + expected.stream()
>> 408:                             .map(Object::toString)
>> 409:                             .collect(Collectors.joining("\n  ")));
> 
> Suggestion:
> 
>                     + expected.stream()
>                               .map(Object::toString)
>                               .collect(Collectors.joining("\n  ")));
> 
> The dots in chained calls were aligned; they remain aligned for `actual` but aren't aligned for `expected`.

This wasn't aligned with the dot above. This was aligned by 8 spaces, the same as for `actual`. But OK if you like.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007007167

From rmarchenko at openjdk.org  Fri Mar 21 07:44:12 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 07:44:12 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
Message-ID: <bBgyHgyVCA1H602ChnyuGLSgLo204PbEqGvmSXAnWzs=.2a2656f7-2a4e-4b0e-9683-b7ab74d014ab@github.com>

On Thu, 20 Mar 2025 21:08:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing review comments 2
>
> src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 81:
> 
>> 79:         if (!isInitedToIsGetter && this.readList != null) {
>> 80:             for (MethodInfo info : this.readList) {
>> 81:                 if ((this.read == null) || (!info.method.isDefault() && this.read.type.isAssignableFrom(info.type))) {
> 
> Suggestion:
> 
>                 if ((this.read == null) || (!info.method.isDefault()
>                                             && this.read.type.isAssignableFrom(info.type))) {
> 
> To avoid a rather long line; wrapping at `||` is also an option.

This file already contains lines which are the same length or much longer. But OK, if you like.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007020271

From rmarchenko at openjdk.org  Fri Mar 21 07:50:50 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 07:50:50 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include bridge methods, or methods which were overriden in subclasses.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/4f3f9285..ec01898a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=07-08

  Stats: 19 lines in 2 files changed: 5 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Fri Mar 21 07:50:50 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 07:50:50 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
Message-ID: <aUZEhdpNVeVvDz3GG1SCoQIrFLH9cYqXse5El0b9Zh4=.8e1b4e56-e6c7-4677-aede-33bde79f2be5@github.com>

On Thu, 20 Mar 2025 20:52:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing review comments 2
>
> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 319:
> 
>> 317:     public static void testScenario7() {
>> 318:         verifyMethods(D7.class,
>> 319:             "public void DefaultMethodBeanPropertyTest$D7.setValue(java.lang.Runnable)"
> 
> `getValue` is not included because there's no implementation for it, right?

Yes, correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007027090

From rmarchenko at openjdk.org  Fri Mar 21 07:55:10 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 07:55:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <aUZEhdpNVeVvDz3GG1SCoQIrFLH9cYqXse5El0b9Zh4=.8e1b4e56-e6c7-4677-aede-33bde79f2be5@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
 <aUZEhdpNVeVvDz3GG1SCoQIrFLH9cYqXse5El0b9Zh4=.8e1b4e56-e6c7-4677-aede-33bde79f2be5@github.com>
Message-ID: <46qSYkSUF2EQpGnpu2ws3PKAfHs8YkGQGJ-m8oX2N94=.8e329a71-429b-4055-a380-1cfbbf2e0086@github.com>

On Fri, 21 Mar 2025 07:47:49 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 319:
>> 
>>> 317:     public static void testScenario7() {
>>> 318:         verifyMethods(D7.class,
>>> 319:             "public void DefaultMethodBeanPropertyTest$D7.setValue(java.lang.Runnable)"
>> 
>> `getValue` is not included because there's no implementation for it, right?
>
> Yes, correct.

Updated the description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007032513

From mbaesken at openjdk.org  Fri Mar 21 08:28:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Mar 2025 08:28:07 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v2]
In-Reply-To: <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <TYkJVMXBkzEhEpbbCTd7yEGfDwaJTwWdFNvsB6Qsszc=.0751a2c2-cd80-4702-a551-cb330e01c776@github.com>
 <mVEt__qmFbDUW3DfcB24SNOpjiObnXQGInSm64l-oAQ=.7f36a4c6-ebcf-4417-ab91-14ac5ae6bfb9@github.com>
 <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com>
 <GDtt8PF6ghHIO-PUGnNfABhxNSj1E2PPu_9m4orQ0jE=.758bd091-2ce1-4101-8b1d-ce577911acc4@github.com>
 <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com>
Message-ID: <kX9gJfO_kceJgPuPgGZsvU_nREQ1hbMuxsGz8vVNB3c=.b2797b6e-9858-4ac7-b968-94ae311cb626@github.com>

On Thu, 20 Mar 2025 22:45:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods.
>
> Ah, I see. I agree, that it makes more sense to either include all native methods, or skip all that are never called. Adding a dummy implementation of one but not all seems ... weird.

Okay then let's do defensive programming and add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl   too .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2007074495

From abhiscxk at openjdk.org  Fri Mar 21 08:34:00 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 08:34:00 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
Message-ID: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>

TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.

-------------

Commit messages:
 - Test stabilization

Changes: https://git.openjdk.org/jdk/pull/24148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343891
  Stats: 23 lines in 1 file changed: 12 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24148/head:pull/24148

PR: https://git.openjdk.org/jdk/pull/24148

From mbaesken at openjdk.org  Fri Mar 21 08:58:36 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Mar 2025 08:58:36 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
Message-ID: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>

> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
> 
> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24009/files
  - new: https://git.openjdk.org/jdk/pull/24009/files/e7941d37..79ec8a7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=01-02

  Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24009/head:pull/24009

PR: https://git.openjdk.org/jdk/pull/24009

From psadhukhan at openjdk.org  Fri Mar 21 09:09:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Mar 2025 09:09:08 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
In-Reply-To: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
Message-ID: <6pPEEh4wfm-qivKxe1JuKARSeIchiPJ9hopghr5K3b0=.7429a470-36f6-4e8f-ac92-6ab8651c4c9e@github.com>

On Fri, 21 Mar 2025 08:28:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.

It seems you have ran CI testing only in linux..since test is modified, it will be good to test in all CI platforms just to be safe it doesnt regress elsewhere..
Also, please update copyright..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24148#issuecomment-2742750770

From abhiscxk at openjdk.org  Fri Mar 21 09:53:37 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 09:53:37 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v2]
In-Reply-To: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
Message-ID: <X5cAnSIclJaQl3414kjIX8W5xu5QndFrskGuHwXtcKs=.f240db07-a26d-4c71-bcfb-3a8163c6f038@github.com>

> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24148/files
  - new: https://git.openjdk.org/jdk/pull/24148/files/30016b49..4331b211

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24148&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24148&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24148/head:pull/24148

PR: https://git.openjdk.org/jdk/pull/24148

From abhiscxk at openjdk.org  Fri Mar 21 09:57:07 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 09:57:07 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
In-Reply-To: <6pPEEh4wfm-qivKxe1JuKARSeIchiPJ9hopghr5K3b0=.7429a470-36f6-4e8f-ac92-6ab8651c4c9e@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <6pPEEh4wfm-qivKxe1JuKARSeIchiPJ9hopghr5K3b0=.7429a470-36f6-4e8f-ac92-6ab8651c4c9e@github.com>
Message-ID: <_qwR0yCXnG1nnon6fIVDBdFvcfELKxcMJ5jkNGpdhnc=.54931383-5b17-4455-b31a-48c19e938164@github.com>

On Fri, 21 Mar 2025 09:06:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems you have ran CI testing only in linux..since test is modified, it will be good to test in all CI platforms just to be safe it doesnt regress elsewhere.. Also, please update copyright..

copyright year updated.
Sure, I will run CI jobs and check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24148#issuecomment-2742869390

From ihse at openjdk.org  Fri Mar 21 10:31:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 10:31:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <KLjkCfVhBiKob8pC0mgS4DvpOyaWTE7w-S0hFG88ptI=.4ce459f3-78cc-48a4-8ac6-ce0e3a47a059@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

Regaring point 2: the current solution works, and is acceptable, I think. The two excluded files only contain the dladdr() implementation, and this is implemented in hotspot, so no functionality is lost. Compacting this into just a single implementation is a separate issue, and need not be resolved now.

Regarding the name of `_generate_export_list_libjli.a_exec`: this is generated from the name of the SetupExecute rule, `generate_export_list_$(lib)`. I don't mind the name, it is clear. I don't see any particular point in keeping the name short, but if it bothers you, shorten the name of the rule. Try keeping it clear what it does, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2742949097

From ihse at openjdk.org  Fri Mar 21 10:36:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 10:36:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

make/StaticLibs.gmk line 117:

> 115:       OUTPUT_FILE := $(lib).exp, \
> 116:       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
> 117:     )) \

To better align with how we store the targets of Setup calls, can you please change this to:

Suggestion:

  STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES))
  $(foreach lib, $(STATIC_LIB_FILES), \
    $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \
      INFO := Generating export list for $(notdir $(lib)), \
      DEPS :=  $(lib), \
      OUTPUT_FILE := $(lib).exp, \
      COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
    )) \
    $(eval   STATIC_LIB_EXPORT_FILES += $(lib).exp) \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007298830

From ihse at openjdk.org  Fri Mar 21 10:54:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 10:54:22 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
Message-ID: <c1soaQAFL3F6LU1zKab_I_YC2FweZyNz0RJrBRokpsc=.574b9fd1-b82d-4c69-9c0e-d0006f7eacf3@github.com>

On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2705508010

From aivanov at openjdk.org  Fri Mar 21 10:55:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 10:55:19 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <aTA01tQTz2GkVIpb8a0ebDVeHIIInjzXFnM0doJpIy0=.ab7e789b-2049-4ace-87e0-531713737ee9@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
 <aTA01tQTz2GkVIpb8a0ebDVeHIIInjzXFnM0doJpIy0=.ab7e789b-2049-4ace-87e0-531713737ee9@github.com>
Message-ID: <7kvb0LT-PdkKtq23dmfnkvFJILvyVaH0Ffs5YItc6jU=.34a46ffc-4a9b-439a-96cf-d200cc38c87e@github.com>

On Fri, 21 Mar 2025 07:29:16 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This wasn't aligned with the dot above. This was aligned by 8 spaces, the same as for `actual`. But OK if you like.

The dots in the chained calls for `expected` were aligned in the previous version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007330463

From aivanov at openjdk.org  Fri Mar 21 11:04:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 11:04:08 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v2]
In-Reply-To: <X5cAnSIclJaQl3414kjIX8W5xu5QndFrskGuHwXtcKs=.f240db07-a26d-4c71-bcfb-3a8163c6f038@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <X5cAnSIclJaQl3414kjIX8W5xu5QndFrskGuHwXtcKs=.f240db07-a26d-4c71-bcfb-3a8163c6f038@github.com>
Message-ID: <fi-oRhtpYk_cmDzcFQEbQru-991SYEBDFl7QYbgjBb8=.432a0b8d-38b6-4bbb-b5f4-a3476181efc5@github.com>

On Fri, 21 Mar 2025 09:53:37 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java line 138:

> 136:         Color expected = isOpaque ? c1 : c2;
> 137: 
> 138:         if (!expected.equals(actual)) {

You may want to print the color values to the test output.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24148#pullrequestreview-2705529874
PR Review Comment: https://git.openjdk.org/jdk/pull/24148#discussion_r2007340811

From aivanov at openjdk.org  Fri Mar 21 11:09:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 11:09:14 GMT
Subject: RFR: 8347321: [ubsan] CGGlyphImages.m:553:30: runtime error: nan
 is outside the range of representable values of type 'unsigned long'
In-Reply-To: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
References: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
Message-ID: <KApbh5ReqAVWfA1eWsXxBhaIeSOY5W0FGvA3GoRvXjg=.840dd9b7-6723-4fc7-8493-854ec728ed49@github.com>

On Mon, 3 Mar 2025 05:57:33 GMT, Phil Race <prr at openjdk.org> wrote:

> The font tests that fail use non-finite or NaN float values.
> In such cases, no visible rendering is expected and the NaNTransform test does pass with empty shapes, but we can filter out these invalid floats before they get to native.
> The macOS class that handles the font strike can check for these and replace them.
> Since you can't observe a difference unless you can get ubsan to work (not easy) and that is a build option, so not something we can use in testing, there' s no regression test update here.

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/macosx/classes/sun/font/CStrike.java line 111:

> 109:             for (int j = 0; j < 6; j++) {
> 110:                 glyphTx[j] = 0;
> 111:             }

Suggestion:

            Arrays.fill(glyphTx, 0);

The intent of resetting the matrix could be clearer this way.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23855#pullrequestreview-2705545802
PR Review Comment: https://git.openjdk.org/jdk/pull/23855#discussion_r2007350423

From abhiscxk at openjdk.org  Fri Mar 21 11:14:50 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 11:14:50 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v3]
In-Reply-To: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
Message-ID: <agbazYKEyyBqpoRf-y-xYRzw9JRwUvSQVK2HmcUtWSI=.454c6336-f531-4c3a-bed2-035826a6e54b@github.com>

> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Print expected and actual color on failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24148/files
  - new: https://git.openjdk.org/jdk/pull/24148/files/4331b211..23e50a99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24148&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24148&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24148/head:pull/24148

PR: https://git.openjdk.org/jdk/pull/24148

From abhiscxk at openjdk.org  Fri Mar 21 11:14:50 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 11:14:50 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v2]
In-Reply-To: <fi-oRhtpYk_cmDzcFQEbQru-991SYEBDFl7QYbgjBb8=.432a0b8d-38b6-4bbb-b5f4-a3476181efc5@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <X5cAnSIclJaQl3414kjIX8W5xu5QndFrskGuHwXtcKs=.f240db07-a26d-4c71-bcfb-3a8163c6f038@github.com>
 <fi-oRhtpYk_cmDzcFQEbQru-991SYEBDFl7QYbgjBb8=.432a0b8d-38b6-4bbb-b5f4-a3476181efc5@github.com>
Message-ID: <ORIWJ7XKThQqycHWLCblDIjU8vycaD99bEON7yqzS-w=.1fe81d9e-314e-45c1-88fe-f12a996c68b7@github.com>

On Fri, 21 Mar 2025 11:00:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year update
>
> test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java line 138:
> 
>> 136:         Color expected = isOpaque ? c1 : c2;
>> 137: 
>> 138:         if (!expected.equals(actual)) {
> 
> You may want to print the color values to the test output.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24148#discussion_r2007356349

From aivanov at openjdk.org  Fri Mar 21 11:22:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 11:22:15 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v3]
In-Reply-To: <agbazYKEyyBqpoRf-y-xYRzw9JRwUvSQVK2HmcUtWSI=.454c6336-f531-4c3a-bed2-035826a6e54b@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <agbazYKEyyBqpoRf-y-xYRzw9JRwUvSQVK2HmcUtWSI=.454c6336-f531-4c3a-bed2-035826a6e54b@github.com>
Message-ID: <IaEJFZOvwI4sY_5X9U_Ax4wuyQ4jabHdPgJiAI4mzxo=.287ad697-80ea-45e5-93ad-7a0210097d4c@github.com>

On Fri, 21 Mar 2025 11:14:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print expected and actual color on failure

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24148#pullrequestreview-2705575524

From psadhukhan at openjdk.org  Fri Mar 21 11:37:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Mar 2025 11:37:58 GMT
Subject: RFR: 6734168: BasicButtonUI uses wrong FontMetrics to Layout JButtons
 text
Message-ID: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>

javax.swing.plaf.basic.BasicButtonUI uses wrong FontMetrics object to layout the text on a JButton. 
The paint(Graphics, JComponent) method of BasicButtonUI calculates the [FontMetrics](https://github.com/openjdk/jdk/blob/6656254c346ef505a48652fdf4dedd6edc020e33/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java#L331) using the passed Graphics object without setting the buttons font before. If the buttons font varies from the currently set font of the passed graphics object, the font metrics do not fit the metrics of the expected font leading to truncated text on the button.
In WindowsLookAndFeel, the font in passed graphics object differs from currently set font as in 

button font javax.swing.plaf.FontUIResource[family=Tahoma,name=Tahoma,style=plain,size=10] 
graphics font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]

whereas in Metal and other L&F it is 
`font javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12]`

so the fix is made in Windows L&F to ensure to set the font of the button to the passed graphics object font before calculating the current FontMetrics.

-------------

Commit messages:
 - whitespace
 - 6734168: BasicButtonUI uses wrong FontMetrics to Layout JButtons text
 - 6734168: BasicButtonUI uses wrong FontMetrics to Layout JButtons text

Changes: https://git.openjdk.org/jdk/pull/24152/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24152&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6734168
  Stats: 117 lines in 2 files changed: 116 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24152/head:pull/24152

PR: https://git.openjdk.org/jdk/pull/24152

From jkern at openjdk.org  Fri Mar 21 11:44:49 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 11:44:49 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  follow Magnus

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/200c36f4..9b92eea7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From jkern at openjdk.org  Fri Mar 21 11:44:49 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 11:44:49 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
 <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>
Message-ID: <o3NyR7DRawHRyef7RnEs4ybyxzET0YH6iHt3bbXaIMI=.d3ba022a-92e9-4d42-8984-335cfd1d75b9@github.com>

On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added needed include
>
> make/StaticLibs.gmk line 117:
> 
>> 115:       OUTPUT_FILE := $(lib).exp, \
>> 116:       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
>> 117:     )) \
> 
> To better align with how we store the targets of Setup calls, can you please change this to:
> 
> Suggestion:
> 
>   STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES))
>   $(foreach lib, $(STATIC_LIB_FILES), \
>     $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \
>       INFO := Generating export list for $(notdir $(lib)), \
>       DEPS :=  $(lib), \
>       OUTPUT_FILE := $(lib).exp, \
>       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
>     )) \
>     $(eval   STATIC_LIB_EXPORT_FILES += $(lib).exp) \

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007406147

From ihse at openjdk.org  Fri Mar 21 12:44:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 12:44:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
Message-ID: <9rfZiM27z9h-LAwYXUYSX7nD0dp1oejodRIUT-S8z94=.d5206ba4-18fe-4a88-ad0a-aa3029f2b834@github.com>

On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Magnus

The build changes look good to me now. You need to have someone review the hotspot AIX changes as well.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2705808054

From abhiscxk at openjdk.org  Fri Mar 21 12:52:06 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 12:52:06 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
In-Reply-To: <_qwR0yCXnG1nnon6fIVDBdFvcfELKxcMJ5jkNGpdhnc=.54931383-5b17-4455-b31a-48c19e938164@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <6pPEEh4wfm-qivKxe1JuKARSeIchiPJ9hopghr5K3b0=.7429a470-36f6-4e8f-ac92-6ab8651c4c9e@github.com>
 <_qwR0yCXnG1nnon6fIVDBdFvcfELKxcMJ5jkNGpdhnc=.54931383-5b17-4455-b31a-48c19e938164@github.com>
Message-ID: <oUfyUoMpRnVIFboEmXSjUSjOv_P67GJqv9oOTgKxZmg=.e54fcb7a-4101-4318-b169-f489574d4073@github.com>

On Fri, 21 Mar 2025 09:54:53 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> It seems you have ran CI testing only in linux..since test is modified, it will be good to test in all CI platforms just to be safe it doesnt regress elsewhere.. Also, please update copyright..

CI testing for Windows and mac also is fine. Link posted in JBS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24148#issuecomment-2743273431

From psadhukhan at openjdk.org  Fri Mar 21 13:05:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Mar 2025 13:05:10 GMT
Subject: RFR: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed [v3]
In-Reply-To: <agbazYKEyyBqpoRf-y-xYRzw9JRwUvSQVK2HmcUtWSI=.454c6336-f531-4c3a-bed2-035826a6e54b@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
 <agbazYKEyyBqpoRf-y-xYRzw9JRwUvSQVK2HmcUtWSI=.454c6336-f531-4c3a-bed2-035826a6e54b@github.com>
Message-ID: <_hjNKew1Mivm3A8EOP96imoeulfcTa4yxhJt7Xrp7Po=.5543d613-cc8b-4b65-86c2-badd1fda526d@github.com>

On Fri, 21 Mar 2025 11:14:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print expected and actual color on failure

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24148#pullrequestreview-2705871716

From aivanov at openjdk.org  Fri Mar 21 13:38:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 13:38:22 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
Message-ID: <-RUd7n5SliGLV3cF7Ow6Sq24oEaw1ybF0NGEKQhQrds=.f70eb045-d22f-4329-8eaa-02a207d89997@github.com>

On Fri, 21 Mar 2025 07:50:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2705970714

From aivanov at openjdk.org  Fri Mar 21 13:41:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 13:41:24 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <uWnRHyruexX0fjOe5a6VsM89KtdJJeZiLAvHXBW2DK0=.98d4bf90-a3a9-4686-877d-34f163321dd1@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <uWnRHyruexX0fjOe5a6VsM89KtdJJeZiLAvHXBW2DK0=.98d4bf90-a3a9-4686-877d-34f163321dd1@github.com>
Message-ID: <Ndq5LIfOT2W3UgAjLzuQFFsgtUF0arIakqrfpWvY-xo=.04769b87-ba82-4ba5-8dfc-f30821b2c217@github.com>

On Fri, 7 Mar 2025 18:44:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please summarize the use cases we discussed(in the description of this PR? or jbs) and how they are currently handled. It would be useful to document this since we don?t have a strict specification.

Adding a JBS comment with the description would also be useful. The comment could even be pinned to highlight the approach to fixing the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2743394785

From rmarchenko at openjdk.org  Fri Mar 21 14:02:25 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 21 Mar 2025 14:02:25 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
Message-ID: <sB4d1UOnXs803sZ6TxsniofR-WaeCVssC6dzYnYzDMI=.c8b255e0-c5a2-475b-a0a0-84696bb4a016@github.com>

On Fri, 21 Mar 2025 07:50:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

I will surely add JBS comment if my update in the description is OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2743453411

From aivanov at openjdk.org  Fri Mar 21 14:06:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 14:06:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <bBgyHgyVCA1H602ChnyuGLSgLo204PbEqGvmSXAnWzs=.2a2656f7-2a4e-4b0e-9683-b7ab74d014ab@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>
 <KefEmm_CEDbc5V_JatBuhqPgJUF0blHz5Ck9be_4AqQ=.918cb6f5-e6de-4678-88d2-6701f9cb03fa@github.com>
 <bBgyHgyVCA1H602ChnyuGLSgLo204PbEqGvmSXAnWzs=.2a2656f7-2a4e-4b0e-9683-b7ab74d014ab@github.com>
Message-ID: <OVnL-8eMAFrIKHQgaG8GwzJR0_oI1pb_Z-Z1g964HoY=.dc65a44e-373e-4f7b-b1f1-79f3c514ea59@github.com>

On Fri, 21 Mar 2025 07:41:13 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 81:
>> 
>>> 79:         if (!isInitedToIsGetter && this.readList != null) {
>>> 80:             for (MethodInfo info : this.readList) {
>>> 81:                 if ((this.read == null) || (!info.method.isDefault() && this.read.type.isAssignableFrom(info.type))) {
>> 
>> Suggestion:
>> 
>>                 if ((this.read == null) || (!info.method.isDefault()
>>                                             && this.read.type.isAssignableFrom(info.type))) {
>> 
>> To avoid a rather long line; wrapping at `||` is also an option.
>
> This file already contains lines which are the same length or much longer. But OK, if you like.

Yes, that's true, yet I'd rather not add more long lines, especially longer than 100 columns.

According to [The Client Libraries Group](https://openjdk.org/groups/client-libs/) and its **Source Code** section, ?All lines <= 80 chars.? (There are no anchors on the page, so I can't link directly to the section.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2007653564

From duke at openjdk.org  Fri Mar 21 15:42:29 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 21 Mar 2025 15:42:29 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v6]
In-Reply-To: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
Message-ID: <P_dSt1GVqvC0zXKcd-ERgollSbYiSq3vDY2GCdpqSP4=.ed0beb7e-6f66-4554-9dee-ae83c3c309d3@github.com>

> This update allows users to print with grayscale using color printers.
> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)).
> 
> **Fix description**
> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D.
> 
> This approach is assumed to be platform, CUPS, and IPP protocol independent.
> 
> **Tests**
> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1.

GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:

  Use PassFailJFrame for test.
  Move GrayscaleProxyGraphics2D.java to the shared classes.
  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21930/files
  - new: https://git.openjdk.org/jdk/pull/21930/files/5486473b..c4850933

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21930&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21930&range=04-05

  Stats: 270 lines in 4 files changed: 58 ins; 140 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/21930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21930/head:pull/21930

PR: https://git.openjdk.org/jdk/pull/21930

From duke at openjdk.org  Fri Mar 21 15:46:32 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 21 Mar 2025 15:46:32 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
 <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>
Message-ID: <VbVvb93U4xkjgbTWuiwvlBH8Ye0-cfg-E0DS9pq1McU=.ed4f369c-e993-4bcd-bb6a-99927b9a28b7@github.com>

On Fri, 7 Mar 2025 21:17:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Update copyright, fix typos, move the proxy to the macos
>>  - Merge branch 'master' into monochrome-printing
>>  - proxy mac only
>>  - Revert "grammar fixes"
>>    
>>    This reverts commit 355b2b8f1dbc71cef433e9a925dfb8a7fff56f99.
>>  - Revert "formatting"
>>    
>>    This reverts commit fde514baeadc2775fa502a2a2d312c6038880e7a.
>>  - Revert "update copyright"
>>    
>>    This reverts commit 60e9b4f024544cfac4ddaddc1ea3653bd4a2fe4c.
>>  - Revert "move grayscale methods to PSPathGraphics"
>>    
>>    This reverts commit 1ef135680645ad2647c4430e852095dda8aa7e0c.
>>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>>    
>>    # Conflicts:
>>    #	src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
>>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>>  - move grayscale methods to PSPathGraphics
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6c591854...5486473b
>
> test/jdk/javax/print/attribute/MonochromePrintTest.java line 63:
> 
>> 61:  * @key printer
>> 62:  * @requires (os.family == "mac")
>> 63:  * @summary javax.print: Support monochrome printing
> 
> This needs to be marked as main/manual
> 
> In addition you should use the PassFailJFrame framework you will see widely used in other manual tests that have been added or updated in the last year.

Updated to use PassFailJFrame, the test is manual.

> test/jdk/javax/print/attribute/MonochromePrintTest.java line 124:
> 
>> 122:         String[] instructions = {
>> 123:                 "Two tests will run and it will test all available color apearances:",
>> 124:                 Arrays.toString(supportedChromaticity) + "supported by the printer.",
> 
> you need to add spaces around the toString(..). Currently this is displayed as
> "Two tests will run and it will test all available color apearances:[color, monochrome]supported by the printer"

Updated

> test/jdk/javax/print/attribute/MonochromePrintTest.java line 199:
> 
>> 197:     private static void print(Chromaticity chromaticity) throws PrinterException {
>> 198:         PrintRequestAttributeSet attr = new HashPrintRequestAttributeSet();
>> 199:         attr.add(MediaSizeName.ISO_A4);
> 
> You should remove this line .. A4 is not necessarily available.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r2007850190
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r2007853474
PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r2007851119

From duke at openjdk.org  Fri Mar 21 15:49:27 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 21 Mar 2025 15:49:27 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <mHHiL7g4Rhm6quPxZ-8gjMp2vsmDseIHqJCPsyYnKI0=.0549bd68-2e5c-4bfc-a3db-60a409db607f@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
 <VoT6utMSKU-QmfVBBg6jlVPsfMHLFCfkvtlXM-JcTVM=.e8c633e3-01df-49b7-a176-a2c64175632f@github.com>
 <mHHiL7g4Rhm6quPxZ-8gjMp2vsmDseIHqJCPsyYnKI0=.0549bd68-2e5c-4bfc-a3db-60a409db607f@github.com>
Message-ID: <QRIrK-BbSdWcndZRQUDQ_41iCiSp1ZQ-uS8hFm3FwQQ=.e1ccc362-b99e-4305-a860-5b2d4b286060@github.com>

On Fri, 7 Mar 2025 22:03:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/print/GrayscaleProxyGraphics2D.java line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * Copyright (c) 2024, BELLSOFT. All rights reserved.
>> 
>> I suggest updating everything to be 2025
>
> This class *could* be useful in other cases besides macOS. So perhaps you can move it to share/classes/sun/print ?
> I note that macOS printing - unlike the Postscript and GDI cases - doesn't depend on the Banding raster print path.
> To use it elsewhere, if there's transparency, we'd need to do something similar there to translate the band to gray - but that should not be too hard, if we need it.

Moved to the share/classes/sun/print.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r2007858185

From mdoerr at openjdk.org  Fri Mar 21 16:02:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Mar 2025 16:02:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
Message-ID: <P-9BgoaWKrfLoPrYt0OZ8sVZ0VQvJ1z61Uzg4Es9GAA=.edcb3b6c-0842-4f74-9b32-4b3cbf0b0989@github.com>

On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Magnus

I'm not really familiar with it, but I have some code style requests.

src/hotspot/os/aix/loadlib_aix.cpp line 218:

> 216:     procentry64 PInfo;
> 217:     PInfo.pi_pid = ::getpid();
> 218:     if ( 0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath,PATH_MAX) && *pgmpath ) {

Coding style: spaces after `(` and before `)` are uncommon, but we should have one before `PATH_MAX`.
I think hotspot style guide compliant would be:
`if (0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath, PATH_MAX) && *pgmpath != 0)`

src/hotspot/os/aix/loadlib_aix.cpp line 221:

> 219:       pgmpath[PATH_MAX] = '\0';
> 220:       pgmbase = strrchr(pgmpath, '/');
> 221:       if (pgmbase) {

Better: `if (pgmbase != nullptr)`

src/hotspot/os/aix/loadlib_aix.cpp line 222:

> 220:       pgmbase = strrchr(pgmpath, '/');
> 221:       if (pgmbase) {
> 222:         pgmbase +=1;

Maybe add a space: "+= 1"?

src/hotspot/os/aix/loadlib_aix.cpp line 245:

> 243:     lm->data_len = ldi->ldinfo_datasize;
> 244: 
> 245:     if (pgmbase && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) {

`pmgbase != nullptr`

-------------

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706439265
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007864471
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007869385
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007866684
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007870732

From jkern at openjdk.org  Fri Mar 21 16:19:38 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 16:19:38 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  follow Martin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/9b92eea7..3d9fcafc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From aivanov at openjdk.org  Fri Mar 21 16:38:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 16:38:15 GMT
Subject: RFR: 6734168: BasicButtonUI uses wrong FontMetrics to Layout
 JButtons text
In-Reply-To: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>
References: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>
Message-ID: <1YANraZ1Wla3VpezIO5oPnN0GB7I5fraommypUPZBAI=.3e540a71-b1f9-4a45-8de8-dbae951cd3de@github.com>

On Fri, 21 Mar 2025 11:26:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax.swing.plaf.basic.BasicButtonUI uses wrong FontMetrics object to layout the text on a JButton. 
> The paint(Graphics, JComponent) method of BasicButtonUI calculates the [FontMetrics](https://github.com/openjdk/jdk/blob/6656254c346ef505a48652fdf4dedd6edc020e33/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java#L331) using the passed Graphics object without setting the buttons font before. If the buttons font varies from the currently set font of the passed graphics object, the font metrics do not fit the metrics of the expected font leading to truncated text on the button.
> In WindowsLookAndFeel, the font in passed graphics object differs from currently set font as in 
> 
> button font javax.swing.plaf.FontUIResource[family=Tahoma,name=Tahoma,style=plain,size=10] 
> graphics font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> 
> whereas in Metal and other L&F it is 
> `font javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12]`
> 
> so the fix is made in Windows L&F to ensure to set the font of the button to the passed graphics object font before calculating the current FontMetrics.

I'm unsure if this bug needs fixing at all.

When a button is painted, the fonts are correctly set. If one wants to cache an image of a button, it is their responsibility to configure the `Graphics` object with the correct attributes, failure to do so results in unpredictable behaviour.

?Caching? a painted button doesn't make much sense either: buttons may react to mouse hover?

The correct way to paint a button would be `button.paint(imageGraphics)` where `imageGraphics` is the `Graphics` object returned by `image.getGraphics`.

The test case doesn't play nicely with High DPI environments, or rather the approach demonstrated by the test case.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java line 177:

> 175:         if (!(b.getFont().equals(g.getFont()))) {
> 176:             b.setFont(g.getFont());
> 177:         }

This looks wrong to me: you persistently change the font of the button to the font set in passed in `Graphics`.

Instead, `g.setFont(b.getFont())` should always be called ? that is the font set in the button must be set to `Graphics` before painting.

The problem is reproducible with Metal too, add the following line after the button is created:


        button.setFont(new Font("Cambria", Font.PLAIN, 20));


Initially, the frame in the button looks this way:

![JButton in Windows 10 using Cambria font of size 20](https://github.com/user-attachments/assets/ee134452-39d5-485f-a838-faedf3a5ba1a)

Then, after clicking the button, the button text renders with the default font:

![After disabling the button, it renders with Dialog instead of Cambria](https://github.com/user-attachments/assets/fe1c1383-82e4-4ff6-82f5-8fb6d0bf910d)

If there were a way to re-enable the button again, it would render with `Font.DIALOG` instead of the custom font that I set when the button was created.

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 61:

> 59: 
> 60:     public static void main(String[] args) throws Exception {
> 61:         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");

Suggestion:

        UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 86:

> 84:         Graphics imgGraphics = image.getGraphics();
> 85: 
> 86:         super.paintComponent(imgGraphics);

Suggestion:

        super.paintComponent(imgGraphics);


To separate the painting to image from further processing.

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 97:

> 95:         JFrame frame = new JFrame("TestButtonFontMetrics");
> 96:         frame.setLayout(new GridBagLayout());
> 97:         frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

Suggestion:


Closing of the test UI is handled by `PassFailJFrame`: if it's closed, the test fails.

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 99:

> 97:         frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
> 98:         TestButtonFontMetrics button = new TestButtonFontMetrics("Test");
> 99:         button.addActionListener(new DisableListener());

Suggestion:

        button.addActionListener(e -> ((JComponent) e.getSource()).setEnabled(false));

@DamonGuy [suggested using lambda expressions](https://github.com/openjdk/jdk/pull/22977#discussion_r1909319106) for `ActionListeners`.

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 102:

> 100:         frame.add(button, new GridBagConstraints(0, 0, 1, 1, 0, 0,
> 101:              GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(
> 102:                   10, 10, 0, 10), 0, 0));

Suggestion:

             GridBagConstraints.CENTER, GridBagConstraints.NONE,
             new Insets(10, 10, 0, 10), 0, 0));

Wrapping at `Insets` creation is easier to read. I'd also set the bottom inset to 10.

test/jdk/javax/swing/JButton/TestButtonFontMetrics.java line 103:

> 101:              GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(
> 102:                   10, 10, 0, 10), 0, 0));
> 103:         frame.pack();

If you make the frame larger, it would display its title and would be easier to handle.

Since the test UI consists of a single button, I think it's a perfect case for using [`splitUIRight`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#splitUIRight(PassFailJFrame.PanelCreator)) or simply [`splitUI`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#splitUI(PassFailJFrame.PanelCreator)). Just return `JPanel` or `Box` with the button inside, see [`PrintLatinCJKTest.createTestUI`](https://github.com/openjdk/jdk/blob/0cb110ebb7f8d184dd855f64c5dd7924c8202b3d/test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java#L68-L92) for an example.

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24152#pullrequestreview-2706417765
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007915688
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007877018
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007852640
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007854081
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007855668
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007862675
PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2007876391

From azvegint at openjdk.org  Fri Mar 21 16:50:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 21 Mar 2025 16:50:10 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
Message-ID: <vnAQy-J6LZik0LOyKWRZlgL_kW3nSh6aPV79fZV28YE=.dfea5337-fe01-4675-914c-434bb1d3d519@github.com>

On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2706602971

From mdoerr at openjdk.org  Fri Mar 21 16:59:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Mar 2025 16:59:14 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <w5eKGTMLmT1RmTsu8p2q9pMZzvmBivan_Q1YZq7hzB4=.403f459e-cfd3-46b4-bf51-6fa64c62d081@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

LGTM. Maybe @MBaesken wants to take a look at the AIX code, too?

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706624142

From aivanov at openjdk.org  Fri Mar 21 17:29:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 17:29:28 GMT
Subject: RFR: 6734168: BasicButtonUI uses wrong FontMetrics to Layout
 JButtons text
In-Reply-To: <1YANraZ1Wla3VpezIO5oPnN0GB7I5fraommypUPZBAI=.3e540a71-b1f9-4a45-8de8-dbae951cd3de@github.com>
References: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>
 <1YANraZ1Wla3VpezIO5oPnN0GB7I5fraommypUPZBAI=.3e540a71-b1f9-4a45-8de8-dbae951cd3de@github.com>
Message-ID: <PGWBImvCGvAdVustlpcnBDcSt7TYH41rvrcpZBSBrak=.ad62651f-36b1-4965-aef3-88ff7f1c85fe@github.com>

On Fri, 21 Mar 2025 16:22:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If there were a way to re-enable the button again, it would render with `Font.DIALOG` instead of the custom font that I set when the button was created.

Indeed, the button font is changed permanently.

If I modify the test code:


        System.out.println("Before: " + getFont());
        super.paintComponent(imgGraphics);
        System.out.println("After: " + getFont());


The output looks this way:


Before: java.awt.Font[family=Cambria,name=Cambria,style=plain,size=20]
After: java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]


If I add another button to re-enable the first button, the frame looks like this:\
![The test button is rendered with Cambria font as expected](https://github.com/user-attachments/assets/3655c1a4-eb1c-4110-9f21-d3f5a84d297b) ![The test button gets rendered with Dialog font while disabled](https://github.com/user-attachments/assets/d3ed72cd-3834-4271-8bec-d9f7a3384873) ![The test button remains rendered with the Dialog font after it's enabled again](https://github.com/user-attachments/assets/7fa7d26e-1888-4bb6-9ead-086a0ea7a24b)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24152#discussion_r2008016974

From honkar at openjdk.org  Fri Mar 21 17:39:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Mar 2025 17:39:37 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v19]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <0ZQLwTW6J7po4jh-07gTitD2qM8oNWaxv5Xsn3NRtFQ=.d8273d0b-7d1a-404f-8914-c396deba05c7@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Merge branch 'master' into BuiltInCheck
 - updated test to check for all builtIn profiles, serial-deserialization
 - redudant stmt removed
 - modifier order changed, added comment to BuiltInProfile
 - review changes
 - builtIn converted to transient, tests updated
 - minor
 - review changes
 - doc update
 - builtIn flag moved to constructor
 - ... and 11 more: https://git.openjdk.org/jdk/compare/eb9e77c9...7da4c5c7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/05d0783d..7da4c5c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=17-18

  Stats: 110998 lines in 2415 files changed: 54862 ins; 37818 del; 18318 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From abhiscxk at openjdk.org  Fri Mar 21 17:51:11 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Mar 2025 17:51:11 GMT
Subject: Integrated: 8343891: Test
 javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
In-Reply-To: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
References: <UTNn_8aL43GgyZLTU17f7C0ndan_bR6XgNsWnH_9vlA=.f97ed2a5-e733-400d-9840-9a2c40d44cc8@github.com>
Message-ID: <h5wMn6x-QsuXtiNAW_Y4JLcqeNa4H7O0FKuobRASAP0=.c104ece0-bcf9-4de7-9573-528a664567be@github.com>

On Fri, 21 Mar 2025 08:28:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> TestJTabbedPaneBackgroundColor.java test was failing intermittently in CI jobs. Test is modified to access UI components on EDT for stabilizations. CI testing seems fine after test change. Link attached in JBS.

This pull request has now been integrated.

Changeset: c2e14b1b
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2e14b1b304796753bea2eca81aa24ab4b3bf6db
Stats:     26 lines in 1 file changed: 14 ins; 3 del; 9 mod

8343891: Test javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed

Reviewed-by: aivanov, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/24148

From aivanov at openjdk.org  Fri Mar 21 19:34:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Mar 2025 19:34:09 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
Message-ID: <W-JTwAa8hkC2Y-QuqFNehMbY6pbjzY6whOXhHSH549A=.c1c8ba4b-4651-47d2-9148-6d4613703b72@github.com>

On Fri, 21 Mar 2025 07:50:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

I ran this changes through CI testing, and the results are good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2744275033

From serb at openjdk.org  Fri Mar 21 22:39:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Mar 2025 22:39:16 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v19]
In-Reply-To: <0ZQLwTW6J7po4jh-07gTitD2qM8oNWaxv5Xsn3NRtFQ=.d8273d0b-7d1a-404f-8914-c396deba05c7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <0ZQLwTW6J7po4jh-07gTitD2qM8oNWaxv5Xsn3NRtFQ=.d8273d0b-7d1a-404f-8914-c396deba05c7@github.com>
Message-ID: <FnK0klZmVEDYjmIyqpxMuSIIy5XXRspORm8bWsj-XQc=.b2073045-030b-4ce6-9f38-88c5b912ade0@github.com>

On Fri, 21 Mar 2025 17:39:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into BuiltInCheck
>  - updated test to check for all builtIn profiles, serial-deserialization
>  - redudant stmt removed
>  - modifier order changed, added comment to BuiltInProfile
>  - review changes
>  - builtIn converted to transient, tests updated
>  - minor
>  - review changes
>  - doc update
>  - builtIn flag moved to constructor
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/8a3e1b75...7da4c5c7

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 104:

> 102: 
> 103:     // this test is added to check the ICC_Profile's transient isBuiltIn flag
> 104:     private static void testSerialization(boolean isBuiltIn)

This method does not actually test serialization; instead, it clones/copies the ICC profile via the filesystem. This is why you did not get an exception at the end of this method, even for a built-in profile.

You should use something like this instead:


ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(iccProfile);


byte[] array = baos.toByteArray();
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(array));
ICC_Profile iccProfile = (ICC_Profile) ois.readObject();

In the example above, the built-in profile should throw an IAE, but a custom profile should not. (I suggest covering all built-in profiles as well).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r2008431593

From serb at openjdk.org  Fri Mar 21 22:51:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Mar 2025 22:51:15 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v17]
In-Reply-To: <ZmfOtUDEr80TOkaXSgrB3Sp4VM2xL1lYFocKUJQ--Sw=.1ef4a721-8f63-48a0-a3ce-56a431e232cf@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <Pqu7e1Pf3SghxqXfDa7J828JUi_y0wwQpiF_aRpLsNA=.342348c0-07ad-440e-b8a9-1a69de586b82@github.com>
 <ZmfOtUDEr80TOkaXSgrB3Sp4VM2xL1lYFocKUJQ--Sw=.1ef4a721-8f63-48a0-a3ce-56a431e232cf@github.com>
Message-ID: <zywuZwA_AlmvsDjA1T14laOq4RRa3EztBJq6pMlK1wA=.7bb4075b-a78b-48eb-8c6c-d1096b56bc60@github.com>

On Thu, 13 Mar 2025 20:25:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   redudant stmt removed
>
> Marked as reviewed by prr (Reviewer).

@prrace I know that the CSR description is not part of the specification. But I would like to point out that we do not specify built-in profiles as singletons (but currently implemented as such). Therefore, it is not necessarily true that the same profile will always be returned by `getInstance` method.

>https://bugs.openjdk.org/browse/JDK-8350025
>The built-in profiles are singleton objects, if an application modifies a shared profile object via ICC_Profile.setData(), then the modified version of the profile is returned each time the same built-in profile is requested via ICC_Profile.getInstance(). This would impact all color space transformations using the modified color space.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23606#issuecomment-2744618698

From prr at openjdk.org  Sat Mar 22 02:48:21 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 22 Mar 2025 02:48:21 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v19]
In-Reply-To: <0ZQLwTW6J7po4jh-07gTitD2qM8oNWaxv5Xsn3NRtFQ=.d8273d0b-7d1a-404f-8914-c396deba05c7@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <0ZQLwTW6J7po4jh-07gTitD2qM8oNWaxv5Xsn3NRtFQ=.d8273d0b-7d1a-404f-8914-c396deba05c7@github.com>
Message-ID: <ZlUVNP1zM0TVenXLDLwEhWSvMbqdR_oNnsiRFlzLlQ4=.5c3e9ee7-16bb-4ac5-985f-5fafa64c2a3c@github.com>

On Fri, 21 Mar 2025 17:39:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into BuiltInCheck
>  - updated test to check for all builtIn profiles, serial-deserialization
>  - redudant stmt removed
>  - modifier order changed, added comment to BuiltInProfile
>  - review changes
>  - builtIn converted to transient, tests updated
>  - minor
>  - review changes
>  - doc update
>  - builtIn flag moved to constructor
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/63e9b2ec...7da4c5c7

> 

That's an interesting point. The way to obtain them is a get* method which conventionally means it isn't a "new" instance, but the first line of the javadoc unhelpfully says
"Constructs an ICC_Profile".

As a matter of practicality it is hard to imagine that getInstance(int) would return new instances every time in any implementation. Particularly since ICC_Profile doesn't over-ride equals() ! Perhaps we should improve the doc of that method too in some way. But I think that can be a separate PR with its own separate CSR.
The spec. update being made here is valid in either case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23606#issuecomment-2744915887

From sakyosang at gmail.com  Mon Mar 24 01:18:24 2025
From: sakyosang at gmail.com (last last)
Date: Mon, 24 Mar 2025 09:18:24 +0800
Subject: =?UTF-8?Q?8246742=EF=BC=9AInquiry_about_PrintDialog_Properties_butto?=
 =?UTF-8?Q?n_behavior_on_Linux?=
Message-ID: <CAMBge5Ng6UwExQpk5S4a_eD7RtMQscB+e4YFV-3DWkC2T0M+GQ@mail.gmail.com>

*Dear OpenJDK Community,*

I'm writing regarding an observation about the PrintDialog's Properties
button behavior on Linux platforms. On my Ubuntu 20.04 system (OpenJDK
version: 17), I noticed that the Properties button in the print dialog
remains disabled.

Through previous research, I found this is documented in JDK-8246742
("Disable Properties button in PrintDialog for Unixes and Mac"). The ticket
suggests this behavior was intentionally implemented.

But from a user perspective, this disabled state raises some concerns:

   1. 1.Users familiar with Windows implementation may find this
   inconsistent
   2. 2.Prevents access to printer-specific options that might otherwise be
   configurable
   3. 3.Could be confusing for applications relying on this functionality

Reproducer:
import java.awt.*;
import java.awt.print.*;

public class PrintDialogExample implements Printable {

    public static void main(String[] args) {
        // ?? PrinterJob ??
        PrinterJob printerJob = PrinterJob.getPrinterJob();

        // ??????
        printerJob.setPrintable(new PrintDialogExample());

        // ???????
        if (printerJob.printDialog()) {
            try {
                // ??????
                printerJob.print();
                System.out.println("Printing complete.");
            } catch (PrinterException e) {
                e.printStackTrace();
            }
        } else {
            System.out.println("Printing cancelled.");
        }
    }

    @Override
    public int print(Graphics graphics, PageFormat pageFormat, int
pageIndex) throws PrinterException {
        // ??????
        if (pageIndex > 0) {
            return Printable.NO_SUCH_PAGE;
        }

        // ? Graphics ????? Graphics2D
        Graphics2D g2d = (Graphics2D) graphics;

        // ???????
        g2d.setFont(new Font("Serif", Font.PLAIN, 12));
        g2d.setColor(Color.BLACK);

        // ????
        String text = "Hello, this is a test print job!";
        g2d.drawString(text, 100, 100);

        // ??????
        return Printable.PAGE_EXISTS;
    }
}


I'd like to inquire:

   1. 1.Is this considered an accepted platform behavior difference?
   2. 2.Are there any plans to implement native printer property support
   for Linux/MacOS?
   3. 3.Would there be value in creating a feature request for this
   capability?

Additional environment details:

   - Desktop Environment: GNOME [3.34.3-0ubuntu1 ]
   - Default Print System: CUPS [2.3.1-9ubuntu1.4]

Thank you for your insights. I'm happy to provide further testing support
if needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250324/ca1da00d/attachment-0001.htm>

From rmarchenko at openjdk.org  Mon Mar 24 07:03:13 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Mon, 24 Mar 2025 07:03:13 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
Message-ID: <S5wPNtxHGDQXdiKasyAucCIeo4dmWZykCoxWFGNoDrM=.9004691c-57af-46b7-ac83-377c04441143@github.com>

On Fri, 21 Mar 2025 07:50:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

Added and pin the comment to the JBS issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2747076746

From mbaesken at openjdk.org  Mon Mar 24 08:34:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 08:34:22 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
Message-ID: <t32QvZBpWakHtXYwgjYsk6LPbnyjGv_0JbXUsJxQBXA=.ed0affec-6d06-41ec-97a9-414e49c679a5@github.com>

On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

Thanks for the review !
Phil - do you have  more comments ?
If not I would like to integrate it soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2747289351

From zzambers at openjdk.org  Mon Mar 24 13:46:16 2025
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 24 Mar 2025 13:46:16 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
Message-ID: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>

This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)

Fix is based on [patch](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) submitted in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.

I was not able to get response from original author for this issue, so I am creating PR myself.

**Testing:**
I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 

Without fix:

   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<


With fix

   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<


Many tests are no longer crashing the VM:

-java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
+java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful

There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)

I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

-------------

Commit messages:
 - Fix for stack smashing issue on linux s390x

Changes: https://git.openjdk.org/jdk/pull/24197/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24197&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343618
  Stats: 20 lines in 1 file changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24197/head:pull/24197

PR: https://git.openjdk.org/jdk/pull/24197

From mbaesken at openjdk.org  Mon Mar 24 14:33:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:33:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Regarding BitmapToYXBandedRectangles  from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature?
But this can be done in another issue/PR not here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748329252

From mbaesken at openjdk.org  Mon Mar 24 14:40:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:40:15 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <KypvNQV9tJHTctzcvnrlJUzQ-M2Zt66UJI0aO2cnsuw=.55911462-d051-4853-950a-20c374ee52e8@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

src/hotspot/os/aix/loadlib_aix.cpp line 245:

> 243:     lm->data_len = ldi->ldinfo_datasize;
> 244: 
> 245:     if (pgmbase != nullptr && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) {

Maybe better `strcmp(...) == 0 ` this is what we use almost everywhere in the HS codebase .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2010314259

From mbaesken at openjdk.org  Mon Mar 24 14:47:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:47:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <8TwaUDdIMp-LNCl2y4Yujed7OooXrKcCAw80VMVQVKc=.fe956a84-6f75-4273-86fd-cde786fce017@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Looks okay, small nit inside. I would prefer more self explaining variable names like program_full_path , program_base_name  but up to you!

-------------

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2710649870

From ihse at openjdk.org  Mon Mar 24 15:30:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Mar 2025 15:30:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
 <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>
Message-ID: <QeXUxCvo2u-8k_Yo6ERC2FBX3ZwWyAb1m4eSSRSVKkU=.60d05c16-f0bb-4d07-82bd-a029a8e30d29@github.com>

On Mon, 24 Mar 2025 14:30:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Regarding BitmapToYXBandedRectangles from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature?
But this can be done in another issue/PR not here.

Indeed we could. Note that the same issue apply to all unix platforms. It's sort of a hack -- the core problem is that we cannot hide non-exported symbols in static libraries. Solving that is the long-term goal, but it is tricky on several platforms.

It could make sense to try to unify the two versions of BitmapToYXBandedRectangles as well; they are similar but not identical (but I can't really tell why).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748527590

From mbaesken at openjdk.org  Mon Mar 24 15:49:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 15:49:20 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Seems we use already a bit of functionality from common/awt in the splashscreen lib

140 ifeq ($(ENABLE_HEADLESS_ONLY), false)
141   LIBSPLASHSCREEN_EXTRA_SRC := \
142       common/awt/systemscale \
143       #
144 
145   LIBSPLASHSCREEN_HEADER_DIRS := \
146       common/awt/utility \

maybe it would make sense to centralize the BitmapToYXBandedRectangles   there and reuse it from there?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748584904

From goetz at openjdk.org  Mon Mar 24 15:49:31 2025
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Mon, 24 Mar 2025 15:49:31 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <wQXUhqgMquuidvAaPe93aI9hD3FNPibARUP-5-YAaYI=.27d763da-2c0e-4eaa-b2a9-58952d8c5fc8@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
 <OXb_L2sMjnl4UK78wFajtN1ruwg9_f07dYjR3oeH-I0=.05b9dc8d-75fc-4d6e-99c1-ab1b36124ae0@github.com>
 <DKISt9HQf09fylSelhvsHEasGanNAMhTQoyfuUPJgOE=.bcc1bc89-a8c8-421b-b3a0-ea554fef7201@github.com>
 <kcToSub8SbQv5WhnNr49Xa5wR45ZvBuHiKq6AsyE32M=.67409fe5-d416-4592-8017-9baef06fb10e@github.com>
 <wQXUhqgMquuidvAaPe93aI9hD3FNPibARUP-5-YAaYI=.27d763da-2c0e-4eaa-b2a9-58952d8c5fc8@github.com>
Message-ID: <o1YtJ7OR9ImbGsBsT3ssOYqOh9DjSuVxBnBuCnLRPrU=.70cc11df-b81c-4e34-926b-4af173642e11@github.com>

On Tue, 4 Mar 2025 05:32:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>>> > > Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement. Manual test case is added to verify the fix.
>>> > 
>>> > 
>>> > Hello. Was this problem observed on Windows before your changes?
>>> 
>>> No, this issue observed only on macOS.
>> 
>> Then try to modify the solution so that it also affects only macOS?
>> Try to debug the native implementation of NSAccessibilityElements? The error might be somewhere there.
>
>> Try to debug the native implementation of NSAccessibilityElements? The error might be somewhere there.
> 
> I posted my analysis in JBS and root caused the issue in a11y `(NSString *)accessibilityStringForRange:(NSRange)range` API in `NavigableTextAccessibility.m` implementation for `Text Component` but the range value invoked by system seems wrong.
> 
> So, this is a workaround fix for the issue.

Hi @kumarabhi006 
I ran this test when trying to backport it to 21/17.
I get unexpected readings when I use the up/down arrows.
* Sometimes it says the right percentages
* Sometimes it says correct numbers
* Sometimes it says arbitrary numbers (it says "11" when I step from 14 to 15).
I tried it with my backport for 21, but also with 24 and head. They all show similar behavior.
But I'm not experienced with using VoiceOver, did I use it wrongly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23841#issuecomment-2748585706

From jkern at openjdk.org  Mon Mar 24 16:18:15 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 24 Mar 2025 16:18:15 GMT
Subject: Integrated: 8352064: AIX: now also able to build static-jdk image with
 a statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <Sclu8dIThAHf2ZLAEMrVPsQY-NEdij5ILJBGmhjwHLE=.8de68110-57f0-4308-80cf-5037f039bf38@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

This pull request has now been integrated.

Changeset: d8c2f59a
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8c2f59a1b28521ab9969fdf71c52726026d2a85
Stats:     68 lines in 5 files changed: 63 ins; 3 del; 2 mod

8352064: AIX: now also able to build static-jdk image with a statically linked launcher

Reviewed-by: mdoerr, mbaesken, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/24062

From ihse at openjdk.org  Mon Mar 24 17:07:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Mar 2025 17:07:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
 <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>
Message-ID: <3hZLvynYqp2oIj5l7-fC764K5KCM08ooRvWq3woHYlI=.85ae9e1d-bf14-4b73-be13-6729f2add58a@github.com>

On Mon, 24 Mar 2025 15:46:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems we use already a bit of functionality from common/awt in the splashscreen lib

Maybe. The client team has traditionally been very conservative about doing clean-up changes like that, so you might be entering an uphill battle if you want to do that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748828065

From serb at openjdk.org  Mon Mar 24 18:27:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Mar 2025 18:27:18 GMT
Subject: RFR: 8352638: Enhance code consistency: java.desktop/windows
Message-ID: <5qm_Hyp98_iQNlGpxru_EapE3rVlCfTTqVTWyF4zlzI=.450e15f8-7a75-44c2-8916-abd44426566d@github.com>

The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.

To make the code review process easier I have made the following changes:

1. I chose `java.desktop/windows` as the starting package because it contains a relatively small number of classes
2. The public API was not affected so there is no need to worry about a CSR
3. In a few places I removed the `final` modifier from methods since they were already defined in final classes

Note: I will submit additional patches in this area later because:

1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
2. I skipped adding `@Override` for anonymous classes

Any feedback or suggestions are welcome!

Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24170.diff) to a simple diff file, it might be more convenient for reviewing the changes.

To download the diff file and filter only the modified lines you can use the following script:


curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24170.diff -o d.txt && grep -E '^+|^-' d.txt


The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

-------------

Commit messages:
 - @Override for toString/equals/hashCode
 - add final
 - initial version

Changes: https://git.openjdk.org/jdk/pull/24170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352638
  Stats: 743 lines in 109 files changed: 543 ins; 0 del; 200 mod
  Patch: https://git.openjdk.org/jdk/pull/24170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24170/head:pull/24170

PR: https://git.openjdk.org/jdk/pull/24170

From serb at openjdk.org  Mon Mar 24 18:49:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Mar 2025 18:49:13 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
Message-ID: <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>

On Fri, 21 Mar 2025 07:50:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 114:

> 112:                 }
> 113:                 for (Method method : iface.getMethods()) {
> 114:                     if (!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()) {

I have looked into the `Modifier` class to check which other modifiers we have, and I found that you might also want to skip static and private methods. Perhaps method.isDefault() is the method you're looking for? It seems like none of the tests catch that?

Also please double check the code a few lines above:

                            method = MethodFinder.findAccessibleMethod(method);
                            if (!method.getDeclaringClass().isInterface()) {
                                method = null; // ignore methods from superclasses
                            }

 - ~~Why do we need to skip the methods from the interfaces? Maybe we can inject our logic there?~~
 - The method `MethodFinder.findAccessibleMethod` also checks each method to be `isExported`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2010743261

From kizune at openjdk.org  Mon Mar 24 19:07:25 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 24 Mar 2025 19:07:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <K-cy3tfXj3EcU0IcymRsnsMod7YxlOnFPd_DRVK_jxo=.f958bcd9-1534-4403-a8f8-6b8f335665a8@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

Screenshot from Windows 10 - just for the reference.
![image](https://github.com/user-attachments/assets/e1082a14-8fdb-4f49-b827-c00f2b6724a2)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2749139860

From prr at openjdk.org  Mon Mar 24 19:53:14 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Mar 2025 19:53:14 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
Message-ID: <gFN8PG9PM3tACRVVpDU-5dFNLgwmBy3zhEoIUrJt9Ow=.017ae131-3a60-4d1e-903d-fb1d9593ab63@github.com>

On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

Marked as reviewed by prr (Reviewer).

Sorry, the job was slow and I was otherwise busy last week and forgot.
Approving now since testing was OK.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2711528266
PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2749235660

From prr at openjdk.org  Mon Mar 24 19:56:13 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Mar 2025 19:56:13 GMT
Subject: Integrated: 8347321: [ubsan] CGGlyphImages.m:553:30: runtime error:
 nan is outside the range of representable values of type 'unsigned long'
In-Reply-To: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
References: <rcHOgL1T6TQHRZf8u7-BXYtmg9bHKKr9MQ5I7b-FHzY=.6df57c2b-35ee-4403-ac47-9db3e9a4990d@github.com>
Message-ID: <leXEcTX4KccCxwWfgtc-HCcjIbsQGHHi1rSJ9nmTkqg=.31484e12-8b85-4bee-bc98-be7ba6e99961@github.com>

On Mon, 3 Mar 2025 05:57:33 GMT, Phil Race <prr at openjdk.org> wrote:

> The font tests that fail use non-finite or NaN float values.
> In such cases, no visible rendering is expected and the NaNTransform test does pass with empty shapes, but we can filter out these invalid floats before they get to native.
> The macOS class that handles the font strike can check for these and replace them.
> Since you can't observe a difference unless you can get ubsan to work (not easy) and that is a build option, so not something we can use in testing, there' s no regression test update here.

This pull request has now been integrated.

Changeset: 6e6a39d3
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e6a39d35fda929300c7668fdf5d2f0fbfed0606
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8347321: [ubsan] CGGlyphImages.m:553:30: runtime error: nan is outside the range of representable values of type 'unsigned long'

Reviewed-by: kizune, azvegint, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/23855

From bpb at openjdk.org  Mon Mar 24 21:10:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 24 Mar 2025 21:10:17 GMT
Subject: RFR: 8152293: Incomplete fraction reduction in getValueAsString()
 for TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL
In-Reply-To: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
References: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
Message-ID: <lMX5mSbZHxOBFTCqlsmCxZmhAGAqwpbI5f5oF2qe-5Y=.a8d4414f-fd93-4075-8c88-7fdf00b1c540@github.com>

On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms in the conversion of `RATIONAL` and `SRATIONAL` field values to a string. Also, add a test.

The corresponding issue is closed as Won't Fix so this PR Is being withdrawn.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24141#issuecomment-2749400714

From bpb at openjdk.org  Mon Mar 24 21:10:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 24 Mar 2025 21:10:17 GMT
Subject: Withdrawn: 8152293: Incomplete fraction reduction in
 getValueAsString() for TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL
In-Reply-To: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
References: <2rRCWrTdBbvJZJlxISy9Q7fLtdh9Ly9uXoCHE_xa2r8=.b4a4e78a-0733-4d93-9536-ee019e3cd161@github.com>
Message-ID: <C2VHh8cgUaGd_QhlZuYPprmW8yfHprUjfbv6LVjnWkQ=.336eab73-d483-4272-ae0a-679ed0ff4041@github.com>

On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms in the conversion of `RATIONAL` and `SRATIONAL` field values to a string. Also, add a test.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24141

From djgredler at gmail.com  Mon Mar 24 22:18:08 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 24 Mar 2025 23:18:08 +0100
Subject: Eliminate sun.awt.OSInfo?
Message-ID: <CAPA+ug4PJTWhuaxk=cB_FGWvHLz5NqhpJYnBRL+vczrRYFLLWg@mail.gmail.com>

Hi all,

The sun.awt.OSInfo class seems to replicate the functionality in
jdk.internal.util.OperatingSystem, with one additional capability:
distinguishing between different versions of Windows. However, the Windows
versions included are Windows 95 through Windows 7, which hasn't been an
officially-supported platform for the JDK since Java 7. There are Windows
version checks which rely on OSInfo sprinkled throughout the java.desktop
module, but all of them are checking for Windows versions which are not
even supported anymore, as far as I can tell. Would a PR which removes
OSInfo be accepted, or is there a reason to keep it around that I'm missing?

Thanks!

Daniel

(Somewhat related: https://bugs.openjdk.org/browse/JDK-8305777)

---

$ grep -r --include "*.java" OSInfo src/java.desktop/
src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:import
sun.awt.OSInfo;
src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
   supported = OSInfo.getWindowsVersion()
src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
           .compareTo(OSInfo.WINDOWS_7) >= 0
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:import
sun.awt.OSInfo;
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:
               if (recentFolder != null &&
OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_2000) >= 0) {
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:import
sun.awt.OSInfo;
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
       return OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
       if (OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0) {
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
       isClassicWindows =
OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0;
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
               (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
               OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >=
0)) {
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
       return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
               &&
OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_VISTA) >= 0;
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
       return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
               && OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_7) >=
0;
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
           if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
                   OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP)
< 0) {
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:import
sun.awt.OSInfo;
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
     return OSInfo.getOSType() == OSInfo.OSType.MACOSX;
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
     return OSInfo.getOSType() == OSInfo.OSType.LINUX;
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
     return (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
             OSInfo.getOSType() == OSInfo.OSType.MACOSX);
src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
     return OSInfo.getOSType() == OSInfo.OSType.AIX;
src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:import
sun.awt.OSInfo;
src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:        if
(OSInfo.getOSType() == OSInfo.OSType.LINUX) {
src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:import
sun.awt.OSInfo;
src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
 int numOfColor = OSInfo.getOSType() == OSInfo.OSType.AIX ? 8 : 4;
src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
 if (OSInfo.getOSType() == OSInfo.OSType.LINUX) { // Load motif default
colors on Linux.
src/java.desktop/share/classes/javax/swing/PopupFactory.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/javax/swing/PopupFactory.java:            if
((OSInfo.getOSType() == OSInfo.OSType.MACOSX) && (owner != null) &&
src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:
           boolean isWindows = OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:
           if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/javax/swing/UIManager.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/javax/swing/UIManager.java:
 OSInfo.OSType osType = OSInfo.getOSType();
src/java.desktop/share/classes/javax/swing/UIManager.java:        if
(osType == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/javax/swing/UIManager.java:        else if
(osType == OSInfo.OSType.MACOSX) {
src/java.desktop/share/classes/javax/swing/UIManager.java:
 OSInfo.OSType osType = OSInfo.getOSType();
src/java.desktop/share/classes/javax/swing/UIManager.java:        if
(osType == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/javax/swing/UIManager.java:            if
(osType == OSInfo.OSType.MACOSX) {
src/java.desktop/share/classes/javax/swing/UIManager.java:            if
(OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
src/java.desktop/share/classes/sun/awt/OSInfo.java:import static
sun.awt.OSInfo.OSType.*;
src/java.desktop/share/classes/sun/awt/OSInfo.java:public class OSInfo {
src/java.desktop/share/classes/sun/awt/OSInfo.java:    private static final
Map<String, WindowsVersion> windowsVersionMap = new HashMap<String,
OSInfo.WindowsVersion>();
src/java.desktop/share/classes/sun/awt/OSInfo.java:    private OSInfo() {
src/java.desktop/share/classes/sun/awt/FontConfiguration.java:
   if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:        if
(f.equals(canonical) || OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/sun/print/PSPrinterJob.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/print/PSPrinterJob.java:        isMac =
OSInfo.getOSType() == OSInfo.OSType.MACOSX;
src/java.desktop/share/classes/sun/print/PSPrinterJob.java:        if
(OSInfo.getOSType() == OSInfo.OSType.LINUX ||
src/java.desktop/share/classes/sun/print/PSPrinterJob.java:
 OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
src/java.desktop/share/classes/sun/print/ServiceDialog.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/print/ServiceDialog.java:            if
(OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:
  if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
src/java.desktop/share/classes/sun/font/FontUtilities.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/font/FontUtilities.java:        isLinux
= OSInfo.getOSType() == OSInfo.OSType.LINUX;
src/java.desktop/share/classes/sun/font/FontUtilities.java:        isMacOSX
= OSInfo.getOSType() == OSInfo.OSType.MACOSX;
src/java.desktop/share/classes/sun/font/FontUtilities.java:
 isWindows = OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
 boolean isXPPlatform = (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
   OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0);
src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:import
sun.awt.OSInfo;
src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
                 if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
                 if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250324/0d44f1f0/attachment-0001.htm>

From philip.race at oracle.com  Mon Mar 24 22:25:40 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 24 Mar 2025 15:25:40 -0700
Subject: Eliminate sun.awt.OSInfo?
In-Reply-To: <CAPA+ug4PJTWhuaxk=cB_FGWvHLz5NqhpJYnBRL+vczrRYFLLWg@mail.gmail.com>
References: <CAPA+ug4PJTWhuaxk=cB_FGWvHLz5NqhpJYnBRL+vczrRYFLLWg@mail.gmail.com>
Message-ID: <f6198d9b-048c-45fd-a8ca-0a8a0d9d1732@oracle.com>

I am not a huge fan of sun.awt.OSInfo and I know a lot of uses are 
out-dated,
and probably could be removed.
Whether that ends up in not needing OSInfo is another a question.
But I would *not* want to migrate to a jdk.internal API.
I have a goal of someday having zero cases of java.base "exports FOO to 
java.desktop"
Its not a top priority to complete, but at the same time I don't want to 
needlessly go in the opposite direction.


-phil.

On 3/24/25 3:18 PM, Daniel Gredler wrote:
> Hi all,
>
> The sun.awt.OSInfo class seems to replicate the functionality in 
> jdk.internal.util.OperatingSystem, with one additional capability: 
> distinguishing between different versions of Windows. However, the 
> Windows versions included are Windows 95 through Windows 7, which 
> hasn't been an officially-supported platform for the JDK since Java 7. 
> There are Windows version checks which rely on OSInfo sprinkled 
> throughout the java.desktop module, but all of them are checking for 
> Windows versions which are not even supported anymore, as far as I can 
> tell. Would a PR which removes OSInfo be accepted, or is there a 
> reason to keep it around that I'm missing?
>
> Thanks!
>
> Daniel
>
> (Somewhat related: https://bugs.openjdk.org/browse/JDK-8305777)
>
> ---
>
> $ grep -r --include "*.java" OSInfo src/java.desktop/
> src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:import 
> sun.awt.OSInfo;
> src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java: ? 
> ? ? ?supported = OSInfo.getWindowsVersion()
> src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java: ? 
> ? ? ? ? ? ? ?.compareTo(OSInfo.WINDOWS_7) >= 0
> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:import 
> sun.awt.OSInfo;
> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java: 
> ? ? ? ? ? ? ? ?if (recentFolder != null && 
> OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_2000) >= 0) {
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:import 
> sun.awt.OSInfo;
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ?if (OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0) {
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ?isClassicWindows = 
> OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0;
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ? ? ? ? ?(OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0)) {
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ? ? ? ? ?&& 
> OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_VISTA) >= 0;
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ? ? ? ? ?&& 
> OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_7) >= 0;
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java: 
> ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) < 0) {
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:import 
> sun.awt.OSInfo;
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.LINUX;
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java: 
> ? ? ? ?return (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java: 
> ? ? ? ? ? ? ? ?OSInfo.getOSType() == OSInfo.OSType.MACOSX);
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java: 
> ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.AIX;
> src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:import 
> sun.awt.OSInfo;
> src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java: ? ? ? 
> ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:import 
> sun.awt.OSInfo;
> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java: ? 
> ?int numOfColor = OSInfo.getOSType() == OSInfo.OSType.AIX ? 8 : 4;
> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java: ? 
> ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) { // Load motif 
> default colors on Linux.
> src/java.desktop/share/classes/javax/swing/PopupFactory.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/javax/swing/PopupFactory.java: ? ? ? ? 
> ? ?if ((OSInfo.getOSType() == OSInfo.OSType.MACOSX) && (owner != null) &&
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java: 
> ? ? ? ? ? ?boolean isWindows = OSInfo.getOSType() == 
> OSInfo.OSType.WINDOWS;
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java: 
> ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/javax/swing/UIManager.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? 
> ?OSInfo.OSType osType = OSInfo.getOSType();
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? ?if 
> (osType == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? ?else if 
> (osType == OSInfo.OSType.MACOSX) {
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? 
> ?OSInfo.OSType osType = OSInfo.getOSType();
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? ?if 
> (osType == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? ? ? ?if 
> (osType == OSInfo.OSType.MACOSX) {
> src/java.desktop/share/classes/javax/swing/UIManager.java: ? ? ? ?if 
> (OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
> src/java.desktop/share/classes/sun/awt/OSInfo.java:import static 
> sun.awt.OSInfo.OSType.*;
> src/java.desktop/share/classes/sun/awt/OSInfo.java:public class OSInfo {
> src/java.desktop/share/classes/sun/awt/OSInfo.java: ? ?private static 
> final Map<String, WindowsVersion> windowsVersionMap = new 
> HashMap<String, OSInfo.WindowsVersion>();
> src/java.desktop/share/classes/sun/awt/OSInfo.java: ? ?private OSInfo() {
> src/java.desktop/share/classes/sun/awt/FontConfiguration.java: ? ? ? ? 
> ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java: ? ? ? 
> ?if (f.equals(canonical) || OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java: ? ? ?isMac 
> = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java: ? ? ?if 
> (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java: ? ? ? ? ? 
> ? ?OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
> src/java.desktop/share/classes/sun/print/ServiceDialog.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/print/ServiceDialog.java: ? ? ? ? 
> ?if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java: 
> ? ? if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> src/java.desktop/share/classes/sun/font/FontUtilities.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/font/FontUtilities.java: ? ? 
> ?isLinux = OSInfo.getOSType() == OSInfo.OSType.LINUX;
> src/java.desktop/share/classes/sun/font/FontUtilities.java: ? ? 
> ?isMacOSX = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> src/java.desktop/share/classes/sun/font/FontUtilities.java: ? ? 
> ?isWindows = OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
> src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java: 
> ?boolean isXPPlatform = (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java: ? ? ? 
> ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0);
> src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:import 
> sun.awt.OSInfo;
> src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java: 
> ? ? ? ? ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
> src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java: 
> ? ? ? ? ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
>


From djgredler at gmail.com  Mon Mar 24 22:43:56 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 24 Mar 2025 23:43:56 +0100
Subject: Eliminate sun.awt.OSInfo?
In-Reply-To: <f6198d9b-048c-45fd-a8ca-0a8a0d9d1732@oracle.com>
References: <CAPA+ug4PJTWhuaxk=cB_FGWvHLz5NqhpJYnBRL+vczrRYFLLWg@mail.gmail.com>
 <f6198d9b-048c-45fd-a8ca-0a8a0d9d1732@oracle.com>
Message-ID: <CAPA+ug76CTCg7KbXjhPxP99D3F5ei253P3HgXV15qZ+=_OmNRw@mail.gmail.com>

Interesting, what are the advantages of removing all of the "exports"? Are
they just code smells?

In an ideal world where there were none of these "exports", java.desktop
would need to reimplement this OS detection functionality, no? Or would
something like jdk.internal.util.OperatingSystem be promoted to a public
API?

More immediately, in your opinion is it worth keeping OSInfo around as a
10-line wrapper around jdk.internal.util.OperatingSystem in order to limit
the "blast radius" of the dependency? Or does it not matter whether 1 class
uses it or 20 classes use it, once the dependency has been created?

Take care,

Daniel



On Mon, Mar 24, 2025 at 11:25?PM Philip Race <philip.race at oracle.com> wrote:

> I am not a huge fan of sun.awt.OSInfo and I know a lot of uses are
> out-dated,
> and probably could be removed.
> Whether that ends up in not needing OSInfo is another a question.
> But I would *not* want to migrate to a jdk.internal API.
> I have a goal of someday having zero cases of java.base "exports FOO to
> java.desktop"
> Its not a top priority to complete, but at the same time I don't want to
> needlessly go in the opposite direction.
>
>
> -phil.
>
> On 3/24/25 3:18 PM, Daniel Gredler wrote:
> > Hi all,
> >
> > The sun.awt.OSInfo class seems to replicate the functionality in
> > jdk.internal.util.OperatingSystem, with one additional capability:
> > distinguishing between different versions of Windows. However, the
> > Windows versions included are Windows 95 through Windows 7, which
> > hasn't been an officially-supported platform for the JDK since Java 7.
> > There are Windows version checks which rely on OSInfo sprinkled
> > throughout the java.desktop module, but all of them are checking for
> > Windows versions which are not even supported anymore, as far as I can
> > tell. Would a PR which removes OSInfo be accepted, or is there a
> > reason to keep it around that I'm missing?
> >
> > Thanks!
> >
> > Daniel
> >
> > (Somewhat related: https://bugs.openjdk.org/browse/JDK-8305777)
> >
> > ---
> >
> > $ grep -r --include "*.java" OSInfo src/java.desktop/
> >
> src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
> >      supported = OSInfo.getWindowsVersion()
> > src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
> >              .compareTo(OSInfo.WINDOWS_7) >= 0
> >
> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:import
>
> > sun.awt.OSInfo;
> >
> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:
>
> >                if (recentFolder != null &&
> > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_2000) >= 0) {
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:import
>
> > sun.awt.OSInfo;
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >        return OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >        if (OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0)
> {
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >        isClassicWindows =
> > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0;
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >                (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >  OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0)) {
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >        return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >                &&
> > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_VISTA) >= 0;
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >        return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >                &&
> > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_7) >= 0;
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >            if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> >
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
> >  OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) < 0) {
> >
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:import
>
> > sun.awt.OSInfo;
> > src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
> >        return OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> > src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
> >        return OSInfo.getOSType() == OSInfo.OSType.LINUX;
> > src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
> >        return (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
> > src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
> >                OSInfo.getOSType() == OSInfo.OSType.MACOSX);
> > src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
> >        return OSInfo.getOSType() == OSInfo.OSType.AIX;
> > src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:
> >  if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
> >
> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
> >  int numOfColor = OSInfo.getOSType() == OSInfo.OSType.AIX ? 8 : 4;
> > src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
> >  if (OSInfo.getOSType() == OSInfo.OSType.LINUX) { // Load motif
> > default colors on Linux.
> > src/java.desktop/share/classes/javax/swing/PopupFactory.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/javax/swing/PopupFactory.java:
> >    if ((OSInfo.getOSType() == OSInfo.OSType.MACOSX) && (owner != null) &&
> >
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:import
>
> > sun.awt.OSInfo;
> >
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:
>
> >            boolean isWindows = OSInfo.getOSType() ==
> > OSInfo.OSType.WINDOWS;
> >
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:import
>
> > sun.awt.OSInfo;
> >
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:
>
> >            if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> > src/java.desktop/share/classes/javax/swing/UIManager.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/javax/swing/UIManager.java:
> >  OSInfo.OSType osType = OSInfo.getOSType();
> > src/java.desktop/share/classes/javax/swing/UIManager.java:    if
> > (osType == OSInfo.OSType.WINDOWS) {
> > src/java.desktop/share/classes/javax/swing/UIManager.java:    else if
> > (osType == OSInfo.OSType.MACOSX) {
> > src/java.desktop/share/classes/javax/swing/UIManager.java:
> >  OSInfo.OSType osType = OSInfo.getOSType();
> > src/java.desktop/share/classes/javax/swing/UIManager.java:    if
> > (osType == OSInfo.OSType.WINDOWS) {
> > src/java.desktop/share/classes/javax/swing/UIManager.java:        if
> > (osType == OSInfo.OSType.MACOSX) {
> > src/java.desktop/share/classes/javax/swing/UIManager.java:        if
> > (OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
> > src/java.desktop/share/classes/sun/awt/OSInfo.java:import static
> > sun.awt.OSInfo.OSType.*;
> > src/java.desktop/share/classes/sun/awt/OSInfo.java:public class OSInfo {
> > src/java.desktop/share/classes/sun/awt/OSInfo.java:    private static
> > final Map<String, WindowsVersion> windowsVersionMap = new
> > HashMap<String, OSInfo.WindowsVersion>();
> > src/java.desktop/share/classes/sun/awt/OSInfo.java:    private OSInfo() {
> > src/java.desktop/share/classes/sun/awt/FontConfiguration.java:
> >        if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> > src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:
> >  if (f.equals(canonical) || OSInfo.getOSType() == OSInfo.OSType.WINDOWS)
> {
> > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:      isMac
> > = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:      if
> > (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
> > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:
> >    OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
> > src/java.desktop/share/classes/sun/print/ServiceDialog.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/print/ServiceDialog.java:
> >  if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
> >
> src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:import
>
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:
> >     if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> > src/java.desktop/share/classes/sun/font/FontUtilities.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/font/FontUtilities.java:
> >  isLinux = OSInfo.getOSType() == OSInfo.OSType.LINUX;
> > src/java.desktop/share/classes/sun/font/FontUtilities.java:
> >  isMacOSX = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
> > src/java.desktop/share/classes/sun/font/FontUtilities.java:
> >  isWindows = OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
> > src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:import
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
> >  boolean isXPPlatform = (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
> > src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
> >  OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0);
> >
> src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:import
>
> > sun.awt.OSInfo;
> > src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
> >                    if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
> > src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
> >                    if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250324/f4ada483/attachment-0001.htm>

From philip.race at oracle.com  Tue Mar 25 00:05:45 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 24 Mar 2025 17:05:45 -0700
Subject: Eliminate sun.awt.OSInfo?
In-Reply-To: <CAPA+ug76CTCg7KbXjhPxP99D3F5ei253P3HgXV15qZ+=_OmNRw@mail.gmail.com>
References: <CAPA+ug4PJTWhuaxk=cB_FGWvHLz5NqhpJYnBRL+vczrRYFLLWg@mail.gmail.com>
 <f6198d9b-048c-45fd-a8ca-0a8a0d9d1732@oracle.com>
 <CAPA+ug76CTCg7KbXjhPxP99D3F5ei253P3HgXV15qZ+=_OmNRw@mail.gmail.com>
Message-ID: <682fcaa7-c091-4b81-af50-bb73488c7a20@oracle.com>



On 3/24/25 3:43 PM, Daniel Gredler wrote:
> Interesting, what are the advantages of removing all of the "exports"? 
> Are they just code smells?

Bad code smells.

>
> In an ideal world where there were none of these "exports", 
> java.desktop would need to reimplement this OS detection 
> functionality, no? Or would something like 
> jdk.internal.util.OperatingSystem be promoted to a public API?

I can't see that being a public API. Internals that we use today is 
stuff that was
not considered suitable for public API, or it already would be.

>
> More immediately, in your opinion is it worth keeping OSInfo around as 
> a 10-line wrapper around jdk.internal.util.OperatingSystem in order to 
> limit the "blast radius" of the dependency? Or does it not matter 
> whether 1 class uses it or 20 classes use it, once the dependency has 
> been created?

Keeping the blast radius to no more than it is today is the first thing.
I would prefer re-implementation over the export, but it hasn't bubbled up.
And I can imagine that even today we might want to know more 
specifically which windows version.
Windows 10 is a range of "versions" and Windows 11 is really just more
Windows 10 versions. And we'll see about Windows 12.

-phil.

>
> Take care,
>
> Daniel
>
>
>
> On Mon, Mar 24, 2025 at 11:25?PM Philip Race <philip.race at oracle.com> 
> wrote:
>
>     I am not a huge fan of sun.awt.OSInfo and I know a lot of uses are
>     out-dated,
>     and probably could be removed.
>     Whether that ends up in not needing OSInfo is another a question.
>     But I would *not* want to migrate to a jdk.internal API.
>     I have a goal of someday having zero cases of java.base "exports
>     FOO to
>     java.desktop"
>     Its not a top priority to complete, but at the same time I don't
>     want to
>     needlessly go in the opposite direction.
>
>
>     -phil.
>
>     On 3/24/25 3:18 PM, Daniel Gredler wrote:
>     > Hi all,
>     >
>     > The sun.awt.OSInfo class seems to replicate the functionality in
>     > jdk.internal.util.OperatingSystem, with one additional capability:
>     > distinguishing between different versions of Windows. However, the
>     > Windows versions included are Windows 95 through Windows 7, which
>     > hasn't been an officially-supported platform for the JDK since
>     Java 7.
>     > There are Windows version checks which rely on OSInfo sprinkled
>     > throughout the java.desktop module, but all of them are checking
>     for
>     > Windows versions which are not even supported anymore, as far as
>     I can
>     > tell. Would a PR which removes OSInfo be accepted, or is there a
>     > reason to keep it around that I'm missing?
>     >
>     > Thanks!
>     >
>     > Daniel
>     >
>     > (Somewhat related: https://bugs.openjdk.org/browse/JDK-8305777)
>     >
>     > ---
>     >
>     > $ grep -r --include "*.java" OSInfo src/java.desktop/
>     >
>     src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:import
>
>     > sun.awt.OSInfo;
>     > src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
>     > ? ? ?supported = OSInfo.getWindowsVersion()
>     > src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java:
>     > ? ? ? ? ? ? ?.compareTo(OSInfo.WINDOWS_7) >= 0
>     >
>     src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java:
>
>     > ? ? ? ? ? ? ? ?if (recentFolder != null &&
>     > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_2000) >= 0) {
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ?if
>     (OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0) {
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ?isClassicWindows =
>     > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_95) <= 0;
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ? ? ? ? ?(OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0)) {
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ? ? ? ? ?&&
>     > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_VISTA) >= 0;
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.WINDOWS
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ? ? ? ? ?&&
>     > OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_7) >= 0;
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS &&
>     >
>     src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java:
>
>     > ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) < 0) {
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.MACOSX;
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.LINUX;
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
>
>     > ? ? ? ?return (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
>
>     > ? ? ? ? ? ? ? ?OSInfo.getOSType() == OSInfo.OSType.MACOSX);
>     >
>     src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java:
>
>     > ? ? ? ?return OSInfo.getOSType() == OSInfo.OSType.AIX;
>     >
>     src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java:
>     > ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
>     >
>     src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:import
>
>     > sun.awt.OSInfo;
>     > src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
>     > ?int numOfColor = OSInfo.getOSType() == OSInfo.OSType.AIX ? 8 : 4;
>     > src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java:
>     > ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) { // Load motif
>     > default colors on Linux.
>     > src/java.desktop/share/classes/javax/swing/PopupFactory.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/javax/swing/PopupFactory.java:
>     > ? ?if ((OSInfo.getOSType() == OSInfo.OSType.MACOSX) && (owner !=
>     null) &&
>     >
>     src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java:
>
>     > ? ? ? ? ? ?boolean isWindows = OSInfo.getOSType() ==
>     > OSInfo.OSType.WINDOWS;
>     >
>     src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java:
>
>     > ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
>     > src/java.desktop/share/classes/javax/swing/UIManager.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/javax/swing/UIManager.java:
>     > ?OSInfo.OSType osType = OSInfo.getOSType();
>     > src/java.desktop/share/classes/javax/swing/UIManager.java: ?if
>     > (osType == OSInfo.OSType.WINDOWS) {
>     > src/java.desktop/share/classes/javax/swing/UIManager.java: ?else if
>     > (osType == OSInfo.OSType.MACOSX) {
>     > src/java.desktop/share/classes/javax/swing/UIManager.java:
>     > ?OSInfo.OSType osType = OSInfo.getOSType();
>     > src/java.desktop/share/classes/javax/swing/UIManager.java: ?if
>     > (osType == OSInfo.OSType.WINDOWS) {
>     > src/java.desktop/share/classes/javax/swing/UIManager.java: ? ?if
>     > (osType == OSInfo.OSType.MACOSX) {
>     > src/java.desktop/share/classes/javax/swing/UIManager.java: ? ?if
>     > (OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
>     > src/java.desktop/share/classes/sun/awt/OSInfo.java:import static
>     > sun.awt.OSInfo.OSType.*;
>     > src/java.desktop/share/classes/sun/awt/OSInfo.java:public class
>     OSInfo {
>     > src/java.desktop/share/classes/sun/awt/OSInfo.java: ?private static
>     > final Map<String, WindowsVersion> windowsVersionMap = new
>     > HashMap<String, OSInfo.WindowsVersion>();
>     > src/java.desktop/share/classes/sun/awt/OSInfo.java: ?private
>     OSInfo() {
>     > src/java.desktop/share/classes/sun/awt/FontConfiguration.java:
>     > ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
>     >
>     src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java:
>     > ?if (f.equals(canonical) || OSInfo.getOSType() ==
>     OSInfo.OSType.WINDOWS) {
>     > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/sun/print/PSPrinterJob.java: ?
>     ?isMac
>     > = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
>     > src/java.desktop/share/classes/sun/print/PSPrinterJob.java: ? ?if
>     > (OSInfo.getOSType() == OSInfo.OSType.LINUX ||
>     > src/java.desktop/share/classes/sun/print/PSPrinterJob.java:
>     > ? ?OSInfo.getOSType() == OSInfo.OSType.MACOSX) {
>     > src/java.desktop/share/classes/sun/print/ServiceDialog.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/sun/print/ServiceDialog.java:
>     > ?if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
>     >
>     src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java:
>
>     > ? ? if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
>     > src/java.desktop/share/classes/sun/font/FontUtilities.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/sun/font/FontUtilities.java:
>     > ?isLinux = OSInfo.getOSType() == OSInfo.OSType.LINUX;
>     > src/java.desktop/share/classes/sun/font/FontUtilities.java:
>     > ?isMacOSX = OSInfo.getOSType() == OSInfo.OSType.MACOSX;
>     > src/java.desktop/share/classes/sun/font/FontUtilities.java:
>     > ?isWindows = OSInfo.getOSType() == OSInfo.OSType.WINDOWS;
>     >
>     src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:import
>     > sun.awt.OSInfo;
>     > src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
>     > ?boolean isXPPlatform = (OSInfo.getOSType() ==
>     OSInfo.OSType.WINDOWS &&
>     > src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java:
>     > ?OSInfo.getWindowsVersion().compareTo(OSInfo.WINDOWS_XP) >= 0);
>     >
>     src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:import
>
>     > sun.awt.OSInfo;
>     >
>     src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
>
>     > ? ? ? ? ? ? ? ? ? ?if (OSInfo.getOSType() == OSInfo.OSType.LINUX) {
>     >
>     src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java:
>
>     > ? ? ? ? ? ? ? ? ? ?if (OSInfo.getOSType() ==
>     OSInfo.OSType.WINDOWS) {
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250324/e5c38eae/attachment-0001.htm>

From sakyosang at gmail.com  Tue Mar 25 02:06:49 2025
From: sakyosang at gmail.com (last last)
Date: Tue, 25 Mar 2025 10:06:49 +0800
Subject: =?UTF-8?Q?8246742=EF=BC=9AInquiry_about_PrintDialog_Properties_butto?=
 =?UTF-8?Q?n_behavior_on_Linux?=
Message-ID: <CAMBge5P=jWbYqCSjH0CbggPPF5_un1s9B+A30Xyz8bp_vVAdEw@mail.gmail.com>

*Dear OpenJDK Community,*

I'm writing regarding an observation about the PrintDialog's Properties
button behavior on Linux platforms. On my Ubuntu 20.04 system (OpenJDK
version: 17), I noticed that the Properties button in the print dialog
remains disabled.

Through previous research, I found this is documented in  [JDK-8246742]
ServiceUI.printDialog does not support properties dialog - Java Bug System
<https://bugs.openjdk.org/browse/JDK-8246742> . The ticket suggests this
behavior was intentionally implemented.

But from a user perspective, this disabled state raises some concerns:

   1. 1.Users familiar with Windows implementation may find this
   inconsistent
   2. 2.Prevents access to printer-specific options that might otherwise be
   configurable
   3. 3.Could be confusing for applications relying on this functionality

Reproducer:
import java.awt.*;
import java.awt.print.*;

public class PrintDialogExample implements Printable {

    public static void main(String[] args) {
        // ?? PrinterJob ??
        PrinterJob printerJob = PrinterJob.getPrinterJob();

        // ??????
        printerJob.setPrintable(new PrintDialogExample());

        // ???????
        if (printerJob.printDialog()) {
            try {
                // ??????
                printerJob.print();
                System.out.println("Printing complete.");
            } catch (PrinterException e) {
                e.printStackTrace();
            }
        } else {
            System.out.println("Printing cancelled.");
        }
    }

    @Override
    public int print(Graphics graphics, PageFormat pageFormat, int
pageIndex) throws PrinterException {
        // ??????
        if (pageIndex > 0) {
            return Printable.NO_SUCH_PAGE;
        }

        // ? Graphics ????? Graphics2D
        Graphics2D g2d = (Graphics2D) graphics;

        // ???????
        g2d.setFont(new Font("Serif", Font.PLAIN, 12));
        g2d.setColor(Color.BLACK);

        // ????
        String text = "Hello, this is a test print job!";
        g2d.drawString(text, 100, 100);

        // ??????
        return Printable.PAGE_EXISTS;
    }
}


I'd like to inquire:

   1. 1.Is this considered an accepted platform behavior difference?
   2. 2.Are there any plans to implement native printer property support
   for Linux/MacOS?
   3. 3.Would there be value in creating a feature request for this
   capability?

Additional environment details:

   - Desktop Environment: GNOME [3.34.3-0ubuntu1 ]
   - Default Print System: CUPS [2.3.1-9ubuntu1.4]

Thank you for your insights. I'm happy to provide further testing support
if needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250325/c63f3b0c/attachment.htm>

From psadhukhan at openjdk.org  Tue Mar 25 03:05:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Mar 2025 03:05:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <uWnbccxSKvTTUiFcasqScBoFOeYI1gBlFehnUtqPYxQ=.6501f91c-b4bd-4418-a03a-e24a622fbd0a@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

> Screenshot from Windows 10 - just for the reference. ![image](https://private-user-images.githubusercontent.com/69642324/426227284-e1082a14-8fdb-4f49-b827-c00f2b6724a2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDI4NzA1NzksIm5iZiI6MTc0Mjg3MDI3OSwicGF0aCI6Ii82OTY0MjMyNC80MjYyMjcyODQtZTEwODJhMTQtOGZkYi00ZjQ5LWI4MjctYzAwZjJiNjcyNGEyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAzMjUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMzI1VDAyMzc1OVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZkNzZmNTU4YzdhN2E2OTdhMGRkMzk0YzQ3ZWE4MGExODA3ZGY2NDhjZDAyYjEzZmQwYWZjMmM3MzU0MTgzYWImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.VuDpxFJN4-10SzYIcQgqvyG7NhR6y9LIiBOUGp1AWd8)


@azuev-java Thanks for WIndows 10 screenshot..

The program renders "Radio Option 1" and "Radio Option 2" with imageicon and "Radio Option 3" without imageicon,
and initially selects "Radio Option 1"

The program selects "Radio Option 1" initially so it should be highlighted to indicate it is selected (this is what is done in Windows 10 Java side)
![Optional _thumb_113664](https://github.com/user-attachments/assets/8b628210-3012-478c-bc3f-89b993dbba6d)

Did you see any highlight in "Radio Option 1" like above when you render the program as it is, before selecting "Radio Option 3" (which is what I did manually )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2749933651

From kizune at openjdk.org  Tue Mar 25 03:15:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 25 Mar 2025 03:15:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <uWnbccxSKvTTUiFcasqScBoFOeYI1gBlFehnUtqPYxQ=.6501f91c-b4bd-4418-a03a-e24a622fbd0a@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
 <uWnbccxSKvTTUiFcasqScBoFOeYI1gBlFehnUtqPYxQ=.6501f91c-b4bd-4418-a03a-e24a622fbd0a@github.com>
Message-ID: <e56sFV62ClXBTLzfdUdhbYQTO2BNJ4Z5k6aq996pVBY=.7e19221a-6fc8-4765-91f1-8553f034e531@github.com>

On Tue, 25 Mar 2025 03:02:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Did you see any highlight in "Radio Option 1" like above when you render the program as it is, before selecting "Radio Option 3" (which is what I did manually )

Yes, the background of the selected icon was bluish as it is on the "Radio Option 3" icon on my screenshot so one can easily distinguish the selected radio button even when the icon itself does not reflect the status.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2749946044

From psadhukhan at openjdk.org  Tue Mar 25 03:18:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Mar 2025 03:18:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <e56sFV62ClXBTLzfdUdhbYQTO2BNJ4Z5k6aq996pVBY=.7e19221a-6fc8-4765-91f1-8553f034e531@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
 <uWnbccxSKvTTUiFcasqScBoFOeYI1gBlFehnUtqPYxQ=.6501f91c-b4bd-4418-a03a-e24a622fbd0a@github.com>
 <e56sFV62ClXBTLzfdUdhbYQTO2BNJ4Z5k6aq996pVBY=.7e19221a-6fc8-4765-91f1-8553f034e531@github.com>
Message-ID: <mmvy3DlEBDbTN_9q07F6TFe-37dWJ1uRR1vaNF1ApFM=.d67715f6-f01b-4b0f-89b1-6997d6d51e33@github.com>

On Tue, 25 Mar 2025 03:12:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Did you see any highlight in "Radio Option 1" like above when you render the program as it is, before selecting "Radio Option 3" (which is what I did manually )
> 
> Yes, the background of the selected icon was bluish as it is on the "Radio Option 3" icon on my screenshot so one can easily distinguish the selected radio button even when the icon itself does not reflect the status.

OK. Thanks...Can you please paste that screenshot also as reference?

@prrace Then I guess we can safely say Windows 11 has introduced this "regression" of not highlighting the selected radio/checkmenuitem and can raise a WIndows platform ticket

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2749950154

From mbaesken at openjdk.org  Tue Mar 25 08:04:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Mar 2025 08:04:18 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build [v3]
In-Reply-To: <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
 <tftU4gQCsrK3eZSXyjAeROqE_Zh1rc9R49XLB1zuwnM=.e723fd6a-464d-469e-897d-d5696ba0808b@github.com>
Message-ID: <cobrER0RU3kiQn8bDPbkExQsCxXSNIB2PaxZ4ygOoD8=.cae52699-681d-4409-9cc2-0007fe9bb6d0@github.com>

On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
>> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
>> 
>> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case

Thanks for the review Phil !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2750397465

From mbaesken at openjdk.org  Tue Mar 25 08:04:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Mar 2025 08:04:19 GMT
Subject: Integrated: 8351277: Remove pipewire from AIX build
In-Reply-To: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
References: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>
Message-ID: <OptUmzIPM3LBHAG_jc4vU7am8zbh5TqvUNx1UroJ13U=.a341e344-c38c-4fb4-b54c-fdcd22724391@github.com>

On Wed, 12 Mar 2025 14:52:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
> Reason is that pipewire updates can break the AIX build, so better avoid it if possible.
> 
> To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

This pull request has now been integrated.

Changeset: 6bc48035
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bc480358c80b0a1a94b5ca5f4b7ff2d84ce8e37
Stats:     42 lines in 4 files changed: 36 ins; 5 del; 1 mod

8351277: Remove pipewire from AIX build

Reviewed-by: ihse, prr, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/24009

From psadhukhan at openjdk.org  Tue Mar 25 09:27:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Mar 2025 09:27:06 GMT
Subject: RFR: 8352676: Opensource JMenu tests - series1
Message-ID: <SCSXFINdJ_3FrG97_8UkhiykGL2MzGaFPqF0p_JjuFg=.3f9df293-9491-4c39-8e26-600dc579dd34@github.com>

Few JMenu tests are opensourced

-------------

Commit messages:
 - 8352676: Opensource JMenu tests - series1

Changes: https://git.openjdk.org/jdk/pull/24220/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24220&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352676
  Stats: 297 lines in 3 files changed: 297 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24220.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24220/head:pull/24220

PR: https://git.openjdk.org/jdk/pull/24220

From azvegint at openjdk.org  Tue Mar 25 09:55:13 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Mar 2025 09:55:13 GMT
Subject: RFR: 8352676: Opensource JMenu tests - series1
In-Reply-To: <SCSXFINdJ_3FrG97_8UkhiykGL2MzGaFPqF0p_JjuFg=.3f9df293-9491-4c39-8e26-600dc579dd34@github.com>
References: <SCSXFINdJ_3FrG97_8UkhiykGL2MzGaFPqF0p_JjuFg=.3f9df293-9491-4c39-8e26-600dc579dd34@github.com>
Message-ID: <9p4Lt2R5mPOTydQ5JAwblfJd1x1VWwn-i494LTQJIzY=.b33702ae-7ed7-4a81-8961-6e6f1a839ce7@github.com>

On Tue, 25 Mar 2025 09:22:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenu tests are opensourced

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24220#pullrequestreview-2713096444

From psadhukhan at openjdk.org  Tue Mar 25 10:38:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Mar 2025 10:38:26 GMT
Subject: Integrated: 8352676: Opensource JMenu tests - series1
In-Reply-To: <SCSXFINdJ_3FrG97_8UkhiykGL2MzGaFPqF0p_JjuFg=.3f9df293-9491-4c39-8e26-600dc579dd34@github.com>
References: <SCSXFINdJ_3FrG97_8UkhiykGL2MzGaFPqF0p_JjuFg=.3f9df293-9491-4c39-8e26-600dc579dd34@github.com>
Message-ID: <XMVRSyaEnpmq4nPj7-_pH0m5PuA-0F0PoJBECBQYFPM=.b235bbf7-d61c-4fb2-aef8-3deb9aedc5eb@github.com>

On Tue, 25 Mar 2025 09:22:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenu tests are opensourced

This pull request has now been integrated.

Changeset: c002b97e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c002b97ee99c1889aa89e0a8853beafaf0969e9c
Stats:     297 lines in 3 files changed: 297 ins; 0 del; 0 mod

8352676: Opensource JMenu tests - series1

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/24220

From dgredler at openjdk.org  Tue Mar 25 14:27:56 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 25 Mar 2025 14:27:56 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike
Message-ID: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>

FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.

When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

-------------

Commit messages:
 - Remove unnecessary Windows version check in FileFontStrike

Changes: https://git.openjdk.org/jdk/pull/24230/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352890
  Stats: 15 lines in 2 files changed: 1 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24230/head:pull/24230

PR: https://git.openjdk.org/jdk/pull/24230

From serb at openjdk.org  Tue Mar 25 15:39:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Mar 2025 15:39:24 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
 <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
Message-ID: <zye9iVM8AK70RuqU_2nm4evvJavym_cl3s2s-HDrBvk=.09c36435-63ea-4bee-adb1-ffc6f7124b41@github.com>

On Sat, 15 Mar 2025 00:16:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

> The click occurs at the edge of the screen. You can run the test attached with the screenshot mode on (this will display the mouse location) and once the test is finished the mouse will display coordinates at the edge of the screen. If you move any windows onto the edge of the screen where the mouse appears to end up and run the test again, then do a simple manual click, that window will gain focus. So the actual mouse pointer isn't at (10000,10000) but rather at the edge of the screen.

So this seems to be a bug in macOS, as the reported mouse location is incorrect while it is actually positioned at the edge?

Probably, there are other macOS APIs that could be used to implement Java_sun_lwawt_macosx_CCursorManager_nativeGetCursorPosition. Or perhaps the methods within it should be called on the appkit thread - I see a potential race, since the mouse is moved asynchronously on appkit, but the coordinates are fetched on the current thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2751687192

From prr at openjdk.org  Tue Mar 25 16:18:18 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Mar 2025 16:18:18 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <hzfPeem4DR3uEL1HyoEpgsozz0ynEogxlOecT_mZTwQ=.04abfd75-1d0e-4041-9f93-aec2106201fc@github.com>

On Tue, 25 Mar 2025 14:21:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24230#pullrequestreview-2714384813

From aivanov at openjdk.org  Tue Mar 25 17:38:48 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Mar 2025 17:38:48 GMT
Subject: RFR: 8352624: Add missing {@code} to PassFailJFrame.Builder.splitUI
Message-ID: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>

A trivial fix to add `{@code}` to the description of `splitUI` methods in `PassFailJFrame.Builder`.

-------------

Commit messages:
 - 8352624: Add missing {@code} to PassFailJFrame.Builder.splitUI

Changes: https://git.openjdk.org/jdk/pull/24235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352624
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24235/head:pull/24235

PR: https://git.openjdk.org/jdk/pull/24235

From serb at openjdk.org  Tue Mar 25 18:07:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Mar 2025 18:07:24 GMT
Subject: RFR: 8352624: Add missing {@code} to
 PassFailJFrame.Builder.splitUI
In-Reply-To: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
References: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
Message-ID: <2YBoS5a73S4iTMsJDK4efp1obCHbGuvbm6L-ox0zAq4=.fe11c952-e902-487e-afd2-aae2c015f327@github.com>

On Tue, 25 Mar 2025 17:32:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial fix to add `{@code}` to the description of `splitUI` methods in `PassFailJFrame.Builder`.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24235#pullrequestreview-2714720789

From duke at openjdk.org  Wed Mar 26 01:39:34 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Mar 2025 01:39:34 GMT
Subject: Withdrawn: 8342870: Errors related to unused code on Windows after
 8339120 in accessibility
In-Reply-To: <p2WnEH3ESxSUdxsjonHB4TFRQbGeWsFMIV1ouL0wxuo=.063a11ff-625d-4a49-bc64-b74052721ebc@github.com>
References: <p2WnEH3ESxSUdxsjonHB4TFRQbGeWsFMIV1ouL0wxuo=.063a11ff-625d-4a49-bc64-b74052721ebc@github.com>
Message-ID: <NWnlSujARzrgOU0a3j-nKBv770YRmpPXXS-L4h9uwls=.01b1c3d6-8f7c-463c-b2b3-38027993eb2a@github.com>

On Wed, 23 Oct 2024 05:17:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable]
>   334 |         bool freeData = false;
>       |              ^~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable]
>   326 |     DWORD retval = -1;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable]
>   379 |         bool freeData = false;
>       |              ^~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable]
>   367 |     DWORD retval = -1;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibi...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21656

From serb at openjdk.org  Wed Mar 26 05:56:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 05:56:37 GMT
Subject: RFR: 8352922: Refactor client classes javadoc to use @throws instead
 of @exception
Message-ID: <y96S7Dt0Lii5JRBHVf-SmSvY2Jjk3_0rYk278SKZjWM=.8ccf44d5-beaf-4bf0-b52d-4b69fb6a0da2@github.com>

Prevailing JDK coding practices use @throws rather than @exception.
Refactored javadoc in client code to follow this convention, similar requests in the past https://github.com/openjdk/jdk/pull/7675 and https://github.com/openjdk/jdk/pull/7644.

-------------

Commit messages:
 - Refactor client classes javadoc to use @throws instead of @exception

Changes: https://git.openjdk.org/jdk/pull/24239/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352922
  Stats: 14 lines in 10 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24239/head:pull/24239

PR: https://git.openjdk.org/jdk/pull/24239

From rmarchenko at openjdk.org  Wed Mar 26 06:35:11 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 26 Mar 2025 06:35:11 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
Message-ID: <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>

On Mon, 24 Mar 2025 18:43:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing review comments
>
> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 114:
> 
>> 112:                 }
>> 113:                 for (Method method : iface.getMethods()) {
>> 114:                     if (!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()) {
> 
> I have looked into the `Modifier` class to check which other modifiers we have, and I found that you might also want to skip static and private methods. Perhaps method.isDefault() is the method you're looking for? It seems like none of the tests catch that?
> 
> Also please double check the code a few lines above:
> 
>                             method = MethodFinder.findAccessibleMethod(method);
>                             if (!method.getDeclaringClass().isInterface()) {
>                                 method = null; // ignore methods from superclasses
>                             }
> 
>  - ~~Why do we need to skip the methods from the interfaces? Maybe we can inject our logic there?~~
>  - The method `MethodFinder.findAccessibleMethod` also checks each method to be `isExported`

Are you thinking of specific test cases that are not covered here? Could you share, please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2013474962

From jwaters at openjdk.org  Wed Mar 26 06:53:15 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Mar 2025 06:53:15 GMT
Subject: RFR: 8342870: Errors related to unused code on Windows after
 8339120 in accessibility [v6]
In-Reply-To: <Wa3hQx95MvKD1hnFK7T0HxRUCBv78p4eL-96MRc6s7M=.86fc8a85-753a-43b2-b328-9c981f3a97ab@github.com>
References: <p2WnEH3ESxSUdxsjonHB4TFRQbGeWsFMIV1ouL0wxuo=.063a11ff-625d-4a49-bc64-b74052721ebc@github.com>
 <Wa3hQx95MvKD1hnFK7T0HxRUCBv78p4eL-96MRc6s7M=.86fc8a85-753a-43b2-b328-9c981f3a97ab@github.com>
Message-ID: <WJ63qBfDvIhSyLvzuixE1VvWjCG1Dy8iQAu8gUfU-U4=.739e6839-1135-4ad7-8ebe-3c1690d27a48@github.com>

On Thu, 23 Jan 2025 05:37:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>> 
>> build.log on release configuration:
>> 
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()':
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable]
>>   334 |         bool freeData = false;
>>       |              ^~~~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable]
>>   326 |     DWORD retval = -1;
>>       |           ^~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)':
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable]
>>   379 |         bool freeData = false;
>>       |              ^~~~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable]
>>   367 |     DWORD retval = -1;
>>       |           ^~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge':
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3...
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Typo in AccessBridgeCalls.c
>  - Fix AccessBridgeCalls.c

No.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2753399070

From serb at openjdk.org  Wed Mar 26 08:03:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 08:03:14 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
Message-ID: <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>

On Wed, 26 Mar 2025 06:32:22 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 114:
>> 
>>> 112:                 }
>>> 113:                 for (Method method : iface.getMethods()) {
>>> 114:                     if (!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()) {
>> 
>> I have looked into the `Modifier` class to check which other modifiers we have, and I found that you might also want to skip static and private methods. Perhaps method.isDefault() is the method you're looking for? It seems like none of the tests catch that?
>> 
>> Also please double check the code a few lines above:
>> 
>>                             method = MethodFinder.findAccessibleMethod(method);
>>                             if (!method.getDeclaringClass().isInterface()) {
>>                                 method = null; // ignore methods from superclasses
>>                             }
>> 
>>  - ~~Why do we need to skip the methods from the interfaces? Maybe we can inject our logic there?~~
>>  - The method `MethodFinder.findAccessibleMethod` also checks each method to be `isExported`
>
> Are you thinking of specific test cases that are not covered here? Could you share, please? Or just about code refactoring?

I wonder if we can return non-public or static methods from non-exported interface? In other words are the checks `!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()` are good enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2013574039

From serb at openjdk.org  Wed Mar 26 08:08:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 08:08:19 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <9JPQ6Loi9YqHNXB774QHOtZZqcVvKd9dk3WA_Ihlbco=.e5b25e12-36b1-41e3-b063-b42db02b1d34@github.com>

On Tue, 25 Mar 2025 14:21:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

src/java.desktop/share/classes/sun/font/FileFontStrike.java line 119:

> 117:     private static native void initNative();
> 118:     static {
> 119:         if (FontUtilities.isWindows && !FontUtilities.useJDKScaler && !GraphicsEnvironment.isHeadless()) {

Please split long lines per 80 chars.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2013581053

From rmarchenko at openjdk.org  Wed Mar 26 08:29:10 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 26 Mar 2025 08:29:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
Message-ID: <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>

On Wed, 26 Mar 2025 08:00:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Are you thinking of specific test cases that are not covered here? Could you share, please? Or just about code refactoring?
>
> I wonder if we can return non-public or static methods from non-exported interface? In other words are the checks `!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()` are good enough?

There is the static method is the test scenario 1.

OK, I'd add the following methods to `interface A4`:

        public static int getStaticValue() {
            return 0;
        }
        private int getPrivateValue() {
            return 0;
        }

Is this the case you're thinking of?

Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2013608180

From serb at openjdk.org  Wed Mar 26 08:39:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 08:39:10 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <qiQ7umoxvA-lELTru7wOHNvJnOgMzgEi3P1Vq1WGCqo=.88d29ce4-3588-4782-b24b-bea2152b3d53@github.com>

On Tue, 25 Mar 2025 14:21:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

src/java.desktop/windows/native/libfontmanager/lcdglyph.c line 126:

> 124: 
> 125: JNIEXPORT void JNICALL Java_sun_font_FileFontStrike_initNative(JNIEnv *env, jclass unused) {
> 126:     memset(igLUTable, 0, sizeof igLUTable);

This line was updated in https://github.com/openjdk/jdk/pull/9772 but I wonder if we actually need it? can we initialize it in the code above with = {0}?
BTW what is the default content of this global static array - zeros? I still prefer {0} for readability even if default is zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2013624736

From perini.davide at dpsoftware.org  Wed Mar 26 13:47:16 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Wed, 26 Mar 2025 14:47:16 +0100
Subject: jpackage and Wix 5
In-Reply-To: <163dabab-ddb8-4029-bede-9bd3227851f4@dpsoftware.org>
References: <af28d9a1161adf30dcf0b2d180a02177@dpsoftware.org>
 <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>
 <163dabab-ddb8-4029-bede-9bd3227851f4@dpsoftware.org>
Message-ID: <027609fdba4abf065686517c579cc3a1@dpsoftware.org>



If I use Wix 3 it works correctly,
are we sure that jpackage 24 supports Wix 5?

Is this a bug in the jpacakge command?

On 2025-03-19 11:45, Davide Perini wrote:

> Il 19/03/2025 11:19, Davide Perini ha scritto: I add some context:
> 
> I installed wix 5 using the donet command globally,
> wix is in the path but when I try to run my jpackage command I get this 
> error:
> 
> jpackage -i ./target --type exe --main-class 
> org.dpsoftware.JavaFXStarter --main-jar 
> FireflyLuciferin-jar-with-dependencies.jar --icon 
> ./data/img/luciferin_logo.ico
> --win-menu --win-menu-group Ambilight --copyright "Davide Perini" 
> --name "Firefly Luciferin"  --vendor DPsoftware --win-dir-chooser 
> --win-shortcut --win-per-user-install --win-shortcut 
> --win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
> 
> java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none, 
> -intermediatefolder, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj, 
> -ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
> .wixext, -b, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\
> Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
> dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl, 
> -culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d, 
> JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d, 
> JpProductCode=e0be8901-8911-3da4
> -83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d, 
> JpAllowDowngrades=yes, -d, 
> JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin\Firefly Luciferin.exe, -d, JpAp
> pSizeKb=409283, -d, JpAppVersion=1.0, -d, 
> JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d, 
> JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d, 
> JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
> T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx 
> f, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
> age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi] 
> in 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin exited with 144 code
> 
> Il 19/03/2025 10:12, Davide Perini ha scritto:
> Hi there,
> 
> I'm using jpackage along with Wix3.
> 
> The command I use to generate my .exe is:
> jpackage -i ../../target --type exe --main-class 
> org.dpsoftware.JavaFXStarter --main-jar 
> FireflyLuciferin-jar-with-dependencies.jar --icon 
> ../../data/img/java_fast_screen_capture_logo.ico --win-menu 
> --win-menu-group Luciferin --copyright "Davide Perini" --name "Firefly 
> Luciferin"  --vendor DPsoftware --win-dir-chooser --win-shortcut 
> --win-per-user-install --win-upgrade-uuid myuuid --app-version 
> "${{steps.get-id.outputs.id}}" --win-shortcut --win-shortcut-prompt 
> --java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m 
> -Xmx1024m --add-modules=jdk.incubator.vector"
> 
> How can I move it to Wix5 using Java 24?
> 
> Is there a guide/documentation that help in migrating from Wix 3 to Wix 
> 5?
> 
> Thanks
> Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250326/e66aa495/attachment-0001.htm>

From dgredler at openjdk.org  Wed Mar 26 14:26:43 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 14:26:43 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v2]
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <ngXrknOept-fN2UGksbWtwx6ld9IR1OIERL5QnVnjAg=.3cf1bf96-bdbd-4baa-a6a7-6c27bdc88576@github.com>

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Wrap line at 80 chars

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24230/files
  - new: https://git.openjdk.org/jdk/pull/24230/files/79e1b2ea..6e0d4910

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24230&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24230/head:pull/24230

PR: https://git.openjdk.org/jdk/pull/24230

From dgredler at openjdk.org  Wed Mar 26 14:26:43 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 14:26:43 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v2]
In-Reply-To: <9JPQ6Loi9YqHNXB774QHOtZZqcVvKd9dk3WA_Ihlbco=.e5b25e12-36b1-41e3-b063-b42db02b1d34@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <9JPQ6Loi9YqHNXB774QHOtZZqcVvKd9dk3WA_Ihlbco=.e5b25e12-36b1-41e3-b063-b42db02b1d34@github.com>
Message-ID: <B10He6rEP23YoWJGl8PrOcYJ2TWmHJyInbDt-WnX-80=.386b39aa-9ac9-4211-b6c8-90c4ed121a8f@github.com>

On Wed, 26 Mar 2025 08:05:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap line at 80 chars
>
> src/java.desktop/share/classes/sun/font/FileFontStrike.java line 119:
> 
>> 117:     private static native void initNative();
>> 118:     static {
>> 119:         if (FontUtilities.isWindows && !FontUtilities.useJDKScaler && !GraphicsEnvironment.isHeadless()) {
> 
> Please split long lines per 80 chars.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2014286858

From dgredler at openjdk.org  Wed Mar 26 14:35:14 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 14:35:14 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v2]
In-Reply-To: <qiQ7umoxvA-lELTru7wOHNvJnOgMzgEi3P1Vq1WGCqo=.88d29ce4-3588-4782-b24b-bea2152b3d53@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <qiQ7umoxvA-lELTru7wOHNvJnOgMzgEi3P1Vq1WGCqo=.88d29ce4-3588-4782-b24b-bea2152b3d53@github.com>
Message-ID: <_7ZV0jq7b7p9Vc68Mz7-RYlC-Nh-ay7SSUjBf-UjHwY=.2508b09e-43a7-4815-aa2c-65dbaec484a6@github.com>

On Wed, 26 Mar 2025 08:36:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap line at 80 chars
>
> src/java.desktop/windows/native/libfontmanager/lcdglyph.c line 126:
> 
>> 124: 
>> 125: JNIEXPORT void JNICALL Java_sun_font_FileFontStrike_initNative(JNIEnv *env, jclass unused) {
>> 126:     memset(igLUTable, 0, sizeof igLUTable);
> 
> This line was updated in https://github.com/openjdk/jdk/pull/9772 but I wonder if we actually need it? can we initialize it in the code above with = {0}? If that is possible we can drop this method completely.
> BTW what is the default content of this global static array - zeros? I still prefer {0} for readability even if default is zero.

I'll defer to you and Phil on this one. The existing code base seems to use `memset` much more often than vanilla array init, even just for zeroes. I had also assumed that we would want to keep `initNative`, rather than initializing immediately, but I'm happy to eliminate it if my assumption was wrong.

@prrace: Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2014313902

From dgredler at openjdk.org  Wed Mar 26 14:40:34 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 14:40:34 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2
Message-ID: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>

Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.

No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.

-------------

Commit messages:
 - Remove unnecessary Windows version check in Win32ShellFolderManager2

Changes: https://git.openjdk.org/jdk/pull/24256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352970
  Stats: 59 lines in 2 files changed: 57 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24256/head:pull/24256

PR: https://git.openjdk.org/jdk/pull/24256

From duke at openjdk.org  Wed Mar 26 15:22:23 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Mar 2025 15:22:23 GMT
Subject: Withdrawn: 8349157: Unnecessary Hashtable usage in
 XKeysym.javaKeycode2KeysymHash
In-Reply-To: <JXTTDKPO9mbxEP4DzlmaaVo5uNg3IbsIR9SDR40aOcg=.c79433ce-4898-4e52-a52a-733c4df16d6d@github.com>
References: <JXTTDKPO9mbxEP4DzlmaaVo5uNg3IbsIR9SDR40aOcg=.c79433ce-4898-4e52-a52a-733c4df16d6d@github.com>
Message-ID: <WZNCe75jOOtqDrM7lZJWNAg8vhWBfXy9tlOKfQHlCPA=.acda5ded-7dd9-41e1-acd7-c1c74ac2dd19@github.com>

On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class.
> As this map is read-only and all its content is initialized in `<clinit>` we can safely use immutable Map instead.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23347

From philip.race at oracle.com  Wed Mar 26 17:18:23 2025
From: philip.race at oracle.com (Philip Race)
Date: Wed, 26 Mar 2025 10:18:23 -0700
Subject: =?UTF-8?Q?Re=3A_8246742=EF=BC=9AInquiry_about_PrintDialog_Propertie?=
 =?UTF-8?Q?s_button_behavior_on_Linux?=
In-Reply-To: <CAMBge5P=jWbYqCSjH0CbggPPF5_un1s9B+A30Xyz8bp_vVAdEw@mail.gmail.com>
References: <CAMBge5P=jWbYqCSjH0CbggPPF5_un1s9B+A30Xyz8bp_vVAdEw@mail.gmail.com>
Message-ID: <3acae65e-ac24-4002-9b31-8e6afb4e62eb@oracle.com>

 1. 1.Is this considered an accepted platform behavior difference?
 2. yes. The properties for windows is the only way to allow the user to
    interact with driver extensions which NO platform API supports.
 3. 2.Are there any plans to implement native printer property support
    for Linux/MacOS?
 4. *no, for starters there is no such thing on Linux. Different
    toolkits provide a printer dialog but none of them are "native"*
 5. in the same way that the windows one is.

 1. 3.Would there be value in creating a feature request for this
    capability?

 ??? no, because there's nothing to expose.

FYI, OpenJDK mailing lists are not for support. They are lists to 
discuss the code changes being made by people contributing fixes.

-phil.

On 3/24/25 7:06 PM, last last wrote:
>
> *Dear OpenJDK Community,*
>
> I'm writing regarding an observation about the PrintDialog's 
> Properties button behavior on Linux platforms. On my Ubuntu 20.04 
> system (OpenJDK version: 17), I noticed that the Properties button in 
> the print dialog remains disabled.
>
> Through previous research, I found this is documented in [JDK-8246742] 
> ServiceUI.printDialog does not support properties dialog - Java Bug 
> System <https://bugs.openjdk.org/browse/JDK-8246742>?. The ticket 
> suggests this behavior was intentionally implemented.
>
> But from a user perspective, this disabled state raises some concerns:
>
>  1. 1.Users familiar with Windows implementation may find this
>     inconsistent
>  2. 2.Prevents access to printer-specific options that might otherwise
>     be configurable
>  3. 3.Could be confusing for applications relying on this functionality
>
> Reproducer:
> import java.awt.*;
> import java.awt.print.*;
>
> public class PrintDialogExample implements Printable {
>
> ? ? public static void main(String[] args) {
> ? ? ? ? // ?? PrinterJob ??
> ? ? ? ? PrinterJob printerJob = PrinterJob.getPrinterJob();
>
> ? ? ? ? // ??????
> printerJob.setPrintable(new PrintDialogExample());
>
> ? ? ? ? // ???????
> ? ? ? ? if (printerJob.printDialog()) {
> ? ? ? ? ? ? try {
> ? ? ? ? ? ? ? ? // ??????
> printerJob.print();
> System.out.println("Printing complete.");
> ? ? ? ? ? ? } catch (PrinterException e) {
> e.printStackTrace();
> ? ? ? ? ? ? }
> ? ? ? ? } else {
> System.out.println("Printing cancelled.");
> ? ? ? ? }
> ? ? }
>
> ? ? @Override
> ? ? public int print(Graphics graphics, PageFormat pageFormat, int 
> pageIndex) throws PrinterException {
> ? ? ? ? // ??????
> ? ? ? ? if (pageIndex > 0) {
> ? ? ? ? ? ? return Printable.NO_SUCH_PAGE;
> ? ? ? ? }
>
> ? ? ? ? // ? Graphics ????? Graphics2D
> ? ? ? ? Graphics2D g2d = (Graphics2D) graphics;
>
> ? ? ? ? // ???????
> g2d.setFont(new Font("Serif", Font.PLAIN, 12));
> g2d.setColor(Color.BLACK);
>
> ? ? ? ? // ????
> ? ? ? ? String text = "Hello, this is a test print job!";
> g2d.drawString(text, 100, 100);
>
> ? ? ? ? // ??????
> ? ? ? ? return Printable.PAGE_EXISTS;
> ? ? }
> }
>
> I'd like to inquire:
>
>  1. 1.Is this considered an accepted platform behavior difference?
>  2. 2.Are there any plans to implement native printer property support
>     for Linux/MacOS?
>  3. 3.Would there be value in creating a feature request for this
>     capability?
>
> Additional environment details:
>
>   * Desktop Environment: GNOME [3.34.3-0ubuntu1 ]
>   * Default Print System: CUPS [2.3.1-9ubuntu1.4]
>
> Thank you for your insights. I'm happy to provide further testing 
> support if needed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250326/beb1fefc/attachment-0001.htm>

From prr at openjdk.org  Wed Mar 26 17:34:19 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Mar 2025 17:34:19 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v2]
In-Reply-To: <_7ZV0jq7b7p9Vc68Mz7-RYlC-Nh-ay7SSUjBf-UjHwY=.2508b09e-43a7-4815-aa2c-65dbaec484a6@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <qiQ7umoxvA-lELTru7wOHNvJnOgMzgEi3P1Vq1WGCqo=.88d29ce4-3588-4782-b24b-bea2152b3d53@github.com>
 <_7ZV0jq7b7p9Vc68Mz7-RYlC-Nh-ay7SSUjBf-UjHwY=.2508b09e-43a7-4815-aa2c-65dbaec484a6@github.com>
Message-ID: <mBtWZesmm7gP8iDATCBRtrBpFZZAv2dOwfbvZb1KccY=.b83a053b-8cc7-4ddd-bbd6-a0d2577d2892@github.com>

On Wed, 26 Mar 2025 14:32:05 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> src/java.desktop/windows/native/libfontmanager/lcdglyph.c line 126:
>> 
>>> 124: 
>>> 125: JNIEXPORT void JNICALL Java_sun_font_FileFontStrike_initNative(JNIEnv *env, jclass unused) {
>>> 126:     memset(igLUTable, 0, sizeof igLUTable);
>> 
>> This line was updated in https://github.com/openjdk/jdk/pull/9772 but I wonder if we actually need it? can we initialize it in the code above with = {0}? If that is possible we can drop this method completely.
>> BTW what is the default content of this global static array - zeros? I still prefer {0} for readability even if default is zero.
>
> I'll defer to you and Phil on this one. The existing code base seems to use `memset` much more often than vanilla array init, even just for zeroes. I had also assumed that we would want to keep `initNative`, rather than initializing immediately, but I'm happy to eliminate it if my assumption was wrong.
> 
> @prrace: Thoughts?

initNative used to do more .. it used to actually check whether it was XP or later .. somewhere along the line that functionality was removed. Probably the method can be removed. But you'd have to be sure the initializer works, and I'd need to run it through the test system.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2014670481

From serb at openjdk.org  Wed Mar 26 18:29:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 18:29:14 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
Message-ID: <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>

On Wed, 26 Mar 2025 08:25:13 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> I wonder if we can return non-public or static methods from non-exported interface? In other words are the checks `!Modifier.isAbstract(method.getModifiers()) && !method.isBridge()` are good enough?
>
> There is the static method is the test scenario 1. Also there is the test scenario 7 to show that `method.isDefault()` is not enough here.
> 
> OK, I'd add the following methods to `interface A4`:
> 
>         public static int getStaticValue() {
>             return 0;
>         }
>         private int getPrivateValue() {
>             return 0;
>         }
> 
> Is this the case you're thinking of?
> 
> Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?

Let me try experimenting with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2014780939

From serb at openjdk.org  Wed Mar 26 19:25:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 19:25:19 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
Message-ID: <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>

On Wed, 26 Mar 2025 18:24:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There is the static method is the test scenario 1. Also there is the test scenario 7 to show that `method.isDefault()` is not enough here.
>> 
>> OK, I'd add the following methods to `interface A4`:
>> 
>>         public static int getStaticValue() {
>>             return 0;
>>         }
>>         private int getPrivateValue() {
>>             return 0;
>>         }
>> 
>> Is this the case you're thinking of?
>> 
>> Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?
>
> Let me try experimenting with that.

BTW please merge the master branch, the current branch is way too outdated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2014857940

From dgredler at openjdk.org  Wed Mar 26 19:49:46 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 19:49:46 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
Message-ID: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>

> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Add 'Test' suffix to test class name, remove unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24256/files
  - new: https://git.openjdk.org/jdk/pull/24256/files/e802646e..3409da27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24256&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24256/head:pull/24256

PR: https://git.openjdk.org/jdk/pull/24256

From serb at openjdk.org  Wed Mar 26 20:03:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 20:03:21 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
 <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
 <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>
Message-ID: <1NkNNs9RxXcHMphPbjjO94h1o_ZlN_aII_o_0vN1HvA=.c50df7ab-836e-4077-92ca-47e0207b4913@github.com>

On Wed, 26 Mar 2025 19:58:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> BTW please merge the master branch, the current branch is way too outdated.
>
>> Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?
> 
> It looks like for classes it was implemented as follows:
>  - getPropertyDescriptors() checks only instance methods getXXX()/setXXX()
>  - getMethodDescriptors() returns all methods of the class, including static ones, but static methods are not considered properties
> 
> It would be good to cover this by the test

Also, in the code above, it is not necessary to filter out private methods since iface.getMethods() returns only public

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2014916624

From serb at openjdk.org  Wed Mar 26 20:03:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 20:03:21 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
 <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
Message-ID: <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>

On Wed, 26 Mar 2025 19:22:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Let me try experimenting with that.
>
> BTW please merge the master branch, the current branch is way too outdated.

> Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?

It looks like for classes it was implemented as follows:
 - getPropertyDescriptors() checks only instance methods getXXX()/setXXX()
 - getMethodDescriptors() returns all methods of the class, including static ones, but static methods are not considered properties

It would be good to cover this by the test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2014915435

From serb at openjdk.org  Wed Mar 26 20:03:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Mar 2025 20:03:21 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <1NkNNs9RxXcHMphPbjjO94h1o_ZlN_aII_o_0vN1HvA=.c50df7ab-836e-4077-92ca-47e0207b4913@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
 <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
 <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>
 <1NkNNs9RxXcHMphPbjjO94h1o_ZlN_aII_o_0vN1HvA=.c50df7ab-836e-4077-92ca-47e0207b4913@github.com>
Message-ID: <vUEEAvsOkyHahPZW1EBX5Pg7qD2wh2kH16RNEIIKYC4=.049a54ce-5777-437d-b987-e7a09c2f0421@github.com>

On Wed, 26 Mar 2025 19:59:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Redarding properties, I think the implementation is OK. The only question in this case is should `getMethodDescriptors()` contain the static method (`public static int DefaultMethodBeanPropertyTest$A4.getStaticValue()`) or not?
>> 
>> It looks like for classes it was implemented as follows:
>>  - getPropertyDescriptors() checks only instance methods getXXX()/setXXX()
>>  - getMethodDescriptors() returns all methods of the class, including static ones, but static methods are not considered properties
>> 
>> It would be good to cover this by the test
>
> Also, in the code above, it is not necessary to filter out private methods since iface.getMethods() returns only public

The last question I have is about the module system when the interface is not exported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2014917885

From dgredler at openjdk.org  Wed Mar 26 21:14:24 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 21:14:24 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Completely remove FileFontStrike.initNative()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24230/files
  - new: https://git.openjdk.org/jdk/pull/24230/files/6e0d4910..16869595

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24230&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24230&range=01-02

  Stats: 14 lines in 2 files changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24230/head:pull/24230

PR: https://git.openjdk.org/jdk/pull/24230

From dgredler at openjdk.org  Wed Mar 26 21:14:24 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Mar 2025 21:14:24 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <mBtWZesmm7gP8iDATCBRtrBpFZZAv2dOwfbvZb1KccY=.b83a053b-8cc7-4ddd-bbd6-a0d2577d2892@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <qiQ7umoxvA-lELTru7wOHNvJnOgMzgEi3P1Vq1WGCqo=.88d29ce4-3588-4782-b24b-bea2152b3d53@github.com>
 <_7ZV0jq7b7p9Vc68Mz7-RYlC-Nh-ay7SSUjBf-UjHwY=.2508b09e-43a7-4815-aa2c-65dbaec484a6@github.com>
 <mBtWZesmm7gP8iDATCBRtrBpFZZAv2dOwfbvZb1KccY=.b83a053b-8cc7-4ddd-bbd6-a0d2577d2892@github.com>
Message-ID: <Io_KXy1UacUapVJF7LJjZ0nx7PMSrhNCz1KjvUrsDgQ=.99bb938a-730c-4b84-a6f9-e5f58073630c@github.com>

On Wed, 26 Mar 2025 17:31:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> I'll defer to you and Phil on this one. The existing code base seems to use `memset` much more often than vanilla array init, even just for zeroes. I had also assumed that we would want to keep `initNative`, rather than initializing immediately, but I'm happy to eliminate it if my assumption was wrong.
>> 
>> @prrace: Thoughts?
>
> initNative used to do more .. it used to actually check whether it was XP or later .. somewhere along the line that functionality was removed. Probably the method can be removed. But you'd have to be sure the initializer works, and I'd need to run it through the test system.

OK, the extra simplification looks like it's working correctly on my Win10 machine. Please have a look and submit that test run, when you get a chance. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24230#discussion_r2015005145

From prr at openjdk.org  Wed Mar 26 22:12:13 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Mar 2025 22:12:13 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
Message-ID: <anp1vKZU-lLVj3aQNW5LRqxcimYngPuuA3eEIZGnO8A=.107ce561-563d-4969-b976-f8323d1cdab8@github.com>

On Wed, 26 Mar 2025 21:14:24 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely remove FileFontStrike.initNative()

Looks OK. Submitting a test job. It takes a while, so don't wait up for the results :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24230#issuecomment-2755854666

From alexey.semenyuk at oracle.com  Wed Mar 26 22:16:47 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 26 Mar 2025 18:16:47 -0400
Subject: Fwd: jpackage and Wix 5
In-Reply-To: <2244140e-52e8-4a22-abb5-ebb1ba41dcc3@oracle.com>
References: <027609fdba4abf065686517c579cc3a1@dpsoftware.org>
 <2244140e-52e8-4a22-abb5-ebb1ba41dcc3@oracle.com>
Message-ID: <7271a15f-a918-4691-b622-f7f2b10c5584@oracle.com>

Davide,

I replied to your question in the core-libs-dev mailing list. See [1]. 
Please lets continue the discussion there.

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141394.html

- Alexey

On 3/26/2025 11:29 AM, Victor D'yakov wrote:
>
>
> Alexey, could you reply on core-libs list?
>
> Victor
> -------- Forwarded Message --------
> Subject: 	Re: jpackage and Wix 5
> Date: 	Wed, 26 Mar 2025 14:47:16 +0100
> From: 	Davide Perini <perini.davide at dpsoftware.org>
> To: 	client-libs-dev at openjdk.org
>
>
>
> If I use Wix 3 it works correctly,
> are we sure that jpackage 24 supports Wix 5?
>
> Is this a bug in the jpacakge command?
>
>
> On 2025-03-19 11:45, Davide Perini wrote:
>
>>
>>
>> Il?19/03/2025?11:19,?Davide?Perini?ha?scritto:
>>> I?add?some?context:
>>>
>>> I?installed?wix?5?using?the?donet?command?globally,
>>> wix is in the path but when I try to run my jpackage command I get 
>>> this error:
>>>
>>> jpackage -i ./target --type exe --main-class 
>>> org.dpsoftware.JavaFXStarter --main-jar 
>>> FireflyLuciferin-jar-with-dependencies.jar --icon 
>>> ./data/img/luciferin_logo.ico
>>> ?--win-menu --win-menu-group Ambilight --copyright "Davide Perini" 
>>> --name "Firefly Luciferin"? --vendor DPsoftware --win-dir-chooser 
>>> --win-shortcut --win-per-user-install --win-shortcut 
>>> --win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
>>>
>>>
>>> java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, 
>>> none, -intermediatefolder, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj, 
>>> -ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
>>> .wixext, -b, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
>>> -loc, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl, 
>>> -loc, C:\Users\SBLANT~1\AppData\
>>> Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl, 
>>> -loc, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl, 
>>> -loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
>>> dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl, 
>>> -culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d, 
>>> JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d, 
>>> JpProductCode=e0be8901-8911-3da4
>>> -83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d, 
>>> JpAllowDowngrades=yes, -d, 
>>> JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
>>> Luciferin\Firefly Luciferin.exe, -d, JpAp
>>> pSizeKb=409283, -d, JpAppVersion=1.0, -d, 
>>> JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d, 
>>> JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d, 
>>> JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
>>> T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx 
>>> f, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
>>> age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out, 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi] 
>>> in 
>>> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
>>> Luciferin exited with 144 code
>>>
>>>
>>> Il?19/03/2025?10:12,?Davide?Perini?ha?scritto:
>>>>
>>>> Hi?there,
>>>>
>>>> I'm?using?jpackage?along?with?Wix3.
>>>>
>>>> The?command?I?use?to?generate?my?.exe?is:
>>>> ? ? ? ? ? jpackage -i ../../target --type exe --main-class 
>>>> org.dpsoftware.JavaFXStarter --main-jar 
>>>> FireflyLuciferin-jar-with-dependencies.jar --icon 
>>>> ../../data/img/java_fast_screen_capture_logo.ico --win-menu 
>>>> --win-menu-group Luciferin --copyright "Davide Perini" --name 
>>>> "Firefly Luciferin" ?--vendor DPsoftware --win-dir-chooser 
>>>> --win-shortcut --win-per-user-install --win-upgrade-uuid myuuid 
>>>> --app-version "${{steps.get-id.outputs.id}}" --win-shortcut 
>>>> --win-shortcut-prompt --java-options "-XX:+UseZGC 
>>>> -XX:+UseStringDeduplication -Xms64m -Xmx1024m 
>>>> --add-modules=jdk.incubator.vector"
>>>>
>>>> How?can?I?move?it?to?Wix5?using?Java?24?
>>>>
>>>> Is there a guide/documentation that help in migrating from Wix 3 to 
>>>> Wix 5?
>>>>
>>>> Thanks
>>>> Davide
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250326/c559dca1/attachment-0001.htm>

From sakyosang at gmail.com  Fri Mar 21 06:47:45 2025
From: sakyosang at gmail.com (last last)
Date: Fri, 21 Mar 2025 14:47:45 +0800
Subject: Inquiry about PrintDialog Properties button behavior on Linux
 (JDK-8246742)
Message-ID: <CAMBge5PjRLPOd=ixAZ8Duy5myWHoNaoYzUzPv7ANdQyr-qZ08g@mail.gmail.com>

*Dear OpenJDK Community,*

I'm writing regarding an observation about the PrintDialog's Properties
button behavior on Linux platforms. On my Ubuntu 20.04 system (OpenJDK
version: 17), I noticed that the Properties button in the print dialog
remains disabled.

Through previous research, I found this is documented in JDK-8246742
("Disable Properties button in PrintDialog for Unixes and Mac"). The ticket
suggests this behavior was intentionally implemented.

But from a user perspective, this disabled state raises some concerns:

   1. 1.Users familiar with Windows implementation may find this
   inconsistent
   2. 2.Prevents access to printer-specific options that might otherwise be
   configurable
   3. 3.Could be confusing for applications relying on this functionality

Reproducer:
import java.awt.*;
import java.awt.print.*;

public class PrintDialogExample implements Printable {

    public static void main(String[] args) {
        // ?? PrinterJob ??
        PrinterJob printerJob = PrinterJob.getPrinterJob();

        // ??????
        printerJob.setPrintable(new PrintDialogExample());

        // ???????
        if (printerJob.printDialog()) {
            try {
                // ??????
                printerJob.print();
                System.out.println("Printing complete.");
            } catch (PrinterException e) {
                e.printStackTrace();
            }
        } else {
            System.out.println("Printing cancelled.");
        }
    }

    @Override
    public int print(Graphics graphics, PageFormat pageFormat, int
pageIndex) throws PrinterException {
        // ??????
        if (pageIndex > 0) {
            return Printable.NO_SUCH_PAGE;
        }

        // ? Graphics ????? Graphics2D
        Graphics2D g2d = (Graphics2D) graphics;

        // ???????
        g2d.setFont(new Font("Serif", Font.PLAIN, 12));
        g2d.setColor(Color.BLACK);

        // ????
        String text = "Hello, this is a test print job!";
        g2d.drawString(text, 100, 100);

        // ??????
        return Printable.PAGE_EXISTS;
    }
}


I'd like to inquire:

   1. 1.Is this considered an accepted platform behavior difference?
   2. 2.Are there any plans to implement native printer property support
   for Linux/MacOS?
   3. 3.Would there be value in creating a feature request for this
   capability?

Additional environment details:

   - Desktop Environment: GNOME [3.34.3-0ubuntu1 ]
   - Default Print System: CUPS [2.3.1-9ubuntu1.4]

Thank you for your insights. I'm happy to provide further testing support
if needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250321/788a09f5/attachment.htm>

From honkar at openjdk.org  Thu Mar 27 00:56:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 27 Mar 2025 00:56:51 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v20]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <gC_NCLYfBNUE5Ze9gTnh57pNOo125p-r1PcCH6-fSLA=.dfebf72e-8750-40de-9115-f7c1e0fca651@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  serialization test case changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/7da4c5c7..c32ed9b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=18-19

  Stats: 49 lines in 1 file changed: 20 ins; 22 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

PR: https://git.openjdk.org/jdk/pull/23606

From honkar at openjdk.org  Thu Mar 27 01:01:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 27 Mar 2025 01:01:37 GMT
Subject: RFR: 8352624: Add missing {@code} to
 PassFailJFrame.Builder.splitUI
In-Reply-To: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
References: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
Message-ID: <vR0Quzjd2pz7BYCxskKswXtjXLI-GC9QspFsd4nMNYY=.062e9ac0-94a7-4a7f-b178-2513a1d0a7d3@github.com>

On Tue, 25 Mar 2025 17:32:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial fix to add `{@code}` to the description of `splitUI` methods in `PassFailJFrame.Builder`.

Marked as reviewed by honkar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24235#pullrequestreview-2718946101

From serb at openjdk.org  Thu Mar 27 02:29:17 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Mar 2025 02:29:17 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <vUEEAvsOkyHahPZW1EBX5Pg7qD2wh2kH16RNEIIKYC4=.049a54ce-5777-437d-b987-e7a09c2f0421@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
 <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
 <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>
 <1NkNNs9RxXcHMphPbjjO94h1o_ZlN_aII_o_0vN1HvA=.c50df7ab-836e-4077-92ca-47e0207b4913@github.com>
 <vUEEAvsOkyHahPZW1EBX5Pg7qD2wh2kH16R
 NEIIKYC4=.049a54ce-5777-437d-b987-e7a09c2f0421@github.com>
Message-ID: <K34nrm1l3mE5s1s4o7WDt_DIlleS2yteQPrp1FG8TDk=.ac18d559-850d-49ea-9052-45b8b23b8b13@github.com>

On Wed, 26 Mar 2025 20:00:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Also, in the code above, it is not necessary to filter out private methods since iface.getMethods() returns only public
>
> The last question I have is about the module system when the interface is not exported.

I have tried to check various cases using the script below:

#!/bin/bash

rm -rf app/ bean/ classes/ bean.jar app.jar
mkdir -p bean/closed bean/exported app/app

cat <<EOF > bean/module-info.java
module bean {
    exports bean.exported;
}
EOF

########################
# non-exported classes
########################
cat <<EOF > bean/closed/ClosedI.java
package bean.closed;

public interface ClosedI {
    default int getBoo() { return 0; }
    default void setBoo(int a) { }
}
EOF

cat <<EOF > bean/closed/ClosedP.java
package bean.closed;

public class ClosedP {
    public int getToo() { return 0; }
    public void setToo(int a) { }
}
EOF

cat <<EOF > bean/closed/ClosedNonPublic.java
package bean.closed;

class ClosedNonPublic {
    public int getNoo() { return 0; }
    public void setNoo(int a) { }
}
EOF

########################
# exported classes
########################
cat <<EOF > bean/exported/OpenClass.java
package bean.exported;

import bean.closed.ClosedI;

public class OpenClass implements OpenI, ClosedI {
}
EOF

cat <<EOF > bean/exported/ClassCP.java
package bean.exported;

import bean.closed.ClosedP;

public class ClassCP extends ClosedP {
}
EOF

cat <<EOF > bean/exported/OpenP.java
package bean.exported;

public class OpenP {
    public int getZoo() { return 0; }
    public void setZoo(int a) { }
}
EOF

cat <<EOF > bean/exported/ClassOP.java
package bean.exported;

import bean.exported.OpenP;

public class ClassOP extends OpenP {
}
EOF

cat <<EOF > bean/exported/OpenI.java
package bean.exported;

public interface OpenI {
    default int getFoo() { return 0; }
    default void setFoo(int a) { }
}
EOF

########################
# main app
########################
cat <<EOF > app/module-info.java
module app {
    requires bean;
    requires java.desktop;
    exports app;
}
EOF


cat <<EOF > app/app/TestBean.java
package app;

import bean.exported.ClassCP;
import bean.exported.ClassOP;
import bean.exported.OpenClass;

import java.beans.*;
import java.io.IOException;
import java.lang.reflect.Method;
import java.util.Arrays;

public final class TestBean {
    public static void main(String[] args) throws Exception {
        System.out.println("\n*** Check exported class implementing two interfaces: exported and closed ***");
        test(OpenClass.class);
        
        System.out.println("\n*** Check exported class extended from an exported class ***");
        test(ClassOP.class);
        
        System.out.println("\n*** Check exported class extended from a closed class ***");
        test(ClassCP.class);

        System.out.println("\n*** Check exported class via reflection ***");
        test(Class.forName("bean.exported.OpenP"));

        System.out.println("\n*** Check closed class via reflection ***");
        test(Class.forName("bean.closed.ClosedP"));

        System.out.println("\n*** Check closed non-public class via reflection ***");
        test(Class.forName("bean.closed.ClosedNonPublic"));
        
        
        System.out.println("\n*** Check exported bean implementing two interfaces: exported and closed ***");
        testBean(new OpenClass());

        System.out.println("\n*** Check exported bean extended from an exported class ***");
        testBean(new ClassOP());

        System.out.println("\n*** Check exported bean extended from a closed class ***");
        testBean(new ClassCP());

        System.out.println("\n*** Check exported bean via JavaBeans instantiation ***");
        testBean(createBean("bean.exported.OpenP"));

        System.out.println("\n*** Check closed bean via JavaBeans instantiation ***");
        testBean(createBean("bean.closed.ClosedP"));

        System.out.println("\n*** Check closed non-public bean via JavaBeans instantiation ***");
        testBean(createBean("bean.closed.ClosedNonPublic"));        


        System.out.println("\n*** Check exported class via reflection ***");
        testBean(Class.forName("bean.exported.OpenP").getDeclaredConstructor().newInstance());

        //System.out.println("\n*** Check closed class via reflection ***");
        //testBean(Class.forName("bean.closed.ClosedP").getDeclaredConstructor().newInstance());

        //System.out.println("\n*** Check closed non-public class via reflection ***");
        //testBean(Class.forName("bean.closed.ClosedNonPublic").getDeclaredConstructor().newInstance());
    }

    private static void test(Class<?> beanClass) throws Exception {
        var info = java.beans.Introspector.getBeanInfo(beanClass, Object.class);
        System.out.println(info.getBeanDescriptor());
        System.out.println("--- properties")
        for (var desc : info.getPropertyDescriptors()) {
            System.out.println(desc.getName());
            System.out.println("\tRead: " + desc.getReadMethod());    
            System.out.println("\tWrite: " + desc.getWriteMethod());
        }
    }
    
    private static void testBean(Object bean) throws Exception {
        if (bean == null) {
            return;
        }
        Class<?> beanClass = bean.getClass();
        var info = java.beans.Introspector.getBeanInfo(beanClass, Object.class);    
        System.out.println(info.getBeanDescriptor());
        System.out.println("--- properties");
        for (var desc : info.getPropertyDescriptors()) {
            System.out.println(desc.getName());
            Method readMethod = desc.getReadMethod();            
            System.out.println("\tRead: " + readMethod);    
            System.out.println("\tWrite: " + desc.getWriteMethod());
            try {
                Object value = readMethod.invoke(bean);
                System.out.println("\tRead: " + readMethod.getName() + " -> " + value);
            } catch (Exception e) {
                System.out.println("\tRead: " + readMethod.getName() + " -> ERROR: " + e);
            }
        }
    }    
    
    private static Object createBean(String className) {
        try {
            return Beans.instantiate(ClassLoader.getSystemClassLoader(), className);
        } catch (IOException | ClassNotFoundException e) {
            System.out.println("ERROR: Failed to instantiate bean: " + className);
            return null;
        }
    }
}
EOF

javac -d classes bean/module-info.java bean/closed/*.java bean/exported/*.java
jar --create --file bean.jar -C classes .
rm -rf classes

javac -d classes --module-path bean.jar app/module-info.java app/app/TestBean.java
jar --create --file app.jar -C classes .
rm -rf classes

if [[ "$OSTYPE" == "cygwin" ]]; then
    SEP=";"
else
    SEP=":"
fi

echo "Start..."
java --module-path "bean.jar${SEP}app.jar" --module app/app.TestBean


The new implementation of default methods in JavaBeans for non-exported interfaces behaves similarly to that for non-exported classes:
For example, in the script above, we create an `OpenClass` that implements both exported and non-exported interfaces. The Introspector reports properties for "both interfaces", but if we attempt to use the property from the non-exported interface, we will get an exception.
This is similar to the situation where we have a non-exported parent class for an exported class: `ClassCP`: the Introspector will report the property for the parent class, but it will not be possible to use it due to an exception at runtime.

@AlanBateman I found that you worked on updating JavaBeans for modules, see [this commit](https://hg.openjdk.org/jigsaw/jake/jdk/rev/e8703be87031). Do you remember if the work was completed and if the current behavior described above in this message is correct? I'm curious because that commit aimed to skip introspecting non-exported classes/fields/methods, [link ](https://github.com/openjdk/jdk/blob/24833403b6b93ca464720f00de0e8bd5e1c140be/src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java#L136)to the current code.

@aivanov-jdk please take a look, probably I am missing something?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2015416746

From serb at openjdk.org  Thu Mar 27 04:25:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Mar 2025 04:25:13 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
Message-ID: <4IP4m6SoknlIgkVTmVXl0JtfcMqEEC9ie4MuNrCLvHQ=.b637cc92-85f7-4a63-9e29-c43b5f6d57b7@github.com>

On Wed, 26 Mar 2025 21:14:24 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely remove FileFontStrike.initNative()

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24230#pullrequestreview-2719554405

From rmarchenko at openjdk.org  Thu Mar 27 06:47:17 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Mar 2025 06:47:17 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v10]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <m9UFVJnwlPWCiKXlQOMEUDCAVn4ToBEq1Z8mVQ4LWGQ=.9a77cb9b-873b-4090-a626-aa46f7a1aacc@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
> * Gettters/setters declared and not implemented are not considered.

Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'master' into jdk-8347826
 - Fixing review comments
 - Fixing review comments 2
 - Symmetric fix
 - minor fix
 - minor fix
 - removed unnecessary lines
 - copyright year
 - Fixing review comments
 - new fixes
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0320f61b...4f29444a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/ec01898a..4f29444a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=08-09

  Stats: 174278 lines in 4318 files changed: 74951 ins; 74053 del; 25274 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From psadhukhan at openjdk.org  Thu Mar 27 08:02:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Mar 2025 08:02:47 GMT
Subject: RFR: 8352678: Opensource few JMenuItem tests
Message-ID: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>

Few JMenuItem tests are opensourced

-------------

Commit messages:
 - 8352678: Opensource few JMenuItem tests

Changes: https://git.openjdk.org/jdk/pull/24273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352678
  Stats: 336 lines in 4 files changed: 336 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24273/head:pull/24273

PR: https://git.openjdk.org/jdk/pull/24273

From rmarchenko at openjdk.org  Thu Mar 27 08:14:12 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Mar 2025 08:14:12 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <K34nrm1l3mE5s1s4o7WDt_DIlleS2yteQPrp1FG8TDk=.ac18d559-850d-49ea-9052-45b8b23b8b13@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <CMNHHDRn5IaguE4kGXT5EP7jnGJacTtYjHwafdN2MGs=.96379aa7-ca61-40f1-9b75-a2e2e24c15e7@github.com>
 <RN4eSKOsw7NhK7_QixvAXWdaK0EEEfQI74LynWDrcHs=.561aea6e-5543-499c-ac08-3110f80a460e@github.com>
 <H3hx1xv2zimFTQTGWpgVjG8IVn4NIMzbdEMM18cZAk4=.8a7e94b4-992b-4cab-a911-0f96cff10931@github.com>
 <VVYQH0QeIsnRiKGbBroU0wj3NuNkYMlt8Bd9V64iWho=.cff53149-2e75-480c-af5a-83ddf586b697@github.com>
 <tU9YfMnKUt2BlpRKh7HjDmjr6da5Ej230LPKsg8ywR4=.1125ea7d-ca89-46eb-9860-1eb396eeb88f@github.com>
 <B3dI5P2CRMjyf7AeRD8Oa_LbAj-BHLAlJP4fR9udZ1M=.ffafd364-d378-4af3-a7ca-174ab4ef9bb9@github.com>
 <BRfX4bTWt6CD_MDeOPUpSAqwyNZYIAC5ydLN_gxn1kw=.ecf92169-5247-4527-a341-c70ed0b827b1@github.com>
 <1NkNNs9RxXcHMphPbjjO94h1o_ZlN_aII_o_0vN1HvA=.c50df7ab-836e-4077-92ca-47e0207b4913@github.com>
 <vUEEAvsOkyHahPZW1EBX5Pg7qD2wh2kH16R
 NEIIKYC4=.049a54ce-5777-437d-b987-e7a09c2f0421@github.com>
 <K34nrm1l3mE5s1s4o7WDt_DIlleS2yteQPrp1FG8TDk=.ac18d559-850d-49ea-9052-45b8b23b8b13@github.com>
Message-ID: <MIychIAfbK4Q-W69hqnk_tY0aOcm2Is3fF3LgdOWxsY=.78580484-b897-427d-bba6-96fe0d7da5f0@github.com>

On Thu, 27 Mar 2025 02:26:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The last question I have is about the module system when the interface is not exported.
>
> I have tried to check various cases using the script below:
> 
> #!/bin/bash
> 
> rm -rf app/ bean/ classes/ bean.jar app.jar
> mkdir -p bean/closed bean/exported app/app
> 
> cat <<EOF > bean/module-info.java
> module bean {
>     exports bean.exported;
> }
> EOF
> 
> ########################
> # non-exported classes
> ########################
> cat <<EOF > bean/closed/ClosedI.java
> package bean.closed;
> 
> public interface ClosedI {
>     default int getBoo() { return 0; }
>     default void setBoo(int a) { }
> }
> EOF
> 
> cat <<EOF > bean/closed/ClosedP.java
> package bean.closed;
> 
> public class ClosedP {
>     public int getToo() { return 0; }
>     public void setToo(int a) { }
> }
> EOF
> 
> cat <<EOF > bean/closed/ClosedNonPublic.java
> package bean.closed;
> 
> class ClosedNonPublic {
>     public int getNoo() { return 0; }
>     public void setNoo(int a) { }
> }
> EOF
> 
> ########################
> # exported classes
> ########################
> cat <<EOF > bean/exported/OpenClass.java
> package bean.exported;
> 
> import bean.closed.ClosedI;
> 
> public class OpenClass implements OpenI, ClosedI {
> }
> EOF
> 
> cat <<EOF > bean/exported/ClassCP.java
> package bean.exported;
> 
> import bean.closed.ClosedP;
> 
> public class ClassCP extends ClosedP {
> }
> EOF
> 
> cat <<EOF > bean/exported/OpenP.java
> package bean.exported;
> 
> public class OpenP {
>     public int getZoo() { return 0; }
>     public void setZoo(int a) { }
> }
> EOF
> 
> cat <<EOF > bean/exported/ClassOP.java
> package bean.exported;
> 
> import bean.exported.OpenP;
> 
> public class ClassOP extends OpenP {
> }
> EOF
> 
> cat <<EOF > bean/exported/OpenI.java
> package bean.exported;
> 
> public interface OpenI {
>     default int getFoo() { return 0; }
>     default void setFoo(int a) { }
> }
> EOF
> 
> ########################
> # main app
> ########################
> cat <<EOF > app/module-info.java
> module app {
>     requires bean;
>     requires java.desktop;
>     exports app;
> }
> EOF
> 
> 
> cat <<EOF > app/app/TestBean.java
> package app;
> 
> import bean.exported.ClassCP;
> import bean.exported.ClassOP;
> import bean.exported.OpenClass;
> 
> import java.beans.*;
> import java.io.IOException;
> import java.lang.reflect.Method;
> import java.util.Arrays;
> 
> public final class TestBean {
>     public static void main(String[] args) throws Exception {
>         System.out.println("\n*** Check exported class implementing two interfaces: exported and closed ***");
>         test(OpenClass.class);
>         
>         System.out.println("\n*** Check exported class extended from an exported class ***");
>         test(ClassOP.class);
>         
>         System.out.println("\n*** Check exported class exten...

@mrserb 

> getMethodDescriptors() returns all methods of the class, **including static ones**, but static methods are not considered properties

I'd like to clarify the behavior:

- Should `getMethodDescriptors()` return static methods defined in the interfaces the class extends?
- If yes, should it recursively find static methods defined in interfaces? For example, the test scenario 1 defines `static int getStaticValue()` in `A1` interface hidden in the inheritance chain. Should it be included to the method descriptor list?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2015889794

From abhiscxk at openjdk.org  Thu Mar 27 09:17:09 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Mar 2025 09:17:09 GMT
Subject: RFR: 8352678: Opensource few JMenuItem tests
In-Reply-To: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
References: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
Message-ID: <zFgwArlTjaRHtL91oRNywBZPJQRJWwHKwpu3NAJt4WU=.d4cf3892-c1f5-43c1-8296-4f5a97fcaccb@github.com>

On Thu, 27 Mar 2025 07:57:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenuItem tests are opensourced

test/jdk/javax/swing/JMenuItem/bug4207339.java line 28:

> 26:  * @bug 4207339
> 27:  * @summary Verifies HTML label support for MenuItems
> 28:  * @library /open/test/jdk/java/awt/regtesthelpers

Suggestion:

 * @library /java/awt/regtesthelpers

test/jdk/javax/swing/JMenuItem/bug4402082.java line 29:

> 27:  * @requires (os.family == "windows")
> 28:  * @summary Tests that JMenuItem accelerator is rendered correctly.
> 29:  * @library /open/test/jdk/java/awt/regtesthelpers

Suggestion:

 * @library /java/awt/regtesthelpers

test/jdk/javax/swing/JMenuItem/bug6197830.java line 29:

> 27:  * @requires (os.family == "linux")
> 28:  * @summary Fix for 4729669 does not work on Motif and GTK look and feels
> 29:  * @library /open/test/jdk/java/awt/regtesthelpers

Suggestion:

 * @library /java/awt/regtesthelpers

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24273#discussion_r2016028456
PR Review Comment: https://git.openjdk.org/jdk/pull/24273#discussion_r2016029168
PR Review Comment: https://git.openjdk.org/jdk/pull/24273#discussion_r2016029543

From psadhukhan at openjdk.org  Thu Mar 27 09:34:36 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Mar 2025 09:34:36 GMT
Subject: RFR: 8352678: Opensource few JMenuItem tests [v2]
In-Reply-To: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
References: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
Message-ID: <h05NOcRbPdgsgwus56FVIDbVyTscoMmvrhYp6Oqd2f0=.7eb0301b-3e23-425e-991a-b166632453ff@github.com>

> Few JMenuItem tests are opensourced

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Rectify lib path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24273/files
  - new: https://git.openjdk.org/jdk/pull/24273/files/030b8d61..38d82dc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24273&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24273&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24273/head:pull/24273

PR: https://git.openjdk.org/jdk/pull/24273

From psadhukhan at openjdk.org  Thu Mar 27 09:34:36 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Mar 2025 09:34:36 GMT
Subject: RFR: 8352678: Opensource few JMenuItem tests [v2]
In-Reply-To: <zFgwArlTjaRHtL91oRNywBZPJQRJWwHKwpu3NAJt4WU=.d4cf3892-c1f5-43c1-8296-4f5a97fcaccb@github.com>
References: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
 <zFgwArlTjaRHtL91oRNywBZPJQRJWwHKwpu3NAJt4WU=.d4cf3892-c1f5-43c1-8296-4f5a97fcaccb@github.com>
Message-ID: <kKHCxMDh0mkeA1TOOk3ltBzs4L3z83i5gY7ZEA9SriE=.1c3f4ddf-b4be-438b-ae5b-3324b77498a3@github.com>

On Thu, 27 Mar 2025 09:14:42 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rectify lib path
>
> test/jdk/javax/swing/JMenuItem/bug6197830.java line 29:
> 
>> 27:  * @requires (os.family == "linux")
>> 28:  * @summary Fix for 4729669 does not work on Motif and GTK look and feels
>> 29:  * @library /open/test/jdk/java/awt/regtesthelpers
> 
> Suggestion:
> 
>  * @library /java/awt/regtesthelpers

Good catch..Thanks..Updated..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24273#discussion_r2016061277

From abhiscxk at openjdk.org  Thu Mar 27 09:47:09 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Mar 2025 09:47:09 GMT
Subject: RFR: 8352678: Opensource few JMenuItem tests [v2]
In-Reply-To: <h05NOcRbPdgsgwus56FVIDbVyTscoMmvrhYp6Oqd2f0=.7eb0301b-3e23-425e-991a-b166632453ff@github.com>
References: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
 <h05NOcRbPdgsgwus56FVIDbVyTscoMmvrhYp6Oqd2f0=.7eb0301b-3e23-425e-991a-b166632453ff@github.com>
Message-ID: <6ELsKzLTJGRqPFyu4rI4QV9VgHlt7-WIk5KOvl4PdNc=.20d8355a-a7d0-4407-81d5-780496b61616@github.com>

On Thu, 27 Mar 2025 09:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few JMenuItem tests are opensourced
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify lib path

LGTM.

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24273#pullrequestreview-2720550799

From psadhukhan at openjdk.org  Thu Mar 27 10:14:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Mar 2025 10:14:17 GMT
Subject: Integrated: 8352678: Opensource few JMenuItem tests
In-Reply-To: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
References: <uGcAkRlL0NlgjHx8t56VZyfrrm_6hF88sLFN0v2rGLU=.35a73d64-cfdf-4942-b8f6-9597397c514d@github.com>
Message-ID: <WXRLl1p6zjtX5_omX9JYJ8HhJT0PVhN_YszkbAOV5WU=.e2c40f15-0729-4988-bd35-d94984635953@github.com>

On Thu, 27 Mar 2025 07:57:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenuItem tests are opensourced

This pull request has now been integrated.

Changeset: 8a40498d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a40498d79a18dcf91cf4979d34c3583a6c39322
Stats:     336 lines in 4 files changed: 336 ins; 0 del; 0 mod

8352678: Opensource few JMenuItem tests

Reviewed-by: abhiscxk

-------------

PR: https://git.openjdk.org/jdk/pull/24273

From psadhukhan at openjdk.org  Thu Mar 27 10:35:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Mar 2025 10:35:08 GMT
Subject: RFR: 8352677: Opensource JMenu tests - series2
Message-ID: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>

Few JMenu tests are opensourced..

-------------

Commit messages:
 - 8352677: Opensource JMenu tests - series2

Changes: https://git.openjdk.org/jdk/pull/24275/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352677
  Stats: 356 lines in 3 files changed: 356 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24275/head:pull/24275

PR: https://git.openjdk.org/jdk/pull/24275

From aivanov at openjdk.org  Thu Mar 27 12:08:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 27 Mar 2025 12:08:17 GMT
Subject: Integrated: 8352624: Add missing {@code} to
 PassFailJFrame.Builder.splitUI
In-Reply-To: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
References: <jZo5rIJpbZA_pkY7V3g7InwDOiWY4lMZ7NRCV3vffqQ=.06835d40-5b0e-44fe-9fdd-8006da65f220@github.com>
Message-ID: <7TrqaQuDe48Zy_CMzwqt8TRkZ-CAwDEci005qVotqzM=.14ba93f9-59f9-4ed8-91c3-cc4952dab014@github.com>

On Tue, 25 Mar 2025 17:32:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial fix to add `{@code}` to the description of `splitUI` methods in `PassFailJFrame.Builder`.

This pull request has now been integrated.

Changeset: 41f3eea9
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41f3eea9b2b7bd74d5f125dedfe107ab5b0bed26
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8352624: Add missing {@code} to PassFailJFrame.Builder.splitUI

Reviewed-by: serb, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/24235

From kizune at openjdk.org  Thu Mar 27 16:34:25 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 27 Mar 2025 16:34:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <mmvy3DlEBDbTN_9q07F6TFe-37dWJ1uRR1vaNF1ApFM=.d67715f6-f01b-4b0f-89b1-6997d6d51e33@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
 <uWnbccxSKvTTUiFcasqScBoFOeYI1gBlFehnUtqPYxQ=.6501f91c-b4bd-4418-a03a-e24a622fbd0a@github.com>
 <e56sFV62ClXBTLzfdUdhbYQTO2BNJ4Z5k6aq996pVBY=.7e19221a-6fc8-4765-91f1-8553f034e531@github.com>
 <mmvy3DlEBDbTN_9q07F6TFe-37dWJ1uRR1vaNF1ApFM=.d67715f6-f01b-4b0f-89b1-6997d6d51e33@github.com>
Message-ID: <UWvMjxirB-relNShNE6g4KtgDiOhmz_QZRopjrH5ksY=.52747b05-96f4-4f68-a70a-8e49292e0b7b@github.com>

On Tue, 25 Mar 2025 03:15:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> OK. Thanks...Can you please paste that screenshot also as reference?

Sure, here it is (By the way the Windows 10 version i am using is latest available update of Windows 10 Professional): 
![menu_default](https://github.com/user-attachments/assets/20d2d782-cf9c-4710-a79c-b732ca12cc4f)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2758669164

From prr at openjdk.org  Thu Mar 27 17:51:18 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Mar 2025 17:51:18 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
Message-ID: <zLeRm4iqAJGn3SmeMfFIkCR6E89yXQVf7KnF-Rbm3iw=.5805e16e-3412-41bb-9cc7-fa8852c2d95d@github.com>

On Wed, 26 Mar 2025 19:49:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'Test' suffix to test class name, remove unused import

testing looks good

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24256#pullrequestreview-2722894766

From dgredler at openjdk.org  Thu Mar 27 18:18:16 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 27 Mar 2025 18:18:16 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
Message-ID: <pw8DUeoY_6xzxYVjkr-slf3zEsRTA9gHLM0v_7QKmtI=.612aa20a-502f-451c-990c-b1ee7c75abc2@github.com>

On Wed, 26 Mar 2025 19:49:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'Test' suffix to test class name, remove unused import

@prr Just to verify, was the testing for this one or for #24230?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24256#issuecomment-2759019262

From prr at openjdk.org  Thu Mar 27 18:45:24 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Mar 2025 18:45:24 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <pw8DUeoY_6xzxYVjkr-slf3zEsRTA9gHLM0v_7QKmtI=.612aa20a-502f-451c-990c-b1ee7c75abc2@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
 <pw8DUeoY_6xzxYVjkr-slf3zEsRTA9gHLM0v_7QKmtI=.612aa20a-502f-451c-990c-b1ee7c75abc2@github.com>
Message-ID: <rnfc4iBqlDRx5TW_tmNVG5yrBql51hh71iRcdWM6FaE=.62705248-3ca2-4bb0-98d5-b81ec2d774b1@github.com>

On Thu, 27 Mar 2025 18:15:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> @prr Just to verify, was the testing for this one or for #24230?

oops wrong PR.  I'll submit a test job for this one soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24256#issuecomment-2759081643

From prr at openjdk.org  Thu Mar 27 18:45:25 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Mar 2025 18:45:25 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
Message-ID: <PMihYc9ghz_sdPu_T5EjHQqnTkd3u41ghu3MMI_Mvtg=.0f8af350-9af8-4d0d-878f-ee023aad3cf1@github.com>

On Wed, 26 Mar 2025 21:14:24 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely remove FileFontStrike.initNative()

testing passed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24230#issuecomment-2759080851

From duke at openjdk.org  Thu Mar 27 19:11:30 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Mar 2025 19:11:30 GMT
Subject: RFR: 8352890: Remove unnecessary Windows version check in
 FileFontStrike [v3]
In-Reply-To: <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
 <1tf4RQXwbqNOINYnOdvbPKVoqbvY_MT-IOsjgnHG0vE=.9b8c9d99-9f9c-47fc-aec3-708f09f96e17@github.com>
Message-ID: <s5s1KgoQcP6Ei7LaRl7cOA8kpt2qhV1qOMoCVO98XSk=.59268ed7-83b7-4cf7-a97d-99f4641d7cf8@github.com>

On Wed, 26 Mar 2025 21:14:24 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely remove FileFontStrike.initNative()

@gredler 
Your change (at version 168695958e99c00b1c66105bbed6eb92b6645e2d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24230#issuecomment-2759141543

From bpb at openjdk.org  Thu Mar 27 22:19:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Mar 2025 22:19:04 GMT
Subject: RFR: 5043343: FileImageInputStream and FileImageOutputStream do not
 properly track streamPos for RandomAccessFile
Message-ID: <KrlvjCnbmsd3jkJ7cD29XqWSLUkyhbPDdrdic1PX7Ro=.52f6142a-8294-4281-a1f5-b7e19b6e34b8@github.com>

In the respective constructors, set the value of the initial stream position to the current file position.

-------------

Commit messages:
 - 5043343: FileImageInputStream and FileImageOutputStream do not properly track streamPos for RandomAccessFile

Changes: https://git.openjdk.org/jdk/pull/24283/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24283&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5043343
  Stats: 112 lines in 3 files changed: 110 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24283/head:pull/24283

PR: https://git.openjdk.org/jdk/pull/24283

From bpb at openjdk.org  Thu Mar 27 22:19:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Mar 2025 22:19:04 GMT
Subject: RFR: 5043343: FileImageInputStream and FileImageOutputStream do
 not properly track streamPos for RandomAccessFile
In-Reply-To: <KrlvjCnbmsd3jkJ7cD29XqWSLUkyhbPDdrdic1PX7Ro=.52f6142a-8294-4281-a1f5-b7e19b6e34b8@github.com>
References: <KrlvjCnbmsd3jkJ7cD29XqWSLUkyhbPDdrdic1PX7Ro=.52f6142a-8294-4281-a1f5-b7e19b6e34b8@github.com>
Message-ID: <_kTmgzHhA6hhl1sv0l0kuyGUkXsIH2Qg7hp5hA24NKs=.fb94d079-d96b-4285-9248-f81b75d69fba@github.com>

On Thu, 27 Mar 2025 22:13:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In the respective constructors, set the value of the initial stream position to the current file position.

No new failures are observed in CI tiers 1-3. The new test fails without but passes with the proposed source changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24283#issuecomment-2759602147

From dgredler at openjdk.org  Fri Mar 28 00:37:14 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 28 Mar 2025 00:37:14 GMT
Subject: Integrated: 8352890: Remove unnecessary Windows version check in
 FileFontStrike
In-Reply-To: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
References: <oZLOWk6Jn_9uI42IMOgafx-TDG7q5g1khU4Rq4abSiA=.789ba92f-e7cf-4e2f-9098-748d76bb402a@github.com>
Message-ID: <t98cN2K-amJVVoHleKeVU8ShtC1Nwoghw-5-AONeNXQ=.55bcd7c4-bf10-4218-996e-b75ab1c2d354@github.com>

On Tue, 25 Mar 2025 14:21:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> FileFontStrike contains a check as to whether the current Windows version is Windows XP or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> When the code in question was added 17 years ago, a test was included (test/jdk/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java), so this can be used to verify that there are no regressions.

This pull request has now been integrated.

Changeset: d5b12c82
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5b12c82fe7c25ccfd70edf73b80824ad316e797
Stats:     24 lines in 2 files changed: 1 ins; 19 del; 4 mod

8352890: Remove unnecessary Windows version check in FileFontStrike

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/24230

From psadhukhan at openjdk.org  Fri Mar 28 02:35:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 02:35:12 GMT
Subject: RFR: 8352685: Opensource JInternalFrame tests - series2
Message-ID: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>

Few JInternalFrame tests are opensourced

-------------

Commit messages:
 - 8352685: Opensource JInternalFrame tests - series2

Changes: https://git.openjdk.org/jdk/pull/24285/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352685
  Stats: 378 lines in 4 files changed: 378 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24285/head:pull/24285

PR: https://git.openjdk.org/jdk/pull/24285

From serb at openjdk.org  Fri Mar 28 02:40:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Mar 2025 02:40:08 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
Message-ID: <-jRzwQxkdvPSdtGXL_B3-7NpK7DWdbTur-ppREXVtN0=.f41a6fa5-fd10-47eb-80a4-a36d56562b91@github.com>

On Wed, 26 Mar 2025 19:49:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'Test' suffix to test class name, remove unused import

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24256#pullrequestreview-2724105143

From serb at openjdk.org  Fri Mar 28 03:56:17 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Mar 2025 03:56:17 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v20]
In-Reply-To: <gC_NCLYfBNUE5Ze9gTnh57pNOo125p-r1PcCH6-fSLA=.dfebf72e-8750-40de-9115-f7c1e0fca651@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <gC_NCLYfBNUE5Ze9gTnh57pNOo125p-r1PcCH6-fSLA=.dfebf72e-8750-40de-9115-f7c1e0fca651@github.com>
Message-ID: <rb3r5q2_ZI2m8-XxJHlGPCBoFzg9WBjse3FOiW65ow4=.0e6605c1-203a-4e61-8bb5-feef342ae08b@github.com>

On Thu, 27 Mar 2025 00:56:51 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array representation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization test case changes

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2724177768

From prr at openjdk.org  Fri Mar 28 04:34:22 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Mar 2025 04:34:22 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
Message-ID: <MbVdO9NVkyiDLTtbBgqh_eLzAUeCIjN_dlztRBqm5_8=.f54c2595-9d22-431c-8d91-e06ac9b31041@github.com>

On Wed, 26 Mar 2025 19:49:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'Test' suffix to test class name, remove unused import

So testing for this PR looks good.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24256#pullrequestreview-2724226901

From rkannathpari at openjdk.org  Fri Mar 28 06:05:54 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 28 Mar 2025 06:05:54 GMT
Subject: RFR: 8353138: Screen capture for test TaskbarPositionTest.java,
 failure case
Message-ID: <JFEX_5HgGA_0wkL8MvRLwdZK4Q0heCEy8fkIouBkZCI=.2334c3ae-6fbf-452f-a41f-3b03b9528213@github.com>

Hi Reviewers,

Added screen capture in case of test failure using Robot. 

Please review and let me know your suggestion if any.

-------------

Commit messages:
 - 8353138: Screen capture for test TaskbarPositionTest.java, failure case

Changes: https://git.openjdk.org/jdk/pull/24286/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353138
  Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24286/head:pull/24286

PR: https://git.openjdk.org/jdk/pull/24286

From abhiscxk at openjdk.org  Fri Mar 28 06:08:14 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Mar 2025 06:08:14 GMT
Subject: RFR: 8352677: Opensource JMenu tests - series2
In-Reply-To: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
References: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
Message-ID: <qcDbPo9i2GTq_BjkQJd4is1wKXQqSyL9u_a9xePUipg=.97193091-f770-4346-8df6-2a65f7b479e4@github.com>

On Thu, 27 Mar 2025 10:28:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenu tests are opensourced..

test/jdk/javax/swing/JMenu/bug6513492.java line 145:

> 143:             PassFailJFrame.log("");
> 144:         } catch (Exception e) {
> 145:             e.printStackTrace();

should we throw exception than print ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24275#discussion_r2017979259

From psadhukhan at openjdk.org  Fri Mar 28 06:41:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 06:41:11 GMT
Subject: RFR: 8352677: Opensource JMenu tests - series2 [v2]
In-Reply-To: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
References: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
Message-ID: <Z9WIVsupZF9ryKWSnyfUzslWUQQUzdkIgbX1n-v8JjQ=.1b881bf3-d49c-4d07-8a57-cc109b19c430@github.com>

> Few JMenu tests are opensourced..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  throw exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24275/files
  - new: https://git.openjdk.org/jdk/pull/24275/files/277b7785..92e78af4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24275&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24275&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24275/head:pull/24275

PR: https://git.openjdk.org/jdk/pull/24275

From psadhukhan at openjdk.org  Fri Mar 28 06:41:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 06:41:13 GMT
Subject: RFR: 8352677: Opensource JMenu tests - series2 [v2]
In-Reply-To: <qcDbPo9i2GTq_BjkQJd4is1wKXQqSyL9u_a9xePUipg=.97193091-f770-4346-8df6-2a65f7b479e4@github.com>
References: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
 <qcDbPo9i2GTq_BjkQJd4is1wKXQqSyL9u_a9xePUipg=.97193091-f770-4346-8df6-2a65f7b479e4@github.com>
Message-ID: <d2rjOS7gPpk4N3H5NViqXHrffmn2JZvafI1Hw-2GfnE=.3d786985-d7e2-42e3-973b-57f0bdb8c9b2@github.com>

On Fri, 28 Mar 2025 06:03:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   throw exception
>
> test/jdk/javax/swing/JMenu/bug6513492.java line 145:
> 
>> 143:             PassFailJFrame.log("");
>> 144:         } catch (Exception e) {
>> 145:             e.printStackTrace();
> 
> should we throw exception than print ?

ok..done..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24275#discussion_r2018007361

From abhiscxk at openjdk.org  Fri Mar 28 06:46:16 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Mar 2025 06:46:16 GMT
Subject: RFR: 8352677: Opensource JMenu tests - series2 [v2]
In-Reply-To: <Z9WIVsupZF9ryKWSnyfUzslWUQQUzdkIgbX1n-v8JjQ=.1b881bf3-d49c-4d07-8a57-cc109b19c430@github.com>
References: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
 <Z9WIVsupZF9ryKWSnyfUzslWUQQUzdkIgbX1n-v8JjQ=.1b881bf3-d49c-4d07-8a57-cc109b19c430@github.com>
Message-ID: <GLlAjPcRrFud3SPFXsCT_TvVNktQlPuwG6BhgHWSZtk=.497b4f71-14e6-4254-afe1-c51d879a3348@github.com>

On Fri, 28 Mar 2025 06:41:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few JMenu tests are opensourced..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   throw exception

LGTM

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24275#pullrequestreview-2724433033

From psadhukhan at openjdk.org  Fri Mar 28 06:56:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 06:56:26 GMT
Subject: Integrated: 8352677: Opensource JMenu tests - series2
In-Reply-To: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
References: <2Wlmo6P7Ko4y7aT-i0iVPbW3vVXyz3XnpPjH8QmCYGE=.23b5389b-a7eb-43c1-b11f-1d46e47424d3@github.com>
Message-ID: <3kdd1Gt-mN0D3fxM6TfyEINKAAbMnEeMMY-jpvNILS0=.3d1e1db4-aa15-4c23-8c0f-62dddae15530@github.com>

On Thu, 27 Mar 2025 10:28:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenu tests are opensourced..

This pull request has now been integrated.

Changeset: cfc648bd
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfc648bd17cc79b1c3e6f69d3559749e937261b2
Stats:     356 lines in 3 files changed: 356 ins; 0 del; 0 mod

8352677: Opensource JMenu tests - series2

Reviewed-by: abhiscxk

-------------

PR: https://git.openjdk.org/jdk/pull/24275

From duke at openjdk.org  Fri Mar 28 07:04:19 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Mar 2025 07:04:19 GMT
Subject: RFR: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2 [v2]
In-Reply-To: <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
 <deyqCw7BKn81ITiFM1PVEspbs5uwzYy0jt0hK-STO8g=.24ccb1cf-b021-4448-b032-24eb9e018961@github.com>
Message-ID: <LqAbsT0mU1GGEnaqrhUj-Ybxk6Z6r449pUJxi77xxug=.15a3be76-c8fd-48f0-9ffa-39bf977591c2@github.com>

On Wed, 26 Mar 2025 19:49:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'Test' suffix to test class name, remove unused import

@gredler 
Your change (at version 3409da273c8b65a19998422ba4d314a996f866bc) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24256#issuecomment-2760391182

From dgredler at openjdk.org  Fri Mar 28 09:47:21 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 28 Mar 2025 09:47:21 GMT
Subject: RFR: 8353002: Remove unnecessary Windows version check in WTaskbarPeer
Message-ID: <SthZ3yxgG8kjZ8Kabq98vkHr7LmiGJTCrp1GafxoFpM=.dd2c3475-d0d2-4aa2-b226-a8bd473ee65a@github.com>

WTaskbarPeer contains a check as to whether the current Windows version is Windows 7 or later. The current minimum supported version is Windows 10, so this is no longer needed.

There didn't seem to be a public test exercising this code, so I also added a basic Taskbar sanity test.

-------------

Commit messages:
 - Remove unnecessary Windows version check in WTaskbarPeer

Changes: https://git.openjdk.org/jdk/pull/24287/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24287&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353002
  Stats: 55 lines in 2 files changed: 50 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24287/head:pull/24287

PR: https://git.openjdk.org/jdk/pull/24287

From psadhukhan at openjdk.org  Fri Mar 28 10:22:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 10:22:45 GMT
Subject: RFR: 8352680: Opensource few misc swing tests
Message-ID: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>

Few JMenuItem and JFrame tests are opensourced..

-------------

Commit messages:
 - 8352680: Opensource few misc swing tests
 - 8352680: Opensource few misc swing tests

Changes: https://git.openjdk.org/jdk/pull/24288/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24288&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352680
  Stats: 418 lines in 3 files changed: 418 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24288.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24288/head:pull/24288

PR: https://git.openjdk.org/jdk/pull/24288

From abhiscxk at openjdk.org  Fri Mar 28 10:56:09 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Mar 2025 10:56:09 GMT
Subject: RFR: 8352680: Opensource few misc swing tests
In-Reply-To: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
Message-ID: <c6ho-x6ET4ToQl9ihDGUbI11AZR5HGkVy2F3kkliUHM=.60b2acf1-fcae-449e-a7a6-862eb051da10@github.com>

On Fri, 28 Mar 2025 10:16:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenuItem and JFrame tests are opensourced..

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 31:

> 29:  *     This test checks if menu items lay out correctly when their
> 30:  *     ComponentOrientation property is set to RIGHT_TO_LEFT.
> 31:  *     This test is manual. The tester is asked to compare left-to-right and

Not required to mention manual
Suggestion:

 *     The tester is asked to compare left-to-right and

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 104:

> 102:     static JMenu createMenu(String laf, String name) {
> 103:         JMenu menu = new JMenu(name);
> 104:         try{

Suggestion:

        try {

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 111:

> 109:             addMenuItems(menu, ComponentOrientation.RIGHT_TO_LEFT);
> 110:             UIManager.setLookAndFeel(save);
> 111:         } catch(Exception e){

Suggestion:

        } catch(Exception e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018402787
PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018405942
PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018405684

From psadhukhan at openjdk.org  Fri Mar 28 11:00:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 11:00:37 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v2]
In-Reply-To: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
Message-ID: <Z-iK3IE8Pi12iPiVb1DVhdSlKVhk8jsbT2d925aR904=.a9c31e3c-c1cb-4ff0-922e-94aaf3e133a5@github.com>

> Few JMenuItem and JFrame tests are opensourced..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24288/files
  - new: https://git.openjdk.org/jdk/pull/24288/files/ccf5851a..71887a49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24288&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24288&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24288.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24288/head:pull/24288

PR: https://git.openjdk.org/jdk/pull/24288

From psadhukhan at openjdk.org  Fri Mar 28 11:00:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 11:00:37 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v2]
In-Reply-To: <c6ho-x6ET4ToQl9ihDGUbI11AZR5HGkVy2F3kkliUHM=.60b2acf1-fcae-449e-a7a6-862eb051da10@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
 <c6ho-x6ET4ToQl9ihDGUbI11AZR5HGkVy2F3kkliUHM=.60b2acf1-fcae-449e-a7a6-862eb051da10@github.com>
Message-ID: <TqxgcbUkSjX-840e5oPv-e7Mx8RgTtvnp2RLBY9ZX7M=.9c32a6ae-268f-4bb3-a7a2-bd58164ec896@github.com>

On Fri, 28 Mar 2025 10:52:04 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 104:
> 
>> 102:     static JMenu createMenu(String laf, String name) {
>> 103:         JMenu menu = new JMenu(name);
>> 104:         try{
> 
> Suggestion:
> 
>         try {

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018417207

From psadhukhan at openjdk.org  Fri Mar 28 11:06:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 11:06:05 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v3]
In-Reply-To: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
Message-ID: <5WmtrcAHhCm1HOxjA4SekQ74RqtaKhzAkJ-44YSf2tw=.e07c7b17-2d42-457a-81f6-10f028511cd8@github.com>

> Few JMenuItem and JFrame tests are opensourced..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24288/files
  - new: https://git.openjdk.org/jdk/pull/24288/files/71887a49..a2c711f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24288&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24288&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24288.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24288/head:pull/24288

PR: https://git.openjdk.org/jdk/pull/24288

From psadhukhan at openjdk.org  Fri Mar 28 11:06:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 11:06:06 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v2]
In-Reply-To: <4Dnxop3kdXTSRxyTx6cZ5CcAUgBlRpPQ1L3nURxgi5k=.481f9602-d269-45aa-9fe8-31718b06d1f8@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
 <Z-iK3IE8Pi12iPiVb1DVhdSlKVhk8jsbT2d925aR904=.a9c31e3c-c1cb-4ff0-922e-94aaf3e133a5@github.com>
 <4Dnxop3kdXTSRxyTx6cZ5CcAUgBlRpPQ1L3nURxgi5k=.481f9602-d269-45aa-9fe8-31718b06d1f8@github.com>
Message-ID: <BadmIUsdQLPyv0kD1XBRobDm2umFbN6Ovg9lMj51ijw=.bc033c48-5591-4507-95bf-063a6c65befc@github.com>

On Fri, 28 Mar 2025 11:01:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 111:
> 
>> 109:             addMenuItems(menu, ComponentOrientation.RIGHT_TO_LEFT);
>> 110:             UIManager.setLookAndFeel(save);
>> 111:         } catch(Exception e) {
> 
> Suggestion:
> 
>         } catch (Exception e) {

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018435286

From abhiscxk at openjdk.org  Fri Mar 28 11:06:06 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Mar 2025 11:06:06 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v2]
In-Reply-To: <Z-iK3IE8Pi12iPiVb1DVhdSlKVhk8jsbT2d925aR904=.a9c31e3c-c1cb-4ff0-922e-94aaf3e133a5@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
 <Z-iK3IE8Pi12iPiVb1DVhdSlKVhk8jsbT2d925aR904=.a9c31e3c-c1cb-4ff0-922e-94aaf3e133a5@github.com>
Message-ID: <4Dnxop3kdXTSRxyTx6cZ5CcAUgBlRpPQ1L3nURxgi5k=.481f9602-d269-45aa-9fe8-31718b06d1f8@github.com>

On Fri, 28 Mar 2025 11:00:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few JMenuItem and JFrame tests are opensourced..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 111:

> 109:             addMenuItems(menu, ComponentOrientation.RIGHT_TO_LEFT);
> 110:             UIManager.setLookAndFeel(save);
> 111:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24288#discussion_r2018431011

From abhiscxk at openjdk.org  Fri Mar 28 11:09:18 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Mar 2025 11:09:18 GMT
Subject: RFR: 8352680: Opensource few misc swing tests [v3]
In-Reply-To: <5WmtrcAHhCm1HOxjA4SekQ74RqtaKhzAkJ-44YSf2tw=.e07c7b17-2d42-457a-81f6-10f028511cd8@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
 <5WmtrcAHhCm1HOxjA4SekQ74RqtaKhzAkJ-44YSf2tw=.e07c7b17-2d42-457a-81f6-10f028511cd8@github.com>
Message-ID: <H_7czAWmYkzjfx_aNWSM_sE5ce-5lWMuxwlpnEbI4z8=.03230680-4442-4e7d-b72d-6079dc50a7d0@github.com>

On Fri, 28 Mar 2025 11:06:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few JMenuItem and JFrame tests are opensourced..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

LGTM. I hope you have tested on all platforms for which tests are intended to run after open sourcing.

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24288#pullrequestreview-2725160283

From mvs at openjdk.org  Fri Mar 28 11:13:57 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 28 Mar 2025 11:13:57 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and
 fails intermittently in CI
Message-ID: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>

java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
Also the frame created in this test is not disposed which may interfere with other tests.

Fix:
Some stabilisations added and the frame is disposed properly.

Testing:
Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.

-------------

Commit messages:
 - 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI

Changes: https://git.openjdk.org/jdk/pull/24292/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24292&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288471
  Stats: 50 lines in 1 file changed: 24 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24292/head:pull/24292

PR: https://git.openjdk.org/jdk/pull/24292

From psadhukhan at openjdk.org  Fri Mar 28 13:06:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 13:06:22 GMT
Subject: Integrated: 8352680: Opensource few misc swing tests
In-Reply-To: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
References: <DSgvzYevqVOUiriFfNSTlcWqFiGpaLOCwzuvKd7RpIs=.58915c76-a4f7-4ba5-8870-5246859bbf19@github.com>
Message-ID: <I5N_G_Tx_ahP3J_NB-6Xyl0LYc6xD9XS48xq6J8qPgQ=.ba14cbec-8050-4c9c-abe1-99961ded88f8@github.com>

On Fri, 28 Mar 2025 10:16:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JMenuItem and JFrame tests are opensourced..

This pull request has now been integrated.

Changeset: c0b61d3b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0b61d3b8820a38a9757a1a3e69da43014d24439
Stats:     418 lines in 3 files changed: 418 ins; 0 del; 0 mod

8352680: Opensource few misc swing tests

Reviewed-by: abhiscxk

-------------

PR: https://git.openjdk.org/jdk/pull/24288

From azvegint at openjdk.org  Fri Mar 28 13:27:09 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Mar 2025 13:27:09 GMT
Subject: RFR: 8352860: Open source events tests batch0
Message-ID: <_j29C-JVs5YYDvJrE_rtOdpvmj4mIU-oJX1KAdDNDWs=.6e630ae4-a1d6-417e-8914-96518d7a71ff@github.com>

Few events tests are opensourced

* java/awt/event/ClickEventsTest.java
* java/awt/event/WindowActivatedEventTest.java

Testing is good

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/24293/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352860
  Stats: 302 lines in 2 files changed: 302 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24293/head:pull/24293

PR: https://git.openjdk.org/jdk/pull/24293

From psadhukhan at openjdk.org  Fri Mar 28 13:26:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 13:26:46 GMT
Subject: RFR: 8352685: Opensource JInternalFrame tests - series2 [v2]
In-Reply-To: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>
References: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>
Message-ID: <_Zi4tfk-3IPoRYu6egBU3bmNmCubpOCO5mNTwBeob-k=.c84b2911-419e-4e55-8975-87444a8039b5@github.com>

> Few JInternalFrame tests are opensourced

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add PL entry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24285/files
  - new: https://git.openjdk.org/jdk/pull/24285/files/630158d8..681f108d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24285&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24285&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24285/head:pull/24285

PR: https://git.openjdk.org/jdk/pull/24285

From azvegint at openjdk.org  Fri Mar 28 13:34:20 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Mar 2025 13:34:20 GMT
Subject: RFR: 8352685: Opensource JInternalFrame tests - series2 [v2]
In-Reply-To: <_Zi4tfk-3IPoRYu6egBU3bmNmCubpOCO5mNTwBeob-k=.c84b2911-419e-4e55-8975-87444a8039b5@github.com>
References: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>
 <_Zi4tfk-3IPoRYu6egBU3bmNmCubpOCO5mNTwBeob-k=.c84b2911-419e-4e55-8975-87444a8039b5@github.com>
Message-ID: <Q3QjxvDBTrUqPhYzRPYHfnEJVKOKWSx7HgJCs5bVOMU=.4bb9bd11-c066-4193-8621-3c262bff5e7c@github.com>

On Fri, 28 Mar 2025 13:26:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few JInternalFrame tests are opensourced
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add PL entry

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24285#pullrequestreview-2725544969

From duke at openjdk.org  Fri Mar 28 15:47:15 2025
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 28 Mar 2025 15:47:15 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI
In-Reply-To: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
Message-ID: <gUPPTN8kjutuZqmV6SNmix5ul45ZUkmMKIbUtwyGClU=.ecae90b2-69e0-456f-b467-49a672d94b3c@github.com>

On Fri, 28 Mar 2025 11:09:03 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
> Also the frame created in this test is not disposed which may interfere with other tests.
> 
> Fix:
> Some stabilisations added and the frame is disposed properly.
> 
> Testing:
> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 92:

> 90:     final bug8077409Test obj = new bug8077409Test();
> 91:     try {
> 92:     obj.setLocationRelativeTo(null);

Please correct the format

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 95:

> 93:     Toolkit.getDefaultToolkit().addAWTEventListener(e -> {
> 94:       KeyEvent keyEvent = (KeyEvent) e;
> 95:       if(keyEvent.getID() == KeyEvent.KEY_RELEASED) {

There is a space after if in all the other if but not for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2018913020
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2018915057

From psadhukhan at openjdk.org  Fri Mar 28 15:53:34 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 15:53:34 GMT
Subject: Integrated: 8352685: Opensource JInternalFrame tests - series2
In-Reply-To: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>
References: <SX2d3Js6SLy62BAca6X5Em8NRDg04SgMKD1Th18TMqE=.2a124402-8c61-4eaf-a32c-36f36843c635@github.com>
Message-ID: <zkSw5ZoonNflhHiEEbJOALi9_p0Nljv2VbR0oJHmy20=.f9b01bcf-1421-4e5e-965a-4ccd585a9210@github.com>

On Fri, 28 Mar 2025 02:29:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few JInternalFrame tests are opensourced

This pull request has now been integrated.

Changeset: da3bb067
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da3bb06797f9550d204b2623481ef757ae941bbd
Stats:     379 lines in 5 files changed: 379 ins; 0 del; 0 mod

8352685: Opensource JInternalFrame tests - series2

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/24285

From psadhukhan at openjdk.org  Fri Mar 28 16:03:21 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Mar 2025 16:03:21 GMT
Subject: RFR: 8352860: Open source events tests batch0
In-Reply-To: <_j29C-JVs5YYDvJrE_rtOdpvmj4mIU-oJX1KAdDNDWs=.6e630ae4-a1d6-417e-8914-96518d7a71ff@github.com>
References: <_j29C-JVs5YYDvJrE_rtOdpvmj4mIU-oJX1KAdDNDWs=.6e630ae4-a1d6-417e-8914-96518d7a71ff@github.com>
Message-ID: <oOzcfvNTKysbst7hjU4rA1SAdY4sGsKnxqjgA396kkY=.3939cdb3-1b3c-4484-8f9a-ea92e802d39c@github.com>

On Fri, 28 Mar 2025 13:20:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Few events tests are opensourced
> 
> * java/awt/event/ClickEventsTest.java
> * java/awt/event/WindowActivatedEventTest.java
> 
> Testing is good

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24293#pullrequestreview-2726006155

From myankelevich at openjdk.org  Fri Mar 28 16:39:50 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 28 Mar 2025 16:39:50 GMT
Subject: RFR: 8353138: Screen capture for test TaskbarPositionTest.java,
 failure case
In-Reply-To: <JFEX_5HgGA_0wkL8MvRLwdZK4Q0heCEy8fkIouBkZCI=.2334c3ae-6fbf-452f-a41f-3b03b9528213@github.com>
References: <JFEX_5HgGA_0wkL8MvRLwdZK4Q0heCEy8fkIouBkZCI=.2334c3ae-6fbf-452f-a41f-3b03b9528213@github.com>
Message-ID: <VyMGinBL1BjKJ_EvKTRJr21uc9HDOQcYyr_qziAdVdk=.74a3aa45-7149-414e-83d2-296e71d645e0@github.com>

On Fri, 28 Mar 2025 06:00:51 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Added screen capture in case of test failure using Robot. 
> 
> Please review and let me know your suggestion if any.

Just a few minor questions. 

Also, it seems that the screenshot code is repeated all over the place. Wouldn't it make sense to make a utility/add it to an existing utility class for further use to standardise it and make it simpler to maintain in time? I know this is well beyond the scope of this ticket, but just thought to mention the idea ? 


        BufferedImage image = robot.createScreenCapture(bounds);
        try {
            ImageIO.write(image,"png", new File("Screenshot.png"));
        } catch (IOException e) {
...

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 78:

> 76: public class TaskbarPositionTest implements ActionListener {
> 77: 
> 78:     private static JFrame frame;

Nit: I don't think  `* @run main TaskbarPositionTest` is needed. But it's fine as it is too, don't have any strong feelings

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 78:

> 76: public class TaskbarPositionTest implements ActionListener {
> 77: 
> 78:     private static JFrame frame;

Nit: copyright year

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 81:

> 79:     private static JPopupMenu popupMenu;
> 80:     private static JPanel panel;
> 81:     private static Robot robot;

Do you think it would be better to have Robot initialisation in this way? IMO it will make the robot final, so there is no way to overwrite it in the future as well as it would be easier to debug and not be initialised in the main method of the class. 

    private static final Robot robot;

    static {
        try {
            robot = new Robot();
        } catch (AWTException e) {
            throw new RuntimeException(e);
        }
    }

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 223:

> 221:             ImageIO.write(image,"png", new File("Screenshot.png"));
> 222:         } catch (IOException e) {
> 223:             e.printStackTrace();

I'm not sure it's the best idea to hide the error and just print it into stdout. Wouldn't it be better to just throw the error, what do you think?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24286#pullrequestreview-2726076897
PR Review Comment: https://git.openjdk.org/jdk/pull/24286#discussion_r2018993990
PR Review Comment: https://git.openjdk.org/jdk/pull/24286#discussion_r2018994882
PR Review Comment: https://git.openjdk.org/jdk/pull/24286#discussion_r2018981226
PR Review Comment: https://git.openjdk.org/jdk/pull/24286#discussion_r2018984420

From dgredler at openjdk.org  Fri Mar 28 17:25:24 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 28 Mar 2025 17:25:24 GMT
Subject: Integrated: 8352970: Remove unnecessary Windows version check in
 Win32ShellFolderManager2
In-Reply-To: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
References: <_V7Bs2c1wZ8bK64o3wSLWF2rDtEhy3QBJqsw65EgY_k=.3c17075b-a14a-4a00-8767-6f47303cf55c@github.com>
Message-ID: <W0GEXp8nUt5adCPEE7D2hziYho_CGaY-UvJShzzlG0I=.4c87e851-ab61-4c32-88bd-41941d029248@github.com>

On Wed, 26 Mar 2025 14:34:54 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Win32ShellFolderManager2 contains a check as to whether the current Windows version is Windows 2000 or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> No test seems to currently exercise this code, and it's not easy to reliably test, but I've added a basic test that should surface any fundamental issues. The change is very simple, though.

This pull request has now been integrated.

Changeset: 3d2c3cd4
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d2c3cd40ebce901d09a2479c267342e04e6f79c
Stats:     60 lines in 2 files changed: 57 ins; 1 del; 2 mod

8352970: Remove unnecessary Windows version check in Win32ShellFolderManager2

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/24256

From djgredler at gmail.com  Fri Mar 28 17:38:52 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Fri, 28 Mar 2025 18:38:52 +0100
Subject: Expected behavior of Font.canDisplay* methods?
Message-ID: <CAPA+ug49nX6bP=0r5FS3oYgPHmR44akX4Bg=bT5_7fsB0bTBHw@mail.gmail.com>

Hi all,

After some of the recent fixes for default-ignorable characters [1, 2] I'm
wondering what the expected behavior for the following methods is w.r.t.
default-ignorable characters (or really any invisible glyphs):

Font.canDisplay(char)
Font.canDisplay(int)
Font.canDisplayUpTo(String)
Font.canDisplayUpTo(char[], int, int)
Font.canDisplayUpTo(CharacterIterator, int, int)

The JavaDoc for the first two methods explicitly states "checks if this
Font has a glyph for the specified character", which is clear enough, but
doesn't match the method name since in reality any font can display e.g.
U+200B (zero width space) regardless of whether it has a glyph in the font,
since U+200B will always map to the invisible glyph and will be skipped
during layout / rendering.

The JavaDoc for the last three methods is more ambiguous, seeming to focus
on whether or not the font "can display" the string. Again, characters
which map to invisible glyphs do not need glyphs in the font, so flagging
them as "can't display" seems questionable.

Basically, I'm wondering whether these five methods should be communicating
that chars which map to invisible glyphs can be displayed, regardless of
whether the font has a glyph for them.

Thoughts?

Take care,

Daniel

[1] http://www.unicode.org/L2/L2002/02368-default-ignorable.html
[2] https://github.com/openjdk/jdk/pull/22670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250328/8694ba5d/attachment.htm>

From aivanov at openjdk.org  Fri Mar 28 19:32:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Mar 2025 19:32:32 GMT
Subject: RFR: 8353002: Remove unnecessary Windows version check in
 WTaskbarPeer
In-Reply-To: <SthZ3yxgG8kjZ8Kabq98vkHr7LmiGJTCrp1GafxoFpM=.dd2c3475-d0d2-4aa2-b226-a8bd473ee65a@github.com>
References: <SthZ3yxgG8kjZ8Kabq98vkHr7LmiGJTCrp1GafxoFpM=.dd2c3475-d0d2-4aa2-b226-a8bd473ee65a@github.com>
Message-ID: <frdbqCUJAB6GfpoBmhoEBt1JXRMQwrB7VKTnxMnQokw=.2e773897-dafb-44ba-964c-f42b451717e5@github.com>

On Fri, 28 Mar 2025 09:41:22 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> WTaskbarPeer contains a check as to whether the current Windows version is Windows 7 or later. The current minimum supported version is Windows 10, so this is no longer needed.
> 
> There didn't seem to be a public test exercising this code, so I also added a basic Taskbar sanity test.

src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java line 46:

> 44:     private static synchronized void init() {
> 45:         if (!initExecuted) {
> 46:             supported = ShellFolder.invoke(() -> nativeInit());

I wonder what will happen if I start `java.exe` on a system with Windows Vista which doesn't support these features.

If the native code returns an error, then it's fine.

I ask this question not only out of curiosity but also because it looks like people run Java apps on Windows versions before Windows 10. We had to implement fallback for older versions of Windows in [JDK-8321151](https://bugs.openjdk.org/browse/JDK-8321151).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24287#discussion_r2019228983

From dgredler at openjdk.org  Fri Mar 28 20:59:17 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 28 Mar 2025 20:59:17 GMT
Subject: RFR: 8353002: Remove unnecessary Windows version check in
 WTaskbarPeer
In-Reply-To: <frdbqCUJAB6GfpoBmhoEBt1JXRMQwrB7VKTnxMnQokw=.2e773897-dafb-44ba-964c-f42b451717e5@github.com>
References: <SthZ3yxgG8kjZ8Kabq98vkHr7LmiGJTCrp1GafxoFpM=.dd2c3475-d0d2-4aa2-b226-a8bd473ee65a@github.com>
 <frdbqCUJAB6GfpoBmhoEBt1JXRMQwrB7VKTnxMnQokw=.2e773897-dafb-44ba-964c-f42b451717e5@github.com>
Message-ID: <0Exo7te9jSfTV_Sp1g5Laz0eohfQeLAN3s_s-gISDq4=.55dc9bad-be0f-49c6-ae80-e1d5d3770a16@github.com>

On Fri, 28 Mar 2025 19:28:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> WTaskbarPeer contains a check as to whether the current Windows version is Windows 7 or later. The current minimum supported version is Windows 10, so this is no longer needed.
>> 
>> There didn't seem to be a public test exercising this code, so I also added a basic Taskbar sanity test.
>
> src/java.desktop/windows/classes/sun/awt/windows/WTaskbarPeer.java line 46:
> 
>> 44:     private static synchronized void init() {
>> 45:         if (!initExecuted) {
>> 46:             supported = ShellFolder.invoke(() -> nativeInit());
> 
> I wonder what will happen if I start `java.exe` on a system with Windows Vista which doesn't support these features.
> 
> If the native code returns an error, then it's fine.
> 
> I ask this question not only out of curiosity but also because it looks like people run Java apps on Windows versions before Windows 10. We had to implement fallback for older versions of Windows in [JDK-8321151](https://bugs.openjdk.org/browse/JDK-8321151).

Interesting, thanks for the link!

One issue I see with [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) is that it didn't work all the way back to the original Windows 10 release, which conflicts with the [Oracle compatibility matrix](https://www.oracle.com/java/technologies/javase-subscription/documentation.html#sysconfig).

But besides that, I'm surprised that a fix was implemented and tested targeting Windows 7 compatibility. Is there a different OpenJDK compatibility matrix that I should be aware of? If not, what were the criteria dictating that Windows 7 compatibility be maintained (at least in 2023)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24287#discussion_r2019367351

From azvegint at openjdk.org  Fri Mar 28 21:28:35 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Mar 2025 21:28:35 GMT
Subject: RFR: 8353126: Open source events tests batch1
Message-ID: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>

Few more events tests are opensourced:

* test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
* test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/24303/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353126
  Stats: 321 lines in 2 files changed: 321 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24303/head:pull/24303

PR: https://git.openjdk.org/jdk/pull/24303

From honkar at openjdk.org  Fri Mar 28 21:41:21 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Mar 2025 21:41:21 GMT
Subject: RFR: 8353126: Open source events tests batch1
In-Reply-To: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
Message-ID: <K0ka7WW_B6DJob7RSCROQHttDFEFt9Jp9_E1wjlNYZ4=.f0b2bbe7-d42a-4ff8-a3d3-c2eee90cbe93@github.com>

On Fri, 28 Mar 2025 21:23:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Few more events tests are opensourced:
> 
> * test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
> * test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java

test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java line 29:

> 27:  * @summary Test for no proper mouse coordinates on MOUSE_ENTER/MOUSE_EXIT events for Win boxes.
> 28:  * @key headful
> 29:  * @library /test/jdk/lib/client /test/jdk/java/awt/regtesthelpers

Applicable to all other tests

Suggestion:

 * @library /lib/client /java/awt/regtesthelpers

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24303#discussion_r2019441833

From azvegint at openjdk.org  Fri Mar 28 22:14:09 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Mar 2025 22:14:09 GMT
Subject: RFR: 8353126: Open source events tests batch1 [v2]
In-Reply-To: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
Message-ID: <Jo5pvhq02pMsxFU9goW34V9zAuKpY79yEjCb0qkKDfQ=.ccc06896-c525-49a4-a37e-75f4a31b311c@github.com>

> Few more events tests are opensourced:
> 
> * test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
> * test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24303/files
  - new: https://git.openjdk.org/jdk/pull/24303/files/826965e5..f2ebadd2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24303&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24303/head:pull/24303

PR: https://git.openjdk.org/jdk/pull/24303

From azvegint at openjdk.org  Fri Mar 28 22:14:12 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Mar 2025 22:14:12 GMT
Subject: RFR: 8353126: Open source events tests batch1 [v2]
In-Reply-To: <K0ka7WW_B6DJob7RSCROQHttDFEFt9Jp9_E1wjlNYZ4=.f0b2bbe7-d42a-4ff8-a3d3-c2eee90cbe93@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
 <K0ka7WW_B6DJob7RSCROQHttDFEFt9Jp9_E1wjlNYZ4=.f0b2bbe7-d42a-4ff8-a3d3-c2eee90cbe93@github.com>
Message-ID: <dCAMlpKMBYPZoLJKtdf0Vqc15ZW9Wn8T48Bj64v3CSU=.fa0f4214-03f4-4089-85a1-0ed0fa0d098b@github.com>

On Fri, 28 Mar 2025 21:37:22 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java line 29:
> 
>> 27:  * @summary Test for no proper mouse coordinates on MOUSE_ENTER/MOUSE_EXIT events for Win boxes.
>> 28:  * @key headful
>> 29:  * @library /test/jdk/lib/client /test/jdk/java/awt/regtesthelpers
> 
> Applicable to all other tests
> 
> Suggestion:
> 
>  * @library /lib/client /java/awt/regtesthelpers

Both options work, but I updated to the shorter version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24303#discussion_r2019486339

From honkar at openjdk.org  Fri Mar 28 23:07:20 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Mar 2025 23:07:20 GMT
Subject: RFR: 8353126: Open source events tests batch1 [v2]
In-Reply-To: <Jo5pvhq02pMsxFU9goW34V9zAuKpY79yEjCb0qkKDfQ=.ccc06896-c525-49a4-a37e-75f4a31b311c@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
 <Jo5pvhq02pMsxFU9goW34V9zAuKpY79yEjCb0qkKDfQ=.ccc06896-c525-49a4-a37e-75f4a31b311c@github.com>
Message-ID: <dJq54rjvO0ww0P1cypurWibaVXS-H3YCI2Ta4AaqRtY=.419428c4-116d-47a1-ae99-593dff48e70b@github.com>

On Fri, 28 Mar 2025 22:14:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Few more events tests are opensourced:
>> 
>> * test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
>> * test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

LGTM

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24303#pullrequestreview-2727005235

From philip.race at oracle.com  Sat Mar 29 03:32:47 2025
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Mar 2025 20:32:47 -0700
Subject: Expected behavior of Font.canDisplay* methods?
In-Reply-To: <CAPA+ug49nX6bP=0r5FS3oYgPHmR44akX4Bg=bT5_7fsB0bTBHw@mail.gmail.com>
References: <CAPA+ug49nX6bP=0r5FS3oYgPHmR44akX4Bg=bT5_7fsB0bTBHw@mail.gmail.com>
Message-ID: <513ec9e0-3660-4cec-b25f-1341bba54764@oracle.com>

I don't have any appetite for changing things here right now. Meaning it 
needs a lot of thinking about.

I was nervous about this when the PR was proposed : see my comment in 
https://github.com/openjdk/jdk/pull/22670
----
One thing this fix does is change the logic which we have today
FROM

Let the font have first say. If it maps the code point, use what the 
font provides,
the font should know what it is doing. And only map to zero if the font 
does not support the code point
TO
Never mind what the font says, these are always invisible and zero width.
I have no easy way to know how this is going to work out in practice.
----

The points raised here mainly re-assert that nervousness and make me 
re-think if the changes in that PR were right.

These are the only APIs that (supposedly) tell you if a font really maps 
a code point.
Important to figure out if a font supports Chinese, or Arabic.
Unfortunately, the macOS implementation - which was contributed by Apple 
- is nearly useless because it'll answer using fall back fonts,
so everything is mappable. That still bugs me and I think whilst its 
fine to eliminate "boxes", its not fine that you have no idea which
font really is a good font for Arabic ..
Arguably we need APIs that are more direct about support for particular 
scripts etc, but the history is what it is.

But what if we added fallbacks on other platforms too ? At this point 
all of these APIs are utterly useless.
So this suggests these APIs should report what the specific font 
actually maps.
But on the other hand, it is confusing if it says it can't but then does.

So a lot of this is existing, but I am not inclined to make a few 
special code points cause us to turn everything upside down.

I think ideally there should be a separation between what a specific 
named font can do and what the platform can substitute
But these are concepts that largely came along after these APIs were 
designed.
New API ? How does that help older releases ? So what works for everyone ?
I could go on .. but there are more pressing font problems I've been 
working on without time to finish.

-phil.







On 3/28/25 10:38 AM, Daniel Gredler wrote:
> Hi all,
>
> After some of the recent fixes for default-ignorable characters [1, 2] 
> I'm wondering what the expected behavior for the following methods is 
> w.r.t. default-ignorable characters (or really any invisible glyphs):
>
> Font.canDisplay(char)
> Font.canDisplay(int)
> Font.canDisplayUpTo(String)
> Font.canDisplayUpTo(char[], int, int)
> Font.canDisplayUpTo(CharacterIterator, int, int)
>
> The JavaDoc for the first two methods explicitly states "checks if 
> this Font has a glyph for the specified character", which is clear 
> enough, but doesn't match the method name since in reality any font 
> can display e.g. U+200B (zero width space) regardless of whether it 
> has a glyph in the font, since U+200B will always map to the invisible 
> glyph and will be skipped during layout / rendering.
>
> The JavaDoc for the last three methods is more ambiguous, seeming to 
> focus on whether or not the font "can display" the string. Again, 
> characters which map to invisible glyphs do not need glyphs in the 
> font, so flagging them as "can't display" seems questionable.
>
> Basically, I'm wondering whether these five methods should be 
> communicating that chars which map to invisible glyphs can be 
> displayed, regardless of whether the font has a glyph for them.
>
> Thoughts?
>
> Take care,
>
> Daniel
>
> [1] http://www.unicode.org/L2/L2002/02368-default-ignorable.html
> [2] https://github.com/openjdk/jdk/pull/22670
>


From prr at openjdk.org  Sat Mar 29 04:23:06 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Mar 2025 04:23:06 GMT
Subject: RFR: 5043343: FileImageInputStream and FileImageOutputStream do
 not properly track streamPos for RandomAccessFile
In-Reply-To: <KrlvjCnbmsd3jkJ7cD29XqWSLUkyhbPDdrdic1PX7Ro=.52f6142a-8294-4281-a1f5-b7e19b6e34b8@github.com>
References: <KrlvjCnbmsd3jkJ7cD29XqWSLUkyhbPDdrdic1PX7Ro=.52f6142a-8294-4281-a1f5-b7e19b6e34b8@github.com>
Message-ID: <hCv8H2LsqC1K9pReoYyXGjC_TOXMdkKLttA9MS3W2_0=.1e9274a3-626b-487f-a642-c2032741f12f@github.com>

On Thu, 27 Mar 2025 22:13:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In the respective constructors, set the value of the initial stream position to the current file position.

LGTM but off-line I'll send some additional testing suggestions, to be 99.9% vs 99% sure

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24283#pullrequestreview-2727244337

From prr at openjdk.org  Sat Mar 29 20:33:10 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Mar 2025 20:33:10 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <tezoTHXN0OXpk8-nYHA_l4jzhsBIVzHnz67gTu5AsTc=.655cf3d1-b527-4b26-ae27-5d26bcd7bc46@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
 <tezoTHXN0OXpk8-nYHA_l4jzhsBIVzHnz67gTu5AsTc=.655cf3d1-b527-4b26-ae27-5d26bcd7bc46@github.com>
Message-ID: <KJmBNN5vvUycpJkF8_bSZsS3_RjmqTePO_XskwezI5w=.84bffe30-8347-424d-b841-f445e59d29d6@github.com>

On Mon, 17 Mar 2025 12:36:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>         mii.fMask = MIIM_FTYPE | MIIM_STRING | MIIM_ID | MIIM_BITMAP | MIIM_CHECKMARKS;

Per 
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-menuiteminfoa

The MFT_BITMAP, MFT_SEPARATOR, and MFT_STRING values cannot be combined with one another. 
(nb MIIM is the replacement name for MFT but the same applies)

I suspect you mean to be setting
HBITMAP   hbmpChecked;
and/or
  HBITMAP   hbmpUnchecked;

not
 HBITMAP   hbmpItem;
which is used to display a bitmap instead of a text string label.

Also you aren't clearing the fMask / resetting it when using the entries without a bitmap
I have no idea how much all of this can confuse the GDI API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2764231962

From kizune at openjdk.org  Mon Mar 31 06:21:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 31 Mar 2025 06:21:11 GMT
Subject: RFR: 8353126: Open source events tests batch1 [v2]
In-Reply-To: <Jo5pvhq02pMsxFU9goW34V9zAuKpY79yEjCb0qkKDfQ=.ccc06896-c525-49a4-a37e-75f4a31b311c@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
 <Jo5pvhq02pMsxFU9goW34V9zAuKpY79yEjCb0qkKDfQ=.ccc06896-c525-49a4-a37e-75f4a31b311c@github.com>
Message-ID: <3tKHdSjBVHTFo07xi-yDHlLcbP6RinW7SE13b6vd8Hk=.f8c703b6-dd45-465e-a619-10a36a1d7f14@github.com>

On Fri, 28 Mar 2025 22:14:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Few more events tests are opensourced:
>> 
>> * test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
>> * test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24303#pullrequestreview-2728319706

From djgredler at gmail.com  Mon Mar 31 12:38:37 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 31 Mar 2025 14:38:37 +0200
Subject: Expected behavior of Font.canDisplay* methods?
In-Reply-To: <513ec9e0-3660-4cec-b25f-1341bba54764@oracle.com>
References: <CAPA+ug49nX6bP=0r5FS3oYgPHmR44akX4Bg=bT5_7fsB0bTBHw@mail.gmail.com>
 <513ec9e0-3660-4cec-b25f-1341bba54764@oracle.com>
Message-ID: <CAPA+ug6TvE-QfktChSOgvzmFy072hx0di7My4mdNL131FW2SKg@mail.gmail.com>

Hi Phil,

Thank you for the detailed response. I'll drop this one for now :-)

Just one comment though, since my understanding is a bit different from the
summary below:

I don't think it's quite accurate to summarize as "we 100% trusted fonts,
now we don't". The `CMap.getFormatCharGlyph(int)` was already doing a lot
of heavy lifting in overriding the font for some of the most common
"metadata" code points, but it was incomplete (not the full list per
Unicode) and inconsistent (applied to TTF fonts only). So I would more
optimistically describe the change as "we incompletely and inconsistently
ignored font glyphs, now we do it consistently and per the standard (which
usually matches user expectations)".

Take care,

Daniel



On Sat, Mar 29, 2025 at 4:32?AM Philip Race <philip.race at oracle.com> wrote:

> I don't have any appetite for changing things here right now. Meaning it
> needs a lot of thinking about.
>
> I was nervous about this when the PR was proposed : see my comment in
> https://github.com/openjdk/jdk/pull/22670
> ----
> One thing this fix does is change the logic which we have today
> FROM
>
> Let the font have first say. If it maps the code point, use what the
> font provides,
> the font should know what it is doing. And only map to zero if the font
> does not support the code point
> TO
> Never mind what the font says, these are always invisible and zero width.
> I have no easy way to know how this is going to work out in practice.
> ----
>
> The points raised here mainly re-assert that nervousness and make me
> re-think if the changes in that PR were right.
>
> These are the only APIs that (supposedly) tell you if a font really maps
> a code point.
> Important to figure out if a font supports Chinese, or Arabic.
> Unfortunately, the macOS implementation - which was contributed by Apple
> - is nearly useless because it'll answer using fall back fonts,
> so everything is mappable. That still bugs me and I think whilst its
> fine to eliminate "boxes", its not fine that you have no idea which
> font really is a good font for Arabic ..
> Arguably we need APIs that are more direct about support for particular
> scripts etc, but the history is what it is.
>
> But what if we added fallbacks on other platforms too ? At this point
> all of these APIs are utterly useless.
> So this suggests these APIs should report what the specific font
> actually maps.
> But on the other hand, it is confusing if it says it can't but then does.
>
> So a lot of this is existing, but I am not inclined to make a few
> special code points cause us to turn everything upside down.
>
> I think ideally there should be a separation between what a specific
> named font can do and what the platform can substitute
> But these are concepts that largely came along after these APIs were
> designed.
> New API ? How does that help older releases ? So what works for everyone ?
> I could go on .. but there are more pressing font problems I've been
> working on without time to finish.
>
> -phil.
>
>
>
>
>
>
>
> On 3/28/25 10:38 AM, Daniel Gredler wrote:
> > Hi all,
> >
> > After some of the recent fixes for default-ignorable characters [1, 2]
> > I'm wondering what the expected behavior for the following methods is
> > w.r.t. default-ignorable characters (or really any invisible glyphs):
> >
> > Font.canDisplay(char)
> > Font.canDisplay(int)
> > Font.canDisplayUpTo(String)
> > Font.canDisplayUpTo(char[], int, int)
> > Font.canDisplayUpTo(CharacterIterator, int, int)
> >
> > The JavaDoc for the first two methods explicitly states "checks if
> > this Font has a glyph for the specified character", which is clear
> > enough, but doesn't match the method name since in reality any font
> > can display e.g. U+200B (zero width space) regardless of whether it
> > has a glyph in the font, since U+200B will always map to the invisible
> > glyph and will be skipped during layout / rendering.
> >
> > The JavaDoc for the last three methods is more ambiguous, seeming to
> > focus on whether or not the font "can display" the string. Again,
> > characters which map to invisible glyphs do not need glyphs in the
> > font, so flagging them as "can't display" seems questionable.
> >
> > Basically, I'm wondering whether these five methods should be
> > communicating that chars which map to invisible glyphs can be
> > displayed, regardless of whether the font has a glyph for them.
> >
> > Thoughts?
> >
> > Take care,
> >
> > Daniel
> >
> > [1] http://www.unicode.org/L2/L2002/02368-default-ignorable.html
> > [2] https://github.com/openjdk/jdk/pull/22670
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250331/bed6c18f/attachment.htm>

From azvegint at openjdk.org  Mon Mar 31 12:39:14 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 31 Mar 2025 12:39:14 GMT
Subject: Integrated: 8352860: Open source events tests batch0
In-Reply-To: <_j29C-JVs5YYDvJrE_rtOdpvmj4mIU-oJX1KAdDNDWs=.6e630ae4-a1d6-417e-8914-96518d7a71ff@github.com>
References: <_j29C-JVs5YYDvJrE_rtOdpvmj4mIU-oJX1KAdDNDWs=.6e630ae4-a1d6-417e-8914-96518d7a71ff@github.com>
Message-ID: <6lL6szyyuIDNG6YWC-qVt4xOC8gkTRuaXzWe9-2qjg4=.0bf11b0c-41f1-415c-8523-6e2de6909b14@github.com>

On Fri, 28 Mar 2025 13:20:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Few events tests are opensourced
> 
> * java/awt/event/ClickEventsTest.java
> * java/awt/event/WindowActivatedEventTest.java
> 
> Testing is good

This pull request has now been integrated.

Changeset: d4d18350
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4d18350f367a18813d0d418169e852c1530418e
Stats:     302 lines in 2 files changed: 302 ins; 0 del; 0 mod

8352860: Open source events tests batch0

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/24293

From azvegint at openjdk.org  Mon Mar 31 16:43:40 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 31 Mar 2025 16:43:40 GMT
Subject: Integrated: 8353126: Open source events tests batch1
In-Reply-To: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
References: <-ShcrQcRX9lkt5nxhU9Xa14-yaImEuLCaWxsWlkDHMQ=.c1d6993e-570d-45d5-893e-d96d19cdf3cf@github.com>
Message-ID: <05tq024HGpUi-4O7RLWvkRCYrdiiqWINuyiRFD71fJo=.ce2b7696-fa8f-4b96-a12c-61354194dedc@github.com>

On Fri, 28 Mar 2025 21:23:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Few more events tests are opensourced:
> 
> * test/jdk/java/awt/event/MouseEvent/DragToLightweightTest.java
> * test/jdk/java/awt/event/MouseEvent/MouseEnterTest.java

This pull request has now been integrated.

Changeset: cd5a43a9
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd5a43a98030a534babb01cfc4521e7e9bc89b91
Stats:     321 lines in 2 files changed: 321 ins; 0 del; 0 mod

8353126: Open source events tests batch1

Reviewed-by: honkar, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/24303

From prr at openjdk.org  Mon Mar 31 23:01:39 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Mar 2025 23:01:39 GMT
Subject: RFR: 8353324: Clean up of comments and import after 8319192
Message-ID: <XEG2TzDcCBfmQXvyRBFz_MVInVcHaPg0ZwAUo8oAP54=.7b9a8a41-fdeb-46ba-8946-7151d4a71498@github.com>

Somehow I did not commit these changes when fixing JDK-8319192

-------------

Commit messages:
 - 8353324

Changes: https://git.openjdk.org/jdk/pull/24339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353324
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24339/head:pull/24339

PR: https://git.openjdk.org/jdk/pull/24339