From kizune at openjdk.org Sat Jul 1 00:14:53 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 1 Jul 2023 00:14:53 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse In-Reply-To: References: Message-ID: <6bCkQV7htcQu8AGUuhE7btt3Co2TmufgQ0IY5gvQFmM=.599902a7-3020-49b7-a2e9-61a302fe3f18@github.com> On Fri, 30 Jun 2023 22:29:05 GMT, Harshitha Onkar wrote: > **Problem:** > > Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Solution:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > It should be tested for two cases: > > CASE 1 : Run the test as an automated test WITHOUT any mouse movement and let the Robot go through al... src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 69: > 67: static int allModifiersMask = kCGEventFlagMaskShift | kCGEventFlagMaskControl > 68: | kCGEventFlagMaskAlternate | kCGEventFlagMaskCommand > 69: | kCGEventFlagMaskAlphaShift; You need to add kCGEventFlagMaskSecondaryFn here otherwise the "secondary fn fix" might catch regression. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1248350915 From honkar at openjdk.org Sat Jul 1 00:29:14 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 1 Jul 2023 00:29:14 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse [v2] In-Reply-To: <6bCkQV7htcQu8AGUuhE7btt3Co2TmufgQ0IY5gvQFmM=.599902a7-3020-49b7-a2e9-61a302fe3f18@github.com> References: <6bCkQV7htcQu8AGUuhE7btt3Co2TmufgQ0IY5gvQFmM=.599902a7-3020-49b7-a2e9-61a302fe3f18@github.com> Message-ID: On Sat, 1 Jul 2023 00:11:53 GMT, Alexander Zuev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> kCGEventFlagMaskSecondaryFn added > > src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 69: > >> 67: static int allModifiersMask = kCGEventFlagMaskShift | kCGEventFlagMaskControl >> 68: | kCGEventFlagMaskAlternate | kCGEventFlagMaskCommand >> 69: | kCGEventFlagMaskAlphaShift; > > You need to add kCGEventFlagMaskSecondaryFn here otherwise the "secondary fn fix" might catch regression. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1248354230 From honkar at openjdk.org Sat Jul 1 00:29:11 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 1 Jul 2023 00:29:11 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse [v2] In-Reply-To: References: Message-ID: > **Problem:** > > Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Solution:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > It should be tested for two cases: > > CASE 1 : Run the test as an automated test WITHOUT any mouse movement and let the Robot go through al... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: kCGEventFlagMaskSecondaryFn added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/20f8fd07..511955ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From duke at openjdk.org Mon Jul 3 01:35:54 2023 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 3 Jul 2023 01:35:54 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse [v2] In-Reply-To: References: Message-ID: On Sat, 1 Jul 2023 00:29:11 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> It should be tested for two cases: >> >> CASE 1 : Run the test as an autom... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > kCGEventFlagMaskSecondaryFn added test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 217: > 215: if (jTextArea.getCaretPosition() != EXPECTED_CARET_POS_CTRL) { > 216: errorLog.append("For Control key, Actual and Expected caret position differ \n" + > 217: "Expected Position : " + EXPECTED_CARET_POS_CTRL + " Actual Position : " + jTextArea.getCaretPosition() + "\n"); Most of the errorLog.append("") are more than 80 column length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1249998004 From abhiscxk at openjdk.org Mon Jul 3 04:52:57 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 3 Jul 2023 04:52:57 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse [v2] In-Reply-To: References: Message-ID: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> On Sat, 1 Jul 2023 00:29:11 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> It should be tested for two cases: >> >> CASE 1 : Run the test as an autom... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > kCGEventFlagMaskSecondaryFn added src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 1: > 1: /* Please update copyright year here and in other files as well. src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 426: > 424: } > 425: > 426: static inline int GetCGKeyMask(int cgKeyCode) Suggestion: static inline int GetCGKeyMask(int cgKeyCode) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1250217347 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1250211432 From itakiguchi at openjdk.org Mon Jul 3 08:03:54 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Mon, 3 Jul 2023 08:03:54 GMT Subject: RFR: 6928542: Chinese characters in RTF are not decoded In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 05:47:35 GMT, Ichiroh Takiguchi wrote: > "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1" > https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf > It refers windgi.h > https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica > > Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542) > > Additional change: > Special character `\line` should `\n` > > **Note:** Following GitHub actions were failed > linux-x86 / test (jdk/tier1 part 1) was failed, it seems it was already reported >> [JDK-8305875](https://bugs.openjdk.org/browse/JDK-8305875) Test TraceVirtualThreadLocals should be run with continuations only > > windows-aarch64 / build (debug) was failed, but I have no idea... I'd like to start a discussion about Swing's RTF implementation to support font charset. If you are interested in RTF, please put your comment into this PR or [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542). Non-reviewers are also welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1617575109 From abhiscxk at openjdk.org Mon Jul 3 09:16:58 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 3 Jul 2023 09:16:58 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Fri, 30 Jun 2023 19:36:43 GMT, Alexey Ivanov wrote: >> I need to check with custom renderer. >> >> If I understand correctly, with current fix the `getSelectedItem` method will return the `rectangle` object and then calling `toString` method will return rectangle's dimension instead of the displayed text in JComboBox and that may result incorrectly. Right? > >> If I understand correctly, with current fix the `getSelectedItem` method will return the `rectangle` object and then calling `toString` method will return rectangle's dimension instead of the displayed text in JComboBox and that may result incorrectly. Right? > > Yes. > > I wonder if other components support this scenario. > What if `JComboBox` uses a non-standard renderer which takes a property from an object? Let's assume, `JComboBox` is populated with `Rectangle` objects, a custom renderer is set which displays the value of the `bottom` field in the combo box. Your code, if I understand it correctly, will default to _full rectangle_ rather than what's really displayed. > You were right. At least in this case the current fix returns _full_rectangle_ dimension in a string form in stead of the text displayed in JComboBox. I think it is required to look for alternate fix, probably to get the displayed text from JComboBox and set it as an accessibleName. >How does JTable handle this kind of situation? Or JList? I case of JTable and JList, the accessible context is of type JLabel which returns the accessibleName in string format. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1250537863 From duke at openjdk.org Mon Jul 3 10:36:12 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 3 Jul 2023 10:36:12 GMT Subject: Integrated: 8307934 JRobot.moveMouseTo must access component on EDT In-Reply-To: References: Message-ID: <_1gzBjfaQpsx467a0BBkvbJcO53FbzzfYFISZcVqUnY=.8964637e-7645-4773-b15a-fc59efc47288@github.com> On Wed, 7 Jun 2023 12:54:54 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > I have updated the JRobot.java file for enabling EDT support, along with I have removed warning BUTTON1_MASK with 'BUTTON1_DOWN_MASK'. > > Regards, > Renjith This pull request has now been integrated. Changeset: 9d2e0b2a Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/9d2e0b2a80084f1769e8dd40f11a39eadb54e8b3 Stats: 78 lines in 1 file changed: 48 ins; 14 del; 16 mod 8307934: JRobot.moveMouseTo must access component on EDT Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/14354 From aivanov at openjdk.org Mon Jul 3 11:14:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 11:14:58 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Mon, 3 Jul 2023 09:14:23 GMT, Abhishek Kumar wrote: > > What if `JComboBox` uses a non-standard renderer which takes a property from an object? Let's assume, `JComboBox` is populated with `Rectangle` objects, a custom renderer is set which displays the value of the `bottom` field in the combo box. Your code, if I understand it correctly, will default to _full rectangle_ rather than what's really displayed. > > You were right. At least in this case the current fix returns _full_rectangle_ dimension in a string form instead of the text displayed in JComboBox. Thank you for confirming it. > I had a doubt here if a custom renderer is used to populate the JComboBox, isn't it required to `override` the `toString` method to return useful information from user end? No, it's not required to override the `toString` method if the programmer doesn't use it. > If not then I think it is required to look for alternate fix, probably to get the displayed text from JComboBox and set it as an accessibleName. Could be? How would you get the text? It should be provided by a renderer? > > How does JTable handle this kind of situation? Or JList? > > I case of JTable and JList, the accessible context is of type JLabel which returns the accessibleName in string format. This doesn't really answer the question. Do `JTable` and `JList` correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from `toString`? If neither `JTable` nor `JList` handle this situation, it's okay to go with `toString` as you implemented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1250718052 From aivanov at openjdk.org Mon Jul 3 11:18:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 11:18:58 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Mon, 3 Jul 2023 11:11:47 GMT, Alexey Ivanov wrote: >>> What if `JComboBox` uses a non-standard renderer which takes a property from an object? Let's assume, `JComboBox` is populated with `Rectangle` objects, a custom renderer is set which displays the value of the `bottom` field in the combo box. Your code, if I understand it correctly, will default to _full rectangle_ rather than what's really displayed. >>> >> You were right. At least in this case the current fix returns _full_rectangle_ dimension in a string form in stead of the text displayed in JComboBox. I had a doubt here if a custom renderer is used to populate the JComboBox, isn't it required to `override` the `toString` method to return useful information from user end? >> >> If not then I think it is required to look for alternate fix, probably to get the displayed text from JComboBox and set it as an accessibleName. >> >> >How does JTable handle this kind of situation? Or JList? >> >> I case of JTable and JList, the accessible context is of type JLabel which returns the accessibleName in string format. > >> > What if `JComboBox` uses a non-standard renderer which takes a property from an object? Let's assume, `JComboBox` is populated with `Rectangle` objects, a custom renderer is set which displays the value of the `bottom` field in the combo box. Your code, if I understand it correctly, will default to _full rectangle_ rather than what's really displayed. >> >> You were right. At least in this case the current fix returns _full_rectangle_ dimension in a string form instead of the text displayed in JComboBox. > > Thank you for confirming it. > >> I had a doubt here if a custom renderer is used to populate the JComboBox, isn't it required to `override` the `toString` method to return useful information from user end? > > No, it's not required to override the `toString` method if the programmer doesn't use it. > >> If not then I think it is required to look for alternate fix, probably to get the displayed text from JComboBox and set it as an accessibleName. > > Could be? > > How would you get the text? It should be provided by a renderer? > >> > How does JTable handle this kind of situation? Or JList? >> >> I case of JTable and JList, the accessible context is of type JLabel which returns the accessibleName in string format. > > This doesn't really answer the question. Do `JTable` and `JList` correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from `toString`? > > If neither `JTable` nor `JList` handle this situation, it's okay to go with `toString` as you implemented. How does `JTable` handle the situation where an image is displayed? You can use SwingSet2 for testing: it displays colored text and images. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1250725240 From honkar at openjdk.org Mon Jul 3 17:43:34 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Jul 2023 17:43:34 GMT Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot on Mac when moving mouse [v3] In-Reply-To: References: Message-ID: > **Problem:** > > Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > It should be tested for two cases: > > CASE 1 : Run the test as an automated test WITHOUT any mouse movement and let the Robot go throug... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: copyright year, line-lengths updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/511955ef..0ab5b74b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=01-02 Stats: 43 lines in 4 files changed: 15 ins; 7 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From honkar at openjdk.org Mon Jul 3 18:36:01 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Jul 2023 18:36:01 GMT Subject: RFR: JDK-8311109: tautological-compare warning in awt_Win32GraphicsDevice.cpp Message-ID: Comparison typo fix. Should be monitor2 (mi2) instead of monitor1 (mi1). ------------- Commit messages: - changed to mi2 Changes: https://git.openjdk.org/jdk/pull/14760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311109 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14760/head:pull/14760 PR: https://git.openjdk.org/jdk/pull/14760 From djelinski at openjdk.org Mon Jul 3 18:46:58 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 3 Jul 2023 18:46:58 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag Message-ID: Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. This patch fixes the following clang warning: warning: argument unused during compilation: '-std:c11' Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. Testing: - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. ------------- Commit messages: - Update copyright - Simplify makefile - Revert template changes - Use CXXFLAGS where CPP files are compiled Changes: https://git.openjdk.org/jdk/pull/14758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311247 Stats: 22 lines in 5 files changed: 16 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14758/head:pull/14758 PR: https://git.openjdk.org/jdk/pull/14758 From aivanov at openjdk.org Mon Jul 3 18:56:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 18:56:53 GMT Subject: RFR: JDK-8311109: tautological-compare warning in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 18:28:40 GMT, Harshitha Onkar wrote: > Comparison typo fix. Should be monitor2 (mi2) instead of monitor1 (mi1). Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14760#pullrequestreview-1511652869 From aivanov at openjdk.org Mon Jul 3 20:25:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 20:25:53 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeli?ski wrote: > Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. > While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. > > This patch fixes the following clang warning: > > warning: argument unused during compilation: '-std:c11' > > > Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. > > Testing: > - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` > - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference > - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 135: > 133: OPTIMIZATION := HIGHEST, \ > 134: CFLAGS := $(CFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ > 135: CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ `LIBAWT_CFLAGS` applies to both C and C++, right? It contains some common flags; it follows the pattern with other libs below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14758#discussion_r1251253977 From aivanov at openjdk.org Mon Jul 3 20:41:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 20:41:57 GMT Subject: RFR: JDK-8302618: [MacOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: References: Message-ID: <9AQlXC1WHDMvt2dGxA6SB8qpx6GWpCH0xwLW_t4scoY=.b56555f3-fa3c-4072-87fa-457ceefb9e41@github.com> On Sat, 1 Jul 2023 00:29:11 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents on MacOS. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> It should be tested for two cases: >> >> CASE 1 : Run the test as an autom... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > kCGEventFlagMaskSecondaryFn added test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 67: > 65: CASE 1 : Run the test as an automated test and let the Robot go through all the test cases.\n > 66: CASE 2 : Run the test in semi-automated mode. While the Robot in typing, > 67: manually move the mouse (without clicking/dragging). Check if the test Passes or Fails.\n\n How does a user do this? test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 75: > 73: if (OSInfo.getOSType() != OSInfo.OSType.MACOSX) { > 74: System.out.println("This test is for MacOS platform only"); > 75: return; Use `jtreg.SkippedException` to indicate the test isn't applicable in this environment. The jtreg treats this exception in a special: the doesn't fail, it doesn't pass either ? it's skipped. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 83: > 81: robot.setAutoDelay(200); > 82: > 83: SwingUtilities.invokeAndWait(() -> createTestUI()); I don't insist, yet IDE usually shows a warning that such a lambda expression can be replaced with a method reference. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 176: > 174: > 175: private static void testAltKey() { > 176: jTextArea.setText(""); Should be called on EDT. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 189: > 187: robot.delay(500); > 188: > 189: if (!jTextArea.getText().equals(EXPECTED_RESULT_ALT)) { Should be called on EDT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251267910 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251263715 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251266700 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251265623 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251265712 From aivanov at openjdk.org Mon Jul 3 20:30:54 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 20:30:54 GMT Subject: RFR: JDK-8302618: [MacOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> References: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> Message-ID: On Mon, 3 Jul 2023 04:45:38 GMT, Abhishek Kumar wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> kCGEventFlagMaskSecondaryFn added > > src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 426: > >> 424: } >> 425: >> 426: static inline int GetCGKeyMask(int cgKeyCode) > > Suggestion: > > static inline int GetCGKeyMask(int cgKeyCode) { I disagree: the common style throughout this file is to put the opening brace on the following line. A few lines above, `GetCGKeyCode` follows the same style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251261953 From honkar at openjdk.org Mon Jul 3 20:46:01 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Jul 2023 20:46:01 GMT Subject: Integrated: JDK-8311109: tautological-compare warning in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 18:28:40 GMT, Harshitha Onkar wrote: > Comparison typo fix. Should be monitor2 (mi2) instead of monitor1 (mi1). This pull request has now been integrated. Changeset: d8a01216 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/d8a012161ad68d08467a6632c2bfb7c4dc341d28 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8311109: tautological-compare warning in awt_Win32GraphicsDevice.cpp Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/14760 From honkar at openjdk.org Mon Jul 3 21:30:56 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Jul 2023 21:30:56 GMT Subject: RFR: JDK-8302618: [MacOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: References: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> Message-ID: <9H6AYAPZRcQ4Za4y1wCJxaQBMa01xw3P3-VhYqqjjxw=.aecde16d-3531-4cc6-9728-89969a2a87bb@github.com> On Mon, 3 Jul 2023 20:28:35 GMT, Alexey Ivanov wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 426: >> >>> 424: } >>> 425: >>> 426: static inline int GetCGKeyMask(int cgKeyCode) >> >> Suggestion: >> >> static inline int GetCGKeyMask(int cgKeyCode) { > > I disagree: the common style throughout this file is to put the opening brace on the following line. A few lines above, `GetCGKeyCode` follows the same style. @aivanov-jdk Yeah, I wasn't sure of open brace placement in native - some methods follow Java-style of having the open brace on the same line and few others have it on the next line. Will revert it in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251290246 From aivanov at openjdk.org Mon Jul 3 21:30:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Jul 2023 21:30:57 GMT Subject: RFR: JDK-8302618: [MacOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: <9H6AYAPZRcQ4Za4y1wCJxaQBMa01xw3P3-VhYqqjjxw=.aecde16d-3531-4cc6-9728-89969a2a87bb@github.com> References: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> <9H6AYAPZRcQ4Za4y1wCJxaQBMa01xw3P3-VhYqqjjxw=.aecde16d-3531-4cc6-9728-89969a2a87bb@github.com> Message-ID: On Mon, 3 Jul 2023 21:26:13 GMT, Harshitha Onkar wrote: >> I disagree: the common style throughout this file is to put the opening brace on the following line. A few lines above, `GetCGKeyCode` follows the same style. > > @aivanov-jdk Yeah, I wasn't sure of open brace placement in native - some methods follow Java-style of having the open brace on the same line and few others have it on the next line. Will revert it in the next commit. Follow the style of the surrounding code so that added or modified lines don't stand out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1251291117 From djelinski at openjdk.org Tue Jul 4 04:56:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 4 Jul 2023 04:56:56 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:17:23 GMT, Alexey Ivanov wrote: >> Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. >> While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. >> >> This patch fixes the following clang warning: >> >> warning: argument unused during compilation: '-std:c11' >> >> >> Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. >> >> Testing: >> - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` >> - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference >> - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 135: > >> 133: OPTIMIZATION := HIGHEST, \ >> 134: CFLAGS := $(CFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ >> 135: CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ > > `LIBAWT_CFLAGS` applies to both C and C++, right? It contains some common flags; it follows the pattern with other libs below. That's correct. `LIBAWT_CFLAGS` contains a bunch of `-D` flags, which are common for C and C++, and `-EHsc` flag, which is probably C++ only, but the compiler doesn't complain. `jabswitch` below is using some C++-specific flags, but it only compiles one C++ file and no C files. I suppose we could simplify that makefile at some point. All other flags are common between C and C++. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14758#discussion_r1251480885 From abhiscxk at openjdk.org Tue Jul 4 09:05:58 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 09:05:58 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Mon, 3 Jul 2023 11:16:12 GMT, Alexey Ivanov wrote: >>> > What if `JComboBox` uses a non-standard renderer which takes a property from an object? Let's assume, `JComboBox` is populated with `Rectangle` objects, a custom renderer is set which displays the value of the `bottom` field in the combo box. Your code, if I understand it correctly, will default to _full rectangle_ rather than what's really displayed. >>> >>> You were right. At least in this case the current fix returns _full_rectangle_ dimension in a string form instead of the text displayed in JComboBox. >> >> Thank you for confirming it. >> >>> I had a doubt here if a custom renderer is used to populate the JComboBox, isn't it required to `override` the `toString` method to return useful information from user end? >> >> No, it's not required to override the `toString` method if the programmer doesn't use it. >> >>> If not then I think it is required to look for alternate fix, probably to get the displayed text from JComboBox and set it as an accessibleName. >> >> Could be? >> >> How would you get the text? It should be provided by a renderer? >> >>> > How does JTable handle this kind of situation? Or JList? >>> >>> I case of JTable and JList, the accessible context is of type JLabel which returns the accessibleName in string format. >> >> This doesn't really answer the question. Do `JTable` and `JList` correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from `toString`? >> >> If neither `JTable` nor `JList` handle this situation, it's okay to go with `toString` as you implemented. > > How does `JTable` handle the situation where an image is displayed? You can use SwingSet2 for testing: it displays colored text and images. > This doesn't really answer the question. Do JTable and JList correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from toString? Checked with JList and it correctly displayed the magnified text for a rectangle and custom renderer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1251728486 From abhiscxk at openjdk.org Tue Jul 4 09:31:03 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 09:31:03 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Tue, 4 Jul 2023 09:03:00 GMT, Abhishek Kumar wrote: >> How does `JTable` handle the situation where an image is displayed? You can use SwingSet2 for testing: it displays colored text and images. > >> This doesn't really answer the question. Do JTable and JList correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from toString? > > Checked with JList and it correctly displayed the magnified text for a rectangle and custom renderer. > The `toString` method of `Rectangle` class is not invoked. > How does `JTable` handle the situation where an image is displayed? You can use SwingSet2 for testing: it displays colored text and images. In Swingset2, the accessibleName is explicitly set for an image in JTable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1251762146 From tr at openjdk.org Tue Jul 4 11:09:17 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Jul 2023 11:09:17 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines Message-ID: The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. CI testing shows green. ------------- Commit messages: - Remove white space from test - Fix + Manual Test Changes: https://git.openjdk.org/jdk/pull/14766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311031 Stats: 93 lines in 2 files changed: 89 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From abhiscxk at openjdk.org Tue Jul 4 11:27:53 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 11:27:53 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:01:27 GMT, Tejesh R wrote: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) ![image](https://github.com/openjdk/jdk/assets/107542245/dfd80858-48df-4897-852f-e14528089276) There is a small gap between the horizontal and vertical line in size column (above 1 or Green) whereas grid lines don't have any gap. Is it correct? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1620068246 From abhiscxk at openjdk.org Tue Jul 4 11:31:00 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 11:31:00 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:01:27 GMT, Tejesh R wrote: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1111: > 1109: > 1110: g.setColor( MetalLookAndFeel.getControlDarkShadow() ); > 1111: SwingUtilities2.drawVLine(g,w-1, 0, h-1); Suggestion: SwingUtilities2.drawVLine(g, w-1, 0, h-1); src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1112: > 1110: g.setColor( MetalLookAndFeel.getControlDarkShadow() ); > 1111: SwingUtilities2.drawVLine(g,w-1, 0, h-1); > 1112: SwingUtilities2.drawHLine(g,1, w-1,h-1); Suggestion: SwingUtilities2.drawHLine(g, 1, w-1, h-1); src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1114: > 1112: SwingUtilities2.drawHLine(g,1, w-1,h-1); > 1113: g.setColor( MetalLookAndFeel.getControlHighlight() ); > 1114: SwingUtilities2.drawHLine(g,0, w-2,0 ); Suggestion: SwingUtilities2.drawHLine(g, 0, w-2, 0 ); src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1115: > 1113: g.setColor( MetalLookAndFeel.getControlHighlight() ); > 1114: SwingUtilities2.drawHLine(g,0, w-2,0 ); > 1115: SwingUtilities2.drawVLine(g,0, 0, h-2); Suggestion: SwingUtilities2.drawVLine(g, 0, 0, h-2); test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 1: > 1: /* Is it possible to make an automated test by comparing pixel colors of images before and after fix? test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 51: > 49: 2. Check if the Table header border vertical lines are > 50: aligned with table data grid lines. > 51: 3. If there is a miss-match between them press FAIL, Suggestion: 3. If there is a mismatch between them press FAIL, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251897705 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251898060 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251898963 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251899506 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251891816 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251890824 From tr at openjdk.org Tue Jul 4 11:37:57 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Jul 2023 11:37:57 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:01:27 GMT, Tejesh R wrote: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > ![image](https://user-images.githubusercontent.com/107542245/250886635-dfd80858-48df-4897-852f-e14528089276.png) > > There is a small gap between the horizontal and vertical line in size column (above 1 or Green) whereas grid lines don't have any gap. > > Is it correct? That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1620081745 From jdv at openjdk.org Tue Jul 4 11:39:56 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Jul 2023 11:39:56 GMT Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus In-Reply-To: References: Message-ID: <1tiSOcKrztJqVeUMFXT6HO58Tcszq-Uks4prbXkQLtI=.70fc0333-dfa8-48af-a321-57d3237ce713@github.com> On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan wrote: > Icon is placed after text in JTabbedPane for NimbusL&F since the text is drawn at LEADING position instead of TRAILING as is done for [other L&F](https://github.com/openjdk/jdk/blob/59c6c0e1b7148a7139f5e6a4ba2b19623c20c77d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L1155-L1160) > > Before fix > ![image](https://github.com/openjdk/jdk/assets/43534309/10d3f919-46e0-47e9-9d27-b33e49b2d62c) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/0c4906ec-df2a-4ce6-8399-fd1cd9e34450) Change looks good to me, except for a small query i have. Test runs fine with & without fix. test/jdk/javax/swing/plaf/nimbus/TestNimbusTabbedPaneIconPosition.java line 54: > 52: static volatile Rectangle bounds; > 53: private static void addTab(JTabbedPane aTabbedPane, int anIndex) { > 54: aTabbedPane.addTab("\u2588", new Icon() { First time i saw usage of Full block character for title and it took some time for me to understand this, unique way to find difference and read color. ------------- PR Review: https://git.openjdk.org/jdk/pull/14596#pullrequestreview-1512696121 PR Review Comment: https://git.openjdk.org/jdk/pull/14596#discussion_r1251907312 From jdv at openjdk.org Tue Jul 4 11:39:58 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Jul 2023 11:39:58 GMT Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus In-Reply-To: References: Message-ID: <_Za1wCG96TNXeQNTNP9_yEZSj28xc7lBj3nKdecBpW4=.82080362-96a1-408b-844c-ec7e481ccb23@github.com> On Wed, 28 Jun 2023 18:38:16 GMT, Damon Nguyen wrote: >> Icon is placed after text in JTabbedPane for NimbusL&F since the text is drawn at LEADING position instead of TRAILING as is done for [other L&F](https://github.com/openjdk/jdk/blob/59c6c0e1b7148a7139f5e6a4ba2b19623c20c77d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L1155-L1160) >> >> Before fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/10d3f919-46e0-47e9-9d27-b33e49b2d62c) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/0c4906ec-df2a-4ce6-8399-fd1cd9e34450) > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java line 659: > >> 657: tabIndex, clippedTitle, textRect, isSelected); >> 658: >> 659: > > What's the purpose of moving this line? Doesn't seem to change anything from what I've tested so far. @prsadhuk Is there any change in rendering based on what we draw first? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14596#discussion_r1251903244 From tr at openjdk.org Tue Jul 4 11:41:53 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Jul 2023 11:41:53 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:20:21 GMT, Abhishek Kumar wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 1: > >> 1: /* > > Is it possible to make an automated test by comparing pixel colors of images before and after fix? Tried to check the line alignment, but couldn't do it because of anti aliasing and scaling. And before and after fix means storing the image of before fix and then comparing with after fix? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251910298 From tr at openjdk.org Tue Jul 4 11:53:32 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Jul 2023 11:53:32 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v2] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/c97bafe8..b039be19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From abhiscxk at openjdk.org Tue Jul 4 11:53:33 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 11:53:33 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:35:35 GMT, Tejesh R wrote: > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. Is it require to address? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1620097528 From tr at openjdk.org Tue Jul 4 11:53:33 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Jul 2023 11:53:33 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v2] In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:39:01 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 1: >> >>> 1: /* >> >> Is it possible to make an automated test by comparing pixel colors of images before and after fix? > > Tried to check the line alignment, but couldn't do it because of anti aliasing and scaling. And before and after fix means storing the image of before fix and then comparing with after fix? Still I feel that would be blind comparison, since we won't be able to exactly test the fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251917815 From psadhukhan at openjdk.org Tue Jul 4 11:59:56 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Jul 2023 11:59:56 GMT Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus In-Reply-To: <1tiSOcKrztJqVeUMFXT6HO58Tcszq-Uks4prbXkQLtI=.70fc0333-dfa8-48af-a321-57d3237ce713@github.com> References: <1tiSOcKrztJqVeUMFXT6HO58Tcszq-Uks4prbXkQLtI=.70fc0333-dfa8-48af-a321-57d3237ce713@github.com> Message-ID: On Tue, 4 Jul 2023 11:35:59 GMT, Jayathirth D V wrote: >> Icon is placed after text in JTabbedPane for NimbusL&F since the text is drawn at LEADING position instead of TRAILING as is done for [other L&F](https://github.com/openjdk/jdk/blob/59c6c0e1b7148a7139f5e6a4ba2b19623c20c77d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L1155-L1160) >> >> Before fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/10d3f919-46e0-47e9-9d27-b33e49b2d62c) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/0c4906ec-df2a-4ce6-8399-fd1cd9e34450) > > test/jdk/javax/swing/plaf/nimbus/TestNimbusTabbedPaneIconPosition.java line 54: > >> 52: static volatile Rectangle bounds; >> 53: private static void addTab(JTabbedPane aTabbedPane, int anIndex) { >> 54: aTabbedPane.addTab("\u2588", new Icon() { > > First time i saw usage of Full block character for title and it took some time for me to understand this, unique way to find difference and read color. > Is there any change in rendering based on what we draw first? No, since we rely on iconRect and textRect which has its own x and y set so no matter is what called first, it will draw at its own set position ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14596#discussion_r1251929720 From jdv at openjdk.org Tue Jul 4 12:07:54 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Jul 2023 12:07:54 GMT Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus In-Reply-To: References: Message-ID: <2oE-DNivcq1EkX7ETFBF-75EK-m-pRkKv4BqG2OaqDk=.6a074275-99cc-43ff-a307-2d901ba4fbb2@github.com> On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan wrote: > Icon is placed after text in JTabbedPane for NimbusL&F since the text is drawn at LEADING position instead of TRAILING as is done for [other L&F](https://github.com/openjdk/jdk/blob/59c6c0e1b7148a7139f5e6a4ba2b19623c20c77d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L1155-L1160) > > Before fix > ![image](https://github.com/openjdk/jdk/assets/43534309/10d3f919-46e0-47e9-9d27-b33e49b2d62c) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/0c4906ec-df2a-4ce6-8399-fd1cd9e34450) Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14596#pullrequestreview-1512748142 From aivanov at openjdk.org Tue Jul 4 12:46:55 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 12:46:55 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeli?ski wrote: > Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. > While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. > > This patch fixes the following clang warning: > > warning: argument unused during compilation: '-std:c11' > > > Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. > > Testing: > - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` > - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference > - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. Marked as reviewed by aivanov (Reviewer). I believe a reviewer from the build team is still required. ------------- PR Review: https://git.openjdk.org/jdk/pull/14758#pullrequestreview-1512816406 PR Comment: https://git.openjdk.org/jdk/pull/14758#issuecomment-1620182635 From aivanov at openjdk.org Tue Jul 4 12:46:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 12:46:56 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 04:53:57 GMT, Daniel Jeli?ski wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 135: >> >>> 133: OPTIMIZATION := HIGHEST, \ >>> 134: CFLAGS := $(CFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ >>> 135: CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ >> >> `LIBAWT_CFLAGS` applies to both C and C++, right? It contains some common flags; it follows the pattern with other libs below. > > That's correct. `LIBAWT_CFLAGS` contains a bunch of `-D` flags, which are common for C and C++, and `-EHsc` flag, which is probably C++ only, but the compiler doesn't complain. > > `jabswitch` below is using some C++-specific flags, but it only compiles one C++ file and no C files. I suppose we could simplify that makefile at some point. All other flags are common between C and C++. Thank for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14758#discussion_r1251981511 From aivanov at openjdk.org Tue Jul 4 12:58:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 12:58:57 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:47:40 GMT, Abhishek Kumar wrote: > > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. > > Is it require to address? I'd rather say ?yes?. Since you're trying to improve border rendering, it's better to fix this inconsistency too. But to get pixel-perfect rendering, you may need to remove the scale transform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1620201488 From aivanov at openjdk.org Tue Jul 4 12:58:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 12:58:59 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v2] In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 11:46:31 GMT, Tejesh R wrote: >> Tried to check the line alignment, but couldn't do it because of anti aliasing and scaling. And before and after fix means storing the image of before fix and then comparing with after fix? > > Still I feel that would be blind comparison, since we won't be able to exactly test the fix. I strongly believe it should be an automated test. It may even be headless, if possible. There are a couple of examples which compare border rendering. You don't need to store images, just count the number of pixels of a particular colour. If you detect an inconsistency, fail the test. You may need to tweak the width or height of columns and rows so that old method results in visible inconsistencies in rendering. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1251993109 From aivanov at openjdk.org Tue Jul 4 14:20:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 14:20:57 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Tue, 4 Jul 2023 09:28:14 GMT, Abhishek Kumar wrote: >>> This doesn't really answer the question. Do JTable and JList correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from toString? >> >> Checked with JList and it correctly displayed the magnified text for a rectangle and custom renderer. >> The `toString` method of `Rectangle` class is not invoked. > >> How does `JTable` handle the situation where an image is displayed? You can use SwingSet2 for testing: it displays colored text and images. > > In Swingset2, the accessibleName is explicitly set for an image in JTable. > > This doesn't really answer the question. Do JTable and JList correctly display the magnified text when a custom renderer is used? In the case with rectangle and a custom renderer? Do they still display text from toString? > > Checked with JList and it correctly displayed the magnified text for a rectangle and custom renderer. The `toString` method of `Rectangle` class is not invoked. It means you have to look into how it's done in JList so that JCheckBox works in a similar way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1252089015 From aivanov at openjdk.org Tue Jul 4 14:32:55 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 14:32:55 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com> Message-ID: On Wed, 28 Jun 2023 06:00:49 GMT, Tejesh R wrote: >>> > This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution. >>> >>> It is possible that the width of the sting isn't calculated correctly, which could explain ?cut off? label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues. >> >> So long as such a margin doesn't just become another workaround fix, so >> >> Step 1 - measure it correctly >> Step 2 - add a pixel of clear margin space for added aesthetics. > > @prrace @aivanov-jdk I don't see much impact w.r.t to Label position/width for different scaling factors. > The width is computed in [stringWidth(String)](https://github.com/openjdk/jdk/blob/48e61c1df53c11ed49603abd70a3dd62a25f7be5/src/java.desktop/share/classes/sun/font/FontDesignMetrics.java#L457) which is same for all scaling factors (though their are slight differences between scaling factor, its corrected due to 0.5 addition at the end). The position is computed in [layoutCompoundLabelImpl()](https://github.com/openjdk/jdk/blame/526dba1a2942e444bf11d03d8eaf014b5ef20ccf/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1073) which seems to be correct, since the calculation for XPos which is `dx = (viewR.x + viewR.width) - (labelR_x + labelR_width);` seems straight forward. > Is there anything else which I should check or can we move ahead with current fix i.e., setting margin to 2pixels for RIGHT Aligned header text for Metal L&F? > Parallelly I will raise a bug and PR for header border alignment. @TejeshR13 I agree it looks correct, I can't spot any differences. Does `JLabel` always position the text correctly? If you make `JLabel` right-aligned, do you see any pixels which aren't painted as expected? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1620358450 From abhiscxk at openjdk.org Tue Jul 4 14:54:59 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jul 2023 14:54:59 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Tue, 4 Jul 2023 14:17:51 GMT, Alexey Ivanov wrote: > It means you have to look into how it's done in JList so that JCheckBox works in a similar way. For a JList, whenever `setText` is invoked from renderer's `getListCellRendererComponent` method, JLabel's text is set to the value displayed in JList. So, a11y API invokes the `getAccessibleName` method for `AccessibleJLabel` and that returns the correct string. But in case of JComboBox, a11y API invokes the `getAccessibleName` method for `AccessibleJButton` and that returns an empty string. To fix this we need to get the current displayed text is JComboBox as the other way around is not correct for custom renderer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1252133130 From aivanov at openjdk.org Tue Jul 4 18:03:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jul 2023 18:03:59 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Tue, 4 Jul 2023 14:52:14 GMT, Abhishek Kumar wrote: > But in case of JComboBox, a11y API invokes the `getAccessibleName` method for `AccessibleJButton` and that returns an empty string. And this seems to be the problem. The `getAccessibleName` method should be on JComboBox, or its editor, which should return the result of `getAccessibleName` of the renderer component. Does this work with editable combo box? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1252267170 From tr at openjdk.org Wed Jul 5 04:37:59 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jul 2023 04:37:59 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v2] In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 12:53:38 GMT, Alexey Ivanov wrote: >> Still I feel that would be blind comparison, since we won't be able to exactly test the fix. > > I strongly believe it should be an automated test. It may even be headless, if possible. There are a couple of examples which compare border rendering. > > You don't need to store images, just count the number of pixels of a particular colour. If you detect an inconsistency, fail the test. You may need to tweak the width or height of columns and rows so that old method results in visible inconsistencies in rendering. How will counting the number of pixels of a particular color help in validating the fix? I was planning to take a portion of image which includes header and 1st row and then check the column of vertical line from header to data, if all are same color then its a straight line, else fail the test... But I was not able to compare the data, some inconsistencies were there with rgb values.... Will try to work on that again...... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1252525241 From tr at openjdk.org Wed Jul 5 04:50:02 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jul 2023 04:50:02 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com> Message-ID: On Wed, 28 Jun 2023 06:00:49 GMT, Tejesh R wrote: >>> > This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution. >>> >>> It is possible that the width of the sting isn't calculated correctly, which could explain ?cut off? label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues. >> >> So long as such a margin doesn't just become another workaround fix, so >> >> Step 1 - measure it correctly >> Step 2 - add a pixel of clear margin space for added aesthetics. > > @prrace @aivanov-jdk I don't see much impact w.r.t to Label position/width for different scaling factors. > The width is computed in [stringWidth(String)](https://github.com/openjdk/jdk/blob/48e61c1df53c11ed49603abd70a3dd62a25f7be5/src/java.desktop/share/classes/sun/font/FontDesignMetrics.java#L457) which is same for all scaling factors (though their are slight differences between scaling factor, its corrected due to 0.5 addition at the end). The position is computed in [layoutCompoundLabelImpl()](https://github.com/openjdk/jdk/blame/526dba1a2942e444bf11d03d8eaf014b5ef20ccf/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1073) which seems to be correct, since the calculation for XPos which is `dx = (viewR.x + viewR.width) - (labelR_x + labelR_width);` seems straight forward. > Is there anything else which I should check or can we move ahead with current fix i.e., setting margin to 2pixels for RIGHT Aligned header text for Metal L&F? > Parallelly I will raise a bug and PR for header border alignment. > @TejeshR13 I agree it looks correct, I can't spot any differences. Does `JLabel` always position the text correctly? If you make `JLabel` right-aligned, do you see any pixels which aren't painted as expected? I didn't any differences in pixels, nor any computational issues specific to right-alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1621015245 From abhiscxk at openjdk.org Wed Jul 5 05:01:01 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jul 2023 05:01:01 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v3] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Tue, 4 Jul 2023 18:01:06 GMT, Alexey Ivanov wrote: > And this seems to be the problem. The getAccessibleName method should be on JComboBox, or its editor, which should return the result of getAccessibleName of the renderer component. Since the a11y APIs are called upon the `AquaComboBoxButton` (subclass of JButton) instance, need to set the text of the button to current displayed text of JComboBox. JComboBox contains `getAccessibleName` method but it is not invoked. > Does this work with editable combo box? Yeah, it worked for editable JComboBox. For editable JComboBox, the string is returned by NavigableTextAccessibility and it returns the current text displayed in editor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1252538309 From tr at openjdk.org Wed Jul 5 08:25:20 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jul 2023 08:25:20 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v3] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Automated test added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/b039be19..d491b6c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=01-02 Stats: 82 lines in 1 file changed: 44 ins; 4 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From tr at openjdk.org Wed Jul 5 08:42:01 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jul 2023 08:42:01 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 12:55:40 GMT, Alexey Ivanov wrote: > > > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. > > > > > > Is it require to address? > > I'd rather say ?yes?. Since you're trying to improve border rendering, it's better to fix this inconsistency too. > > But to get pixel-perfect rendering, you may need to remove the scale transform. I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1621299445 From abhiscxk at openjdk.org Wed Jul 5 09:43:24 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jul 2023 09:43:24 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v4] In-Reply-To: References: Message-ID: <_XdYb4m4xLww6lvWPP-0pRrvmRmSuHmzV6-PA4kkCgg=.eed0b261-0627-4d5a-86e9-74904ef74329@github.com> > The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. > > Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. > > Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. > > CI link is posted in JBS. Abhishek Kumar 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 six additional commits since the last revision: - set accessiblename to displayed text in JComboBox - Merge - Explicit frame dispose remove - merge - Review comment update - JComboBox selected item screen magnifier fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14497/files - new: https://git.openjdk.org/jdk/pull/14497/files/1cdc34dc..9fc3e2f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=02-03 Stats: 14798 lines in 711 files changed: 7200 ins; 3391 del; 4207 mod Patch: https://git.openjdk.org/jdk/pull/14497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497 PR: https://git.openjdk.org/jdk/pull/14497 From abhiscxk at openjdk.org Wed Jul 5 09:46:13 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jul 2023 09:46:13 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v4] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: On Wed, 5 Jul 2023 04:58:12 GMT, Abhishek Kumar wrote: >>> But in case of JComboBox, a11y API invokes the `getAccessibleName` method for `AccessibleJButton` and that returns an empty string. >> >> And this seems to be the problem. The `getAccessibleName` method should be on JComboBox, or its editor, which should return the result of `getAccessibleName` of the renderer component. >> >> Does this work with editable combo box? > >> And this seems to be the problem. The getAccessibleName method should be on JComboBox, or its editor, which should return the result of getAccessibleName of the renderer component. > > Since the a11y APIs are called upon the `AquaComboBoxButton` (subclass of JButton) instance, need to set the text of the button to current displayed text of JComboBox. JComboBox contains `getAccessibleName` method but it is not invoked. > >> Does this work with editable combo box? > > Yeah, it worked for editable JComboBox. For editable JComboBox, the string is returned by NavigableTextAccessibility and it returns the current text displayed in editor. Accessible name is set by getting the current text displayed in JComboBox (using `renderer getText()` method) in stead of setting it by JComboBox `getSelectedItem().toString() `method. Tested with custom renderer and it shows the magnified text as displayed in JComboBox. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1252843596 From aivanov at openjdk.org Wed Jul 5 11:58:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Jul 2023 11:58:53 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v3] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 04:35:18 GMT, Tejesh R wrote: >> I strongly believe it should be an automated test. It may even be headless, if possible. There are a couple of examples which compare border rendering. >> >> You don't need to store images, just count the number of pixels of a particular colour. If you detect an inconsistency, fail the test. You may need to tweak the width or height of columns and rows so that old method results in visible inconsistencies in rendering. > > How will counting the number of pixels of a particular color help in validating the fix? I was planning to take a portion of image which includes header and 1st row and then check the column of vertical line from header to data, if all are same color then its a straight line, else fail the test... But I was not able to compare the data, some inconsistencies were there with rgb values.... Will try to work on that again...... I wasn't clear enough, however, you understood it. There are three possible colours in the header: background, highlight and shadow. There's also text which we can ignore; if anti-aliasing is disabled, it will be solid colour only; alternatively the headers may have no text at all or a space. So, the header should start with highlight colour, there should be 2 pixels of it at 225%, right? Then the highlight is followed by the background until you find the shadow colour. It should also be 2 pixels. The shadow should be followed by the highlight colour of the next cell, there should be no background colour between highlight and shadow. This algorithm works in the [`ScaledEtchedBorderTest.java`](https://github.com/openjdk/jdk/blob/00ac46c06d8a7154a007cd67092bd80226a02fc3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java) test, see the [`checkBorder` method](https://github.com/openjdk/jdk/blob/00ac46c06d8a7154a007cd67092bd80226a02fc3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java#L151-L154). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1252999031 From aivanov at openjdk.org Wed Jul 5 12:39:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Jul 2023 12:39:59 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v4] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> Message-ID: <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> On Wed, 5 Jul 2023 09:43:12 GMT, Abhishek Kumar wrote: >>> And this seems to be the problem. The getAccessibleName method should be on JComboBox, or its editor, which should return the result of getAccessibleName of the renderer component. >> >> Since the a11y APIs are called upon the `AquaComboBoxButton` (subclass of JButton) instance, need to set the text of the button to current displayed text of JComboBox. JComboBox contains `getAccessibleName` method but it is not invoked. >> >>> Does this work with editable combo box? >> >> Yeah, it worked for editable JComboBox. For editable JComboBox, the string is returned by NavigableTextAccessibility and it returns the current text displayed in editor. > > Accessible name is set by getting the current text displayed in JComboBox (using `renderer getText()` method) in stead of setting it by JComboBox `getSelectedItem().toString() `method. Tested with custom renderer and it shows the magnified text as displayed in JComboBox. > > And this seems to be the problem. The getAccessibleName method should be on JComboBox, or its editor, which should return the result of getAccessibleName of the renderer component. > > Since the a11y APIs are called upon the `AquaComboBoxButton` (subclass of JButton) instance, need to set the text of the button to current displayed text of JComboBox. JComboBox contains `getAccessibleName` method but it is not invoked. This is weird. I expect the accessibility API is called on the `JComboBox` in both cases where it's editable or not. Could this be a bug? Should we fix it in a different way? > > Does this work with editable combo box? > > Yeah, it worked for editable JComboBox. For editable JComboBox, the string is returned by NavigableTextAccessibility and it returns the current text displayed in editor. That's good. And it makes me wonder why non-editable combo box behaves so differently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1253045504 From aivanov at openjdk.org Wed Jul 5 12:48:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Jul 2023 12:48:56 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 08:39:27 GMT, Tejesh R wrote: > I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. I admit I am confused to which part it refers. I re-checked your after screenshot and it looks fine to me. The shadow is followed by white highlight. There was background colour seen between these two colours in the before-fix screenshot. There's still a 2-pixel background colour under the highlight. Yet it is present in the before-fix too, so it looks it is designed this way for a smoother 3D shading effect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1621688006 From abhiscxk at openjdk.org Wed Jul 5 13:10:59 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jul 2023 13:10:59 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v4] In-Reply-To: <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> Message-ID: On Wed, 5 Jul 2023 12:37:23 GMT, Alexey Ivanov wrote: > This is weird. I expect the accessibility API is called on the JComboBox in both cases where it's editable or not. Could this be a bug? Should we fix it in a different way? AFAIK, I don't think that it is a bug because the arrow button in Aqua LAF is an instance of AquaComboBoxButton. So, native side invoked a11y API based on component. Similarly, For non-editable JComboBox, editor is an instance of JTextField and a11y API invoked on NavigableTextAccessibility. I think this may be a solution to handle custom as well as default renderer. One of the CI test failed with this fix. Looking into it, will update it accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1253083125 From aivanov at openjdk.org Wed Jul 5 13:20:00 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Jul 2023 13:20:00 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v4] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> Message-ID: On Wed, 5 Jul 2023 13:06:05 GMT, Abhishek Kumar wrote: > > This is weird. I expect the accessibility API is called on the JComboBox in both cases where it's editable or not. Could this be a bug? Should we fix it in a different way? > > AFAIK, I don't think that it is a bug because the arrow button in Aqua LAF is an instance of AquaComboBoxButton. So, native side invoked a11y API based on component. Similarly, For non-editable JComboBox, editor is an instance of JTextField and a11y API invoked on NavigableTextAccessibility. That's the problem: *why* is it called on *the combo button* instead of the combo box itself? It doesn't look right. In case of editable `JComboBox`, it consists of two components: an editor and the button. I assume the implementation of accessible interfaces gets called on the first child of the combo box. It's about right for the editable component: the editor is the main component of the combo box. But it doesn't look right to me that the drop-down button is the main component of the combo box if it's non-editable. The combo box should handle the accessibility request itself in this case. It still uses the same renderer which can't be put into editable state. The renderer is never added into containment hierarchy. Or there could be a *dummy* editor which handles the accessibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1253096757 From clanger at openjdk.org Wed Jul 5 13:53:58 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 5 Jul 2023 13:53:58 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote: >> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove import Looks good overall. I made a few suggestions. test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java line 40: > 38: * Agent's JAR file contains modified class java.util.TooManyListenersException (it is assumed > 39: * that this class isn't loaded before agent is loaded), agent instantiates TooManyListenersException > 40: * and checks that non-modified version of this class was loaded from jdk image (not from agent's JAR). "from the jdk image" test/jdk/com/sun/tools/attach/ProviderTest.java line 110: > 108: public static void main(String args[]) throws Exception { > 109: // deal with internal builds where classes are loaded from the > 110: // 'classes' directory rather than the image modules file "... rather than the runtime image" test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 27: > 25: * @test > 26: * @bug 4798312 > 27: * @summary In Windows, javap doesn't load classes from image "... from the runtime image" ------------- Changes requested by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514576016 PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253140142 PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253141204 PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253142105 From clanger at openjdk.org Wed Jul 5 13:54:01 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 5 Jul 2023 13:54:01 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196: >> >>> 194: >>> 195: /** >>> 196: * Set whether or not to use ct.sym as an alternate >> >> As an alternate to what? This needs something else. > > should "to the image modules files" be used instead ? maybe "... to the current runtime."? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253139297 From tr at openjdk.org Wed Jul 5 14:10:56 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jul 2023 14:10:56 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v3] In-Reply-To: References: Message-ID: <0zL7jlnJKH37fvTMUlD9Ke2gh2hLTwsir4GX7fYduWQ=.97043650-d272-4556-9e62-35d4b5a13522@github.com> On Wed, 5 Jul 2023 11:56:05 GMT, Alexey Ivanov wrote: >> How will counting the number of pixels of a particular color help in validating the fix? I was planning to take a portion of image which includes header and 1st row and then check the column of vertical line from header to data, if all are same color then its a straight line, else fail the test... But I was not able to compare the data, some inconsistencies were there with rgb values.... Will try to work on that again...... > > I wasn't clear enough, however, you understood it. There are three possible colours in the header: background, highlight and shadow. There's also text which we can ignore; if anti-aliasing is disabled, it will be solid colour only; alternatively the headers may have no text at all or a space. > > So, the header should start with highlight colour, there should be 2 pixels of it at 225%, right? Then the highlight is followed by the background until you find the shadow colour. It should also be 2 pixels. The shadow should be followed by the highlight colour of the next cell, there should be no background colour between highlight and shadow. > > This algorithm works in the [`ScaledEtchedBorderTest.java`](https://github.com/openjdk/jdk/blob/00ac46c06d8a7154a007cd67092bd80226a02fc3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java) test, see the [`checkBorder` method](https://github.com/openjdk/jdk/blob/00ac46c06d8a7154a007cd67092bd80226a02fc3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java#L151-L154). I understood your algorithm, hadn't thought this way. What I did is to get the grid line color from data cell, then just compare for the same color at same columns (for straight line/alignment w.r.t vertical grid line and vertical header border). Before my fix, there would be shift of header line to one pixel left, hence the test would fail. I guess this way I can ensure that the alignment will be there after the fix. I tested it in mach5, it is green. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1253166365 From jwaters at openjdk.org Wed Jul 5 14:29:54 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 5 Jul 2023 14:29:54 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeli?ski wrote: > Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. > While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. > > This patch fixes the following clang warning: > > warning: argument unused during compilation: '-std:c11' > > > Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. > > Testing: > - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` > - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference > - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. Marked as reviewed by jwaters (Committer). Looks good to me. I actually have a similar change applied locally on my repo too ------------- PR Review: https://git.openjdk.org/jdk/pull/14758#pullrequestreview-1514663833 PR Comment: https://git.openjdk.org/jdk/pull/14758#issuecomment-1621873070 From mbaesken at openjdk.org Wed Jul 5 15:07:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Jul 2023 15:07:15 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4] In-Reply-To: References: Message-ID: > There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14593/files - new: https://git.openjdk.org/jdk/pull/14593/files/9b2232a7..3a7b057a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593 PR: https://git.openjdk.org/jdk/pull/14593 From clanger at openjdk.org Wed Jul 5 15:07:16 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 5 Jul 2023 15:07:16 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 15:01:52 GMT, Matthias Baesken wrote: >> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust comments Fine from my end now. Just one minor nit left. ? src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196: > 194: > 195: /** > 196: * Set whether or not to use ct.sym as an alternate to the current runtime You should bring back the period at the end of the sentence. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514740197 PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253244166 From mbaesken at openjdk.org Wed Jul 5 15:07:17 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Jul 2023 15:07:17 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote: >> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove import Hi Christoph, thanks for the suggestions, I added some changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1621939153 From abhiscxk at openjdk.org Wed Jul 5 17:45:35 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jul 2023 17:45:35 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: Message-ID: > The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. > > Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. > > Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. > > CI link is posted in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Add condition to check JLabel instance ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14497/files - new: https://git.openjdk.org/jdk/pull/14497/files/9fc3e2f8..47195a92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497 PR: https://git.openjdk.org/jdk/pull/14497 From cushon at openjdk.org Wed Jul 5 23:26:04 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 5 Jul 2023 23:26:04 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG Message-ID: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. ------------- Commit messages: - 6355567: AdobeMarkerSegment causes failure to read valid JPEG Changes: https://git.openjdk.org/jdk/pull/14779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6355567 Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14779/head:pull/14779 PR: https://git.openjdk.org/jdk/pull/14779 From prr at openjdk.org Wed Jul 5 23:42:54 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Jul 2023 23:42:54 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG In-Reply-To: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: <8ouXbdIy7Mo8L5LSxlcMyEqz-B9rW9Bwp6-Iofdw3bA=.09fa1564-8832-4e8a-a2ac-fa63fa178c4a@github.com> On Wed, 5 Jul 2023 23:19:39 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. The provided image for the test looks to me like a down-sized version of the image seen here https://thedisabledlist.com/2005/sinus-cavities. As such I don't see how you can provide it under the terms of the OCA as I then presume you don't own it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14779#issuecomment-1622688245 From honkar at openjdk.org Wed Jul 5 23:50:19 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Jul 2023 23:50:19 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:43:34 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> It should be tested for two cases: >> >> CASE 1 : Run the test as an auto... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year, line-lengths updated Test updated to run in 2 modes - automated and manual mode. Test instruction frame has been updated to appear only when executed in manual mode. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1622687859 From honkar at openjdk.org Wed Jul 5 23:50:19 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Jul 2023 23:50:19 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: <9AQlXC1WHDMvt2dGxA6SB8qpx6GWpCH0xwLW_t4scoY=.b56555f3-fa3c-4072-87fa-457ceefb9e41@github.com> References: <9AQlXC1WHDMvt2dGxA6SB8qpx6GWpCH0xwLW_t4scoY=.b56555f3-fa3c-4072-87fa-457ceefb9e41@github.com> Message-ID: On Mon, 3 Jul 2023 20:38:34 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> kCGEventFlagMaskSecondaryFn added > > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 67: > >> 65: CASE 1 : Run the test as an automated test and let the Robot go through all the test cases.\n >> 66: CASE 2 : Run the test in semi-automated mode. While the Robot in typing, >> 67: manually move the mouse (without clicking/dragging). Check if the test Passes or Fails.\n\n > > How does a user do this? Test updated to run twice (automated & manual), to cover the two cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1253759065 From honkar at openjdk.org Wed Jul 5 23:50:19 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Jul 2023 23:50:19 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v4] In-Reply-To: References: Message-ID: <0Rle2NJyM6dQskVBO6t8ZWjdyxCVTgo_m3ObVmYe05c=.e20112c4-0f39-4497-9f63-8bb83ab02e24@github.com> > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > It should be tested for two cases: > > CASE 1 : Run the test as an automated test WITHOUT any mouse movement and let the Robot go throu... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: automated and manual mode test changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/0ab5b74b..962a6176 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=02-03 Stats: 173 lines in 2 files changed: 81 ins; 47 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From honkar at openjdk.org Wed Jul 5 23:50:19 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Jul 2023 23:50:19 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v2] In-Reply-To: References: <9kgUon0hpxEI0vDSWSY5Lc_8pDr4zGb531FoSD9LmEs=.6b97857b-c3a0-481c-a4d4-dc03a21525c2@github.com> <9H6AYAPZRcQ4Za4y1wCJxaQBMa01xw3P3-VhYqqjjxw=.aecde16d-3531-4cc6-9728-89969a2a87bb@github.com> Message-ID: <6SlFQzGznzZsYT8xnm_FnJwGHcEl-nCNUf3hw_sY18E=.c0c36648-b662-4e52-948e-95db529ae858@github.com> On Mon, 3 Jul 2023 21:28:36 GMT, Alexey Ivanov wrote: >> @aivanov-jdk Yeah, I wasn't sure of open brace placement in native - some methods follow Java-style of having the open brace on the same line and few others have it on the next line. Will revert it in the next commit. > > Follow the style of the surrounding code so that added or modified lines don't stand out. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1253758021 From cushon at openjdk.org Wed Jul 5 23:51:11 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 5 Jul 2023 23:51:11 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v2] In-Reply-To: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: > Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 6355567: AdobeMarkerSegment causes failure to read valid JPEG ------------- Changes: https://git.openjdk.org/jdk/pull/14779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14779&range=01 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14779/head:pull/14779 PR: https://git.openjdk.org/jdk/pull/14779 From cushon at openjdk.org Wed Jul 5 23:51:12 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 5 Jul 2023 23:51:12 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG In-Reply-To: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Wed, 5 Jul 2023 23:19:39 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. Thanks, I have removed the test ------------- PR Comment: https://git.openjdk.org/jdk/pull/14779#issuecomment-1622691496 From honkar at openjdk.org Thu Jul 6 00:04:08 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Jul 2023 00:04:08 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > It should be tested for two cases: > > CASE 1 : Run the test as an automated test WITHOUT any mouse movement and let the Robot go throu... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: minor test changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/962a6176..2b682e7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From dnguyen at openjdk.org Thu Jul 6 05:13:07 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 6 Jul 2023 05:13:07 GMT Subject: RFR: 8166900: If you wrap a JTable in a JLayer, the cursor is moved to the last row of table by you press the page down key. [v2] In-Reply-To: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> References: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> Message-ID: On Fri, 23 Jun 2023 03:14:21 GMT, Prasanta Sadhukhan wrote: >> If a JTable is wrapped in JLayer and first row is selected and VK_PAGE_DOWN is pressed, the last row of the table is selected instead of the next row after current viewport. >> This is because table.getParent.getSize() returns the whole table size >> whereas it should be the JViewport which size should be used to calculate the "delta" to be used to scroll the table and select the row and "SwingUtilities.getUnwrappedParent(table)" gets the viewport. >> >> Tested against SwingSet2 too where it worked too. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Formatting Marked as reviewed by dnguyen (Committer). test/jdk/javax/swing/JTable/JLayerTableTest.java line 75: > 73: SwingUtilities.invokeAndWait(() -> { > 74: createUI(); > 75: }); Is it better to call "SwingUtilities.invokeAndWait(JLayerTableTest::createUI());" since there's only 1 line in the block? Tested and confirmed the changes make the test pass. ------------- PR Review: https://git.openjdk.org/jdk/pull/14614#pullrequestreview-1515761355 PR Review Comment: https://git.openjdk.org/jdk/pull/14614#discussion_r1253936488 From tr at openjdk.org Thu Jul 6 05:59:53 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 6 Jul 2023 05:59:53 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 12:46:26 GMT, Alexey Ivanov wrote: >>> > > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. >>> > >>> > >>> > Is it require to address? >>> >>> I'd rather say ?yes?. Since you're trying to improve border rendering, it's better to fix this inconsistency too. >>> >>> But to get pixel-perfect rendering, you may need to remove the scale transform. >> >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > > I admit I am confused to which part it refers. > > I re-checked your after screenshot and it looks fine to me. The shadow is followed by white highlight. There was background colour seen between these two colours in the before-fix screenshot. > > There's still a 2-pixel background colour under the highlight. Yet it is present in the before-fix too, so it looks it is designed this way for a smoother 3D shading effect. @aivanov-jdk @kumarabhi006 Is there anything else w.r.t fix and automated test ? I think have addressed your review suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1623036859 From abhiscxk at openjdk.org Thu Jul 6 06:47:59 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jul 2023 06:47:59 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v3] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 08:25:20 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Automated test added test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 112: > 110: expectedRGB = imgDate.getRGB(verticalLineCol,0); > 111: > 112: for(int i = 0; i < imgHeader.getHeight();i++) { Suggestion: for(int i = 0; i < imgHeader.getHeight(); i++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 114: > 112: for(int i = 0; i < imgHeader.getHeight();i++) { > 113: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { > 114: if(expectedRGB != imgHeader.getRGB(j,i)) { Suggestion: if (expectedRGB != imgHeader.getRGB(j, i)) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 120: > 118: } > 119: > 120: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE;i++) { Suggestion: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 122: > 120: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE;i++) { > 121: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { > 122: if(expectedRGB != imgDate.getRGB(j,i)) { Suggestion: if (expectedRGB != imgDate.getRGB(j, i)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1254002735 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1254004304 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1254005124 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1254005266 From mbaesken at openjdk.org Thu Jul 6 07:35:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Jul 2023 07:35:10 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5] In-Reply-To: References: Message-ID: <98WmwQW2HwA0y6V4kHm-Mz75WifXcX1R6eKMq-jQyjU=.b07ce857-c2d1-46cb-9dc5-0dd075ad8dd4@github.com> > There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14593/files - new: https://git.openjdk.org/jdk/pull/14593/files/3a7b057a..f29c4019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593 PR: https://git.openjdk.org/jdk/pull/14593 From mbaesken at openjdk.org Thu Jul 6 07:35:11 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Jul 2023 07:35:11 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 15:07:15 GMT, Matthias Baesken wrote: >> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust comments Hi Christoph, thanks for the review ! I added the '.' as suggested. Any objections to the latest revision? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1623132227 From dholmes at openjdk.org Thu Jul 6 07:35:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Jul 2023 07:35:12 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 09:23:05 GMT, Matthias Baesken wrote: >> test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1: >> >>> 1: /* >> >> The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something? > > It seems to start a javap. So I think it tests something, how important this is and what other tests might cover similar stuff, I do not know unfortunately . This is a trivial test for a trivial issue. javap will be tested much more thoroughly by other tests. I think this test can be deleted without any loss of coverage. Or it can just be left. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1254047816 From tr at openjdk.org Thu Jul 6 08:23:21 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 6 Jul 2023 08:23:21 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v2] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Automated test added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/9103b080..85b2dfde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=00-01 Stats: 253 lines in 2 files changed: 114 ins; 139 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From tr at openjdk.org Thu Jul 6 08:28:22 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 6 Jul 2023 08:28:22 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v4] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/d491b6c3..a3c5da4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From abhiscxk at openjdk.org Thu Jul 6 08:36:03 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jul 2023 08:36:03 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> Message-ID: On Wed, 5 Jul 2023 13:17:07 GMT, Alexey Ivanov wrote: > But it doesn't look right to me that the drop-down button is the main component of the combo box if it's non-editable. The combo box should handle the accessibility request itself in this case. It still uses the same renderer which can't be put into editable state. The renderer is never added into containment hierarchy. In case of non-editable combobox there is no editor as such and arrowButton is the main component. When native side request a11y information, accessible interface for combo button is returned (as only two accessible component are present. One is arrow button and other is popup). Subsequent accessible APIs are invoked for combo button to get accessible name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1254116370 From aivanov at openjdk.org Thu Jul 6 10:36:00 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Jul 2023 10:36:00 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> Message-ID: On Thu, 6 Jul 2023 08:32:40 GMT, Abhishek Kumar wrote: > > But it doesn't look right to me that the drop-down button is the main component of the combo box if it's non-editable. The combo box should handle the accessibility request itself in this case. It still uses the same renderer which can't be put into editable state. The renderer is never added into containment hierarchy. > > In case of non-editable combobox there is no editor as such and arrowButton is the main component. When native side request a11y information, accessible interface for combo button is returned (as only two accessible component are present. One is arrow button and other is popup). Subsequent accessible APIs are invoked for combo button to get accessible name. Do you think it is correct? I admit refactoring / rewriting accessibility implementation for `JComboBox` is out of scope in this bug. Yet the current way doesn't feel right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1254252087 From aivanov at openjdk.org Thu Jul 6 11:01:09 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Jul 2023 11:01:09 GMT Subject: RFR: 8310054: ScrollPane insets are incorrect In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 21:31:52 GMT, Sergey Bylokhov wrote: > I guess we should call "s->VerifyState();" after the "s->SetInsets(env);" similar to what we do in the "AwtScrollPane::_SetInsets" @mrserb An interesting question? You're right, I've introduced an inconsistency. Yet I don't think it matters because `SetInsets` doesn't change any members of `AwtScrollPane` object which are asserted in `VerifyState`. In addition to it, `VerifyState` is a no-op in release builds. I'll take this into account in [JDK-8310056](https://bugs.openjdk.org/browse/JDK-8310056). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14478#discussion_r1254275679 From abhiscxk at openjdk.org Thu Jul 6 11:18:02 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jul 2023 11:18:02 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> Message-ID: <_BEr15ASBn4AAaO7WkLe6vIXqOUNSDLskogaCDBvkg8=.531ed829-3bfa-4f57-9282-24808a10ffc7@github.com> On Thu, 6 Jul 2023 10:33:03 GMT, Alexey Ivanov wrote: > Do you think it is correct? > > I admit refactoring / rewriting accessibility implementation for JComboBox is out of scope in this bug. Yet the current way doesn't feel right. I think so. If I am not wrong the non-editable JComboBox doesn't have any editor, so the arrowButton width and height is equal to the combobox width and height. This results in arrowbutton rendering for entire display area of combobox. Due to this we are getting the accessible interface invoked for combobox button. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1254293156 From aivanov at openjdk.org Thu Jul 6 11:58:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Jul 2023 11:58:10 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: <_BEr15ASBn4AAaO7WkLe6vIXqOUNSDLskogaCDBvkg8=.531ed829-3bfa-4f57-9282-24808a10ffc7@github.com> References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> <_BEr15ASBn4AAaO7WkLe6vIXqOUNSDLskogaCDBvkg8=.531ed829-3bfa-4f57-9282-24808a10ffc7@github.com> Message-ID: On Thu, 6 Jul 2023 11:15:31 GMT, Abhishek Kumar wrote: >>> > But it doesn't look right to me that the drop-down button is the main component of the combo box if it's non-editable. The combo box should handle the accessibility request itself in this case. It still uses the same renderer which can't be put into editable state. The renderer is never added into containment hierarchy. >>> >>> In case of non-editable combobox there is no editor as such and arrowButton is the main component. When native side request a11y information, accessible interface for combo button is returned (as only two accessible component are present. One is arrow button and other is popup). Subsequent accessible APIs are invoked for combo button to get accessible name. >> >> Do you think it is correct? >> >> I admit refactoring / rewriting accessibility implementation for `JComboBox` is out of scope in this bug. Yet the current way doesn't feel right. > >> Do you think it is correct? >> >> I admit refactoring / rewriting accessibility implementation for JComboBox is out of scope in this bug. Yet the current way doesn't feel right. > > I think so. > If I am not wrong the non-editable JComboBox doesn't have any editor, so the arrowButton width and height is equal to the combobox width and height. This results in arrowbutton rendering for entire display area of combobox. Due to this we are getting the accessible interface invoked for combobox button. Yes, non-editable combo box doesn't have the editor. Yet the arrowButton is not what displays the text. It is for this reason that I think it is wrong that the button becomes the main component which handles accessibility for combo box if it's not editable. It is not the button that displays the text. Setting accessible name in `doRendererPaint` doesn't feel right either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1254331218 From aivanov at openjdk.org Thu Jul 6 20:11:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Jul 2023 20:11:57 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 18:39:47 GMT, Alexey Ivanov wrote: > > Having said that, I guess XP theme also padding is not correct as can be seen in this bug [JDK-8139392](https://bugs.openjdk.org/browse/JDK-8139392) which I have rectified > > > > After fix > > ![image](https://user-images.githubusercontent.com/43534309/248217142-224f098c-5ff5-4713-8434-05d99e7d9a71.png) > > Your latest changes also fix [JDK-8139392](https://bugs.openjdk.org/browse/JDK-8139392), do I get it right? If so, add it to the list of fixed issues. This change does not address JDK-8139392 fully. The title bar buttons in Vista theme, which are still used for MDI windows, are not square. The dimensions of the native buttons are 32?18. The dimensions of the JInternalFrame title bar buttons after your fix are 24?18; before your fix they were 28?18. That is the width of the buttons is smaller by 8 and 4 pixels. Aren't these the values subtracted from the width value fetched from Windows? As for the classic theme? It's not available in Windows anymore, there's only Visual-style enabled theme now. So, you can't get the dimensions of the title bar buttons of an MDI window. I guess the only way is to use heuristics. According to old screenshots I have, the main title bar buttons in Windows 98 were 16?14 and in Windows 2000 the dimensions were 17?15. That is the buttons were not square, the width was 2 pixels greater than the height. The dimensions of the buttons in the Windows classic theme after your fix are 20?18. The buttons are still larger than they were (the height comes from the visual-style theme) but proportions are correct. Before the fix, the dimensions were 34?18 ? the buttons were even wider than in the visual-style enabled theme. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1624248716 From duke at openjdk.org Thu Jul 6 23:35:09 2023 From: duke at openjdk.org (duke) Date: Thu, 6 Jul 2023 23:35:09 GMT Subject: Withdrawn: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From jiangli at openjdk.org Fri Jul 7 00:50:04 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 7 Jul 2023 00:50:04 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c Message-ID: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. ------------- Commit messages: - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c Changes: https://git.openjdk.org/jdk/pull/14794/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14794&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311606 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14794.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14794/head:pull/14794 PR: https://git.openjdk.org/jdk/pull/14794 From jwaters at openjdk.org Fri Jul 7 02:29:24 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 7 Jul 2023 02:29:24 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 Message-ID: Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code ------------- Commit messages: - Explain why is needed - Cleanup awt_Win32GraphicsDevice.cpp - ThemeReader.cpp: Likewise - awt_Window.cpp: Likewise - awt_PrintJob.cpp: Likewise - awt_PrintControl.cpp: Likewise with as well - awt_Font.cpp: Likewise - awt_DesktopProperties.cpp: Likewise - awt_Component.cpp: Likewise - GDIRenderer.cpp: Likewise - ... and 6 more: https://git.openjdk.org/jdk/compare/27de536b...88e899f4 Changes: https://git.openjdk.org/jdk/pull/14795/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14795&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311380 Stats: 79 lines in 14 files changed: 17 ins; 30 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/14795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14795/head:pull/14795 PR: https://git.openjdk.org/jdk/pull/14795 From psadhukhan at openjdk.org Fri Jul 7 02:59:12 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 02:59:12 GMT Subject: Integrated: 6875229: Wrong placement of icons in JTabbedPane in Nimbus In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan wrote: > Icon is placed after text in JTabbedPane for NimbusL&F since the text is drawn at LEADING position instead of TRAILING as is done for [other L&F](https://github.com/openjdk/jdk/blob/59c6c0e1b7148a7139f5e6a4ba2b19623c20c77d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L1155-L1160) > > Before fix > ![image](https://github.com/openjdk/jdk/assets/43534309/10d3f919-46e0-47e9-9d27-b33e49b2d62c) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/0c4906ec-df2a-4ce6-8399-fd1cd9e34450) This pull request has now been integrated. Changeset: 6485b7d0 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/6485b7d0d3dcbf9c33219feb03a7744a80feb669 Stats: 128 lines in 2 files changed: 126 ins; 0 del; 2 mod 6875229: Wrong placement of icons in JTabbedPane in Nimbus Reviewed-by: honkar, abhiscxk, dnguyen, jdv ------------- PR: https://git.openjdk.org/jdk/pull/14596 From psadhukhan at openjdk.org Fri Jul 7 04:01:57 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 04:01:57 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 20:08:37 GMT, Alexey Ivanov wrote: > > > Having said that, I guess XP theme also padding is not correct as can be seen in this bug [JDK-8139392](https://bugs.openjdk.org/browse/JDK-8139392) which I have rectified > > > After fix > > > ![image](https://user-images.githubusercontent.com/43534309/248217142-224f098c-5ff5-4713-8434-05d99e7d9a71.png) > > > > > > Your latest changes also fix [JDK-8139392](https://bugs.openjdk.org/browse/JDK-8139392), do I get it right? If so, add it to the list of fixed issues. > > This change does not address JDK-8139392 fully. The title bar buttons in Vista theme, which are still used for MDI windows, are not square. The dimensions of the native buttons are 32?18. The dimensions of the JInternalFrame title bar buttons after your fix are 24?18; before your fix they were 28?18. That is the width of the buttons is smaller by 8 and 4 pixels. Aren't these the values subtracted from the width value fetched from Windows? > Adjusted to native button dimensions of 32x18 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1624647368 From psadhukhan at openjdk.org Fri Jul 7 04:01:56 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 04:01:56 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v7] In-Reply-To: References: Message-ID: > Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. > > Before fix SwingSet2 demo (Windows Classic InternalFrame) > ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Adjust width for Windows Vista theme to 32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14555/files - new: https://git.openjdk.org/jdk/pull/14555/files/0d030f3e..b7ca6c51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14555/head:pull/14555 PR: https://git.openjdk.org/jdk/pull/14555 From mbaesken at openjdk.org Fri Jul 7 07:00:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 7 Jul 2023 07:00:05 GMT Subject: Integrated: JDK-8310550: Adjust references to rt.jar In-Reply-To: References: Message-ID: <5z7tycp2SolizjphgpOZ9dewDyUSx4kL-Ad-D9_fKZE=.0f5bda5f-2d9c-41cf-b6cd-dd4ee866aaf9@github.com> On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken wrote: > There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted. This pull request has now been integrated. Changeset: 25cbe85d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/25cbe85d6f46bed82c7f1266ce52c86943e29d60 Stats: 17 lines in 12 files changed: 0 ins; 8 del; 9 mod 8310550: Adjust references to rt.jar Reviewed-by: erikj, clanger ------------- PR: https://git.openjdk.org/jdk/pull/14593 From aivanov at openjdk.org Fri Jul 7 19:25:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Jul 2023 19:25:56 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4] In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 03:57:17 GMT, Prasanta Sadhukhan wrote: > > This change does not address JDK-8139392 fully. The title bar buttons in Vista theme, which are still used for MDI windows, are not square. The dimensions of the native buttons are 32?18. The dimensions of the JInternalFrame title bar buttons after your fix are 24?18; before your fix they were 28?18. That is the width of the buttons is smaller by 8 and 4 pixels. Aren't these the values subtracted from the width value fetched from Windows? > > Adjusted to native button dimensions of 32x18 It looks good now. In scale of 150%, the bottom and right borders of the internal frame buttons disappear and re-appear as you drag an internal frame. But it's a completely different story. At scale of 100% or 200%, the buttons look as they should. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1625948961 From aivanov at openjdk.org Fri Jul 7 20:01:01 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Jul 2023 20:01:01 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v7] In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 04:01:56 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Adjust width for Windows Vista theme to 32 **`WindowsIconFactory.java`** Could you also remove `Dimension` import? It's unused. Could you please add `final` modifier to the `part` field in `FrameButtonIcon` (line 178)? **`WindowsInternalFrameTitlePane.java`** Could you please organise imports? This will expand all the wildcard imports. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 292: > 290: // ratio from the uxtheme part > 291: width = UIManager.getInt("InternalFrame.titleButtonHeight") -2; > 292: Dimension d = XPStyle.getPartSize(Part.WP_CLOSEBUTTON, State.NORMAL); The part should've been `Part.WP_MDICLOSEBUTTON`. Yet the returned size is wrong either way. On my Windows 11 system, the dimensions are 14?9 and 3?5 for `WP_CLOSEBUTTON` and `WP_MDICLOSEBUTTON`. Either is far from the real values. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 83: > 81: } else { > 82: buttonWidth = buttonHeight; > 83: buttonWidth += 2; Suggestion: buttonWidth = buttonHeight + 2; src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 88: > 86: setBorder(BorderFactory.createLineBorder(activeBorderColor, 1)); > 87: } > 88: UIManager.put("InternalFrame.titleButtonWidth", buttonWidth); > The only concern is that UI Manager has a wrong width until `JInternalFrame` is shown or initialised. But it has been the case before the fix too. I was probably wrong in making you save the width into the `UIManager`. First of all, it creates an inconsistency between the width and the height. We don't use the value of height (`InternalFrame.titleButtonHeight`) either, we use the adjusted value only; neither do we store it back ? it will break our calculations. For the sake of backward compatibility, *we shouldn't update `InternalFrame.titleButtonWidth`.* test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 58: > 56: } > 57: UIManager.setLookAndFeel( > 58: "com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel"); Shall `WindowsLookAndFeel` be tested as well? test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 103: > 101: Icon icon = ((JButton) c).getIcon(); > 102: if (icon.getIconHeight() > height - 4 > 103: || icon.getIconWidth() > height - 2) { Should we make the test stricter? According to the code, `width = height + 2` for the classic theme and `width = height + 14` for visual styles. In both cases, `height = UIManager.getInt("InternalFrame.titleButtonHeight") - 4`. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1519648245 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1256352193 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1256355797 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1256375584 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1256376314 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1256381116 From aivanov at openjdk.org Fri Jul 7 20:24:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Jul 2023 20:24:56 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v7] In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 04:01:56 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Adjust width for Windows Vista theme to 32 The values in `UIManager` ? `InternalFrame.titleButtonWidth` and `InternalFrame.titleButtonHeight` ? come from Windows desktop properties, which are gotten from [`SystemParametersInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) called with `SPI_GETNONCLIENTMETRICS`, they are `iCaptionWidth` and `iCaptionHeight` members of the [`NONCLIENTMETRICS`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-nonclientmetricsw) structure. https://github.com/openjdk/jdk/blob/292ee630ae32c3b50363b10ffa6090e57ffef1e8/src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp#L299-L300 Interestingly, the returned values are 32?22 which don't match the width and height of any buttons. They may be correct for the Windows classic theme if it could be enabled. I wonder if [`GetSystemMetrics`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics) with `SM_CXSIZE` and `SM_CYSIZE` gives the correct result. Yet it may be too late to change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1626033157 From cushon at openjdk.org Fri Jul 7 23:27:00 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 7 Jul 2023 23:27:00 GMT Subject: RFR: 8311666: Disabled tests in test/jdk/sun/java2d/marlin Message-ID: Please review this fix for JDK-8311666, which adds missing jtreg `/* @test */` comments to several tests in `test/jdk/sun/java2d/marlin` which were not being run. ------------- Commit messages: - 8311666: Disabled tests in test/jdk/sun/java2d/marlin Changes: https://git.openjdk.org/jdk/pull/14807/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311666 Stats: 18 lines in 3 files changed: 17 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14807/head:pull/14807 PR: https://git.openjdk.org/jdk/pull/14807 From prr at openjdk.org Fri Jul 7 23:39:53 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 7 Jul 2023 23:39:53 GMT Subject: RFR: 8311666: Disabled tests in test/jdk/sun/java2d/marlin In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 23:20:05 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-8311666, which adds missing jtreg `/* @test */` comments to several tests in `test/jdk/sun/java2d/marlin` which were not being run. Hmm. Puzzling. These tests seem to have been like this since (at least) JDK8u days. I don't understand how they managed to be updated several times over the years without anyone addressing this. I hope I'm not missing something but they have no comment to explain it. And they do pass for me on current JDK. But best to push this on Monday not Friday in case there is a surprise. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14807#pullrequestreview-1520309930 From cushon at openjdk.org Sat Jul 8 00:25:54 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 8 Jul 2023 00:25:54 GMT Subject: RFR: 8311666: Disabled tests in test/jdk/sun/java2d/marlin In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 23:20:05 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-8311666, which adds missing jtreg `/* @test */` comments to several tests in `test/jdk/sun/java2d/marlin` which were not being run. Thanks for taking a look! > Hmm. Puzzling. These tests seem to have been like this since (at least) JDK8u days. I don't understand how they managed to be updated several times over the years without anyone addressing this. I hope I'm not missing something but they have no comment to explain it. And they do pass for me on current JDK. But best to push this on Monday not Friday in case there is a surprise. I think that matches my understanding, that it was an oversight when they were originally contributed, and then it went unnoticed and unfixed since then. Submitting earlier in the week sounds good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14807#issuecomment-1626385193 From lbourges at openjdk.org Sat Jul 8 09:11:54 2023 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 8 Jul 2023 09:11:54 GMT Subject: RFR: 8311666: Disabled tests in test/jdk/sun/java2d/marlin In-Reply-To: References: Message-ID: <70ymaYuCoaBH2M5Ubn7QLfQl3RVQ196BEJlJC03kKTE=.d67eca66-72f8-4f5a-874b-cef97501ccd6@github.com> On Fri, 7 Jul 2023 23:20:05 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-8311666, which adds missing jtreg `/* @test */` comments to several tests in `test/jdk/sun/java2d/marlin` which were not being run. The test dates are from 2010 for pisces, moved into marlin tests once pisces was removed in 2017. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/14807#issuecomment-1626952413 From alanb at openjdk.org Mon Jul 10 05:33:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Jul 2023 05:33:12 GMT Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 09:57:04 GMT, Matthias Baesken wrote: > Hi Alan, I adjusted the comment in DriverManager.java . Thanks, the update looks okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1257728322 From psadhukhan at openjdk.org Mon Jul 10 09:49:21 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 09:49:21 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v8] In-Reply-To: References: Message-ID: > Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. > > Before fix SwingSet2 demo (Windows Classic InternalFrame) > ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) 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/14555/files - new: https://git.openjdk.org/jdk/pull/14555/files/b7ca6c51..ec2c9abc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=06-07 Stats: 62 lines in 3 files changed: 41 ins; 6 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/14555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14555/head:pull/14555 PR: https://git.openjdk.org/jdk/pull/14555 From aivanov at openjdk.org Mon Jul 10 16:07:20 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Jul 2023 16:07:20 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v8] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 09:49:21 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comments In general, looks good except for the couple of comments. I also think the test can be simplified, more on this below. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 59: > 57: import javax.swing.UIManager; > 58: import javax.swing.plaf.basic.BasicInternalFrameTitlePane; > 59: import javax.swing.plaf.UIResource; I got a different list of imports: see [commit 389cd03](https://github.com/aivanov-jdk/jdk/commit/389cd03c5630e41bc20c60579d6a339590d36fbc). The list of imports should be sorted, but it's not sorted here. The imports from `java.beans` should be after `java.awt` rather inside `javax` packages. In OpenJDK, we decided to put internal packages below public packages, so `SwingUtilities2` goes below `javax.*` packages. There's still wildcard import: `TMSchema.*`. The [complete sorted list of imports](https://github.com/aivanov-jdk/jdk/blob/389cd03c5630e41bc20c60579d6a339590d36fbc/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L28-L68) as produced by *Optimize Imports* command in IDEA. test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 105: > 103: BasicInternalFrameTitlePane title = > 104: ((BasicInternalFrameTitlePane)((BasicInternalFrameUI) > 105: iframe.getUI()).getNorthPane()); You don't use the `BasicInternalFrameTitlePane` type, the cast can be removed. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1522410250 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1258473594 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1258474781 From cushon at openjdk.org Mon Jul 10 16:16:33 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 10 Jul 2023 16:16:33 GMT Subject: Integrated: 8311666: Disabled tests in test/jdk/sun/java2d/marlin In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 23:20:05 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-8311666, which adds missing jtreg `/* @test */` comments to several tests in `test/jdk/sun/java2d/marlin` which were not being run. This pull request has now been integrated. Changeset: b285ed72 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/b285ed72aebe2d802fa9c071372cea6c09870b9a Stats: 18 lines in 3 files changed: 17 ins; 1 del; 0 mod 8311666: Disabled tests in test/jdk/sun/java2d/marlin Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/14807 From aivanov at openjdk.org Mon Jul 10 16:22:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Jul 2023 16:22:10 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v8] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 09:49:21 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comments May I suggest a simplified version of the test [`InternalFrameTitleButtonTest.java`](https://github.com/aivanov-jdk/jdk/blob/6decd8ae82ed95f0c4bda9089d1e05eb084567b9/test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java)? Its `test` method is shorter; I moved the condition to its own method `testButtonSize` where an internal frame title button is passed as well as an offset for width that is different for classic and visual-style-enabled L&F. This also avoids checking which L&F is selected. Here's [the diff](https://github.com/aivanov-jdk/jdk/compare/ec2c9ab..6decd8a#diff-f941d2d497179f4da7530480b24522ccd05da02ca24c6e3fa55824d4199529e1) on top of your latest update. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1629282273 From jiangli at openjdk.org Mon Jul 10 16:25:51 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 16:25:51 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v2] In-Reply-To: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: > Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. Jiangli Zhou 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8311606 - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14794/files - new: https://git.openjdk.org/jdk/pull/14794/files/c00d6177..9729ddca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14794&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14794&range=00-01 Stats: 3310 lines in 91 files changed: 1598 ins; 1259 del; 453 mod Patch: https://git.openjdk.org/jdk/pull/14794.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14794/head:pull/14794 PR: https://git.openjdk.org/jdk/pull/14794 From aivanov at openjdk.org Mon Jul 10 17:34:22 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Jul 2023 17:34:22 GMT Subject: RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane Message-ID: It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace **Fix** The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb Client tests are green. ------------- Commit messages: - Remove debug prints - 8311689: Wrong visible amount in Adjustable of ScrollPane Changes: https://git.openjdk.org/jdk/pull/14815/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311689 Stats: 95 lines in 2 files changed: 93 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14815.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14815/head:pull/14815 PR: https://git.openjdk.org/jdk/pull/14815 From jiangli at openjdk.org Mon Jul 10 17:44:11 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 17:44:11 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v2] In-Reply-To: References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: On Mon, 10 Jul 2023 16:25:51 GMT, Jiangli Zhou wrote: >> Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. > > Jiangli Zhou 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8311606 > - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c Ping, please help review this simple change. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14794#issuecomment-1629423147 From serb at openjdk.org Mon Jul 10 19:17:06 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 10 Jul 2023 19:17:06 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v2] In-Reply-To: References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: On Mon, 10 Jul 2023 16:25:51 GMT, Jiangli Zhou wrote: >> Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. > > Jiangli Zhou 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8311606 > - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14794#pullrequestreview-1522759153 From aivanov at openjdk.org Mon Jul 10 19:27:35 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Jul 2023 19:27:35 GMT Subject: RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane [v2] In-Reply-To: References: Message-ID: > It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. > > https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 > > After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. > > I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace > > **Fix** > > The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. > > I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb > > Client tests are green. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Add Robot.waitForIdle It ensures getViewportSize in the test is called after AwtScrollPane::_SetSpans completes on the toolkit thread. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14815/files - new: https://git.openjdk.org/jdk/pull/14815/files/f9e59211..f40921ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14815&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14815&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14815.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14815/head:pull/14815 PR: https://git.openjdk.org/jdk/pull/14815 From kizune at openjdk.org Mon Jul 10 20:10:14 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 10 Jul 2023 20:10:14 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 00:04:08 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test is run in 2 modes - as automated and manual test. >> >> CASE 1 :... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > minor test changes Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14744#pullrequestreview-1522951141 From aivanov at openjdk.org Mon Jul 10 20:29:13 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Jul 2023 20:29:13 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 00:04:08 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> The issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test is run in 2 modes - as automated and manual test. >> >> CASE 1 :... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > minor test changes I admit I don't understand the Objective-C code, yet it couple of points caught my attention. I mostly looked at the test as I did the previous time. src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 313: > 311: if (keyPressed) { > 312: initFlags ^= flagMaskValue; > 313: } Suggestion: if (keyPressed) { initFlags ^= flagMaskValue; } Shouldn't it get indented? src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 322: > 320: > 321: CGEventFlags flags = CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState); > 322: flags = (initFlags & allModifiersMask) | (flags & (!allModifiersMask)); Should `!allModifiersMask` be `~allModifiersMask`? That is _bitwise_ NOT instead of _logical_ NOT. Suggestion: flags = (initFlags & allModifiersMask) | (flags & (!allModifiersMask)); test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 78: > 76: move the mouse (without clicking/dragging). > 77: When ready click on the "Start" button to run the test. > 78: """; And start moving the mouse? test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 102: > 100: throw new RuntimeException("Test instruction frame closed"); > 101: } > 102: } Instead of busy-waiting, you can use `CountDownLatch` to start the test. You should also release the latch if the instruction frame is closed. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 237: > 235: jFrame.getContentPane().add(jButton, BorderLayout.PAGE_END); > 236: > 237: jFrame.setSize(560,200); Suggestion: jFrame.setSize(560, 200); test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 250: > 248: jFrame.getContentPane().add(pane, BorderLayout.CENTER); > 249: > 250: jFrame.setSize(450,100); Suggestion: jFrame.setSize(450, 100); test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 261: > 259: boolean condition = expectedResult.equals(EXPECTED_RESULT_CTRL) > 260: ? (jTextArea.getCaretPosition() > 261: != Integer.parseInt(EXPECTED_RESULT_CTRL)) You pass different expected result strings but here you always compare `expectedResult` to `EXPECTED_RESULT_CTRL`. Is it intentional? Do I miss anything? I haven't run the test. ------------- PR Review: https://git.openjdk.org/jdk/pull/14744#pullrequestreview-1522945218 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258848971 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258864126 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258876531 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258875171 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258877726 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258877487 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258879793 From jiangli at openjdk.org Mon Jul 10 20:30:54 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 20:30:54 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v2] In-Reply-To: References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: <_JZ7z-07i1XCaBYe8jeiFkwMn18w1nT-L1n58bfrVpQ=.5026e83b-a22a-44be-9199-798b16af37d6@github.com> On Mon, 10 Jul 2023 19:13:54 GMT, Sergey Bylokhov wrote: >> Jiangli Zhou 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 two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8311606 >> - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c > > Marked as reviewed by serb (Reviewer). Thanks for the review, @mrserb. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14794#issuecomment-1629684973 From prr at openjdk.org Mon Jul 10 20:36:57 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 20:36:57 GMT Subject: RFR: 8311247: Some cpp files are compiled with -std:c11 flag In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeli?ski wrote: > Please review this patch that configures C++ arguments on build jobs that involve compiling CPP files. As a result of this change, CPP files are compiled with `-std:c++14` command line argument instead of `-std:c11`, which is used when C++ arguments are not configured. > While at it, I simplified the `java.security.jgss/Lib.gmk` file by moving the additional include directory to `EXTRA_HEADER_DIRS`. > > This patch fixes the following clang warning: > > warning: argument unused during compilation: '-std:c11' > > > Microsoft states that [std:c++14 is the default](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170), so there shouldn't be any differences in produced code. > > Testing: > - verified that after the changes, all CPP files are compiled with `std:c++14` instead of `-std:c11` > - spot-checked a few `cmdline` files that changed after this patch was applied; the `-std` change was the only difference > - tier1-5 builds, tier1-2 tests and client libs tests continue to pass on Windows, Linux & MacOS. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14758#pullrequestreview-1523000377 From jiangli at openjdk.org Mon Jul 10 20:40:45 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 20:40:45 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v3] In-Reply-To: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: > Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. Jiangli Zhou 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8311606 - Merge branch 'master' into JDK-8311606 - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14794/files - new: https://git.openjdk.org/jdk/pull/14794/files/9729ddca..0b8a1e9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14794&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14794&range=01-02 Stats: 64 lines in 6 files changed: 16 ins; 16 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/14794.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14794/head:pull/14794 PR: https://git.openjdk.org/jdk/pull/14794 From prr at openjdk.org Mon Jul 10 20:44:56 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 20:44:56 GMT Subject: RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 19:27:35 GMT, Alexey Ivanov wrote: >> It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. >> >> https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 >> >> After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. >> >> I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace >> >> **Fix** >> >> The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. >> >> I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb >> >> Client tests are green. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Add Robot.waitForIdle > > It ensures getViewportSize in the test is called > after AwtScrollPane::_SetSpans completes on the > toolkit thread. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14815#pullrequestreview-1523010261 From prr at openjdk.org Mon Jul 10 20:58:03 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 20:58:03 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v2] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Wed, 5 Jul 2023 23:51:11 GMT, Liam Miller-Cushon wrote: >> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 6355567: AdobeMarkerSegment causes failure to read valid JPEG lgtm. I'd like @jayathirthrao to be 2nd reviewer. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14779#pullrequestreview-1523028392 From honkar at openjdk.org Mon Jul 10 21:00:56 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 10 Jul 2023 21:00:56 GMT Subject: RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 19:27:35 GMT, Alexey Ivanov wrote: >> It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. >> >> https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 >> >> After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. >> >> I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace >> >> **Fix** >> >> The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. >> >> I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb >> >> Client tests are green. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Add Robot.waitForIdle > > It ensures getViewportSize in the test is called > after AwtScrollPane::_SetSpans completes on the > toolkit thread. Tested locally by applying the patch. Fix looks good. ------------- Marked as reviewed by honkar (Committer). PR Review: https://git.openjdk.org/jdk/pull/14815#pullrequestreview-1523036070 From honkar at openjdk.org Mon Jul 10 21:13:15 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 10 Jul 2023 21:13:15 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 20:12:25 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> minor test changes > > src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 322: > >> 320: >> 321: CGEventFlags flags = CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState); >> 322: flags = (initFlags & allModifiersMask) | (flags & (!allModifiersMask)); > > Should `!allModifiersMask` be `~allModifiersMask`? That is _bitwise_ NOT instead of _logical_ NOT. > > Suggestion: > > flags = (initFlags & allModifiersMask) | (flags & (!allModifiersMask)); @aivanov-jdk That is correct, Thanks for catching it. It should be `~`. > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 261: > >> 259: boolean condition = expectedResult.equals(EXPECTED_RESULT_CTRL) >> 260: ? (jTextArea.getCaretPosition() >> 261: != Integer.parseInt(EXPECTED_RESULT_CTRL)) > > You pass different expected result strings but here you always compare `expectedResult` to `EXPECTED_RESULT_CTRL`. Is it intentional? Do I miss anything? > > I haven't run the test. The assertion for CTRL key is different for the rest and involves caret position comparison instead of expected strings (as in other cases), hence I have used `EXPECTED_RESULT_CTRL` to differentiate the cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258918909 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258918223 From prr at openjdk.org Mon Jul 10 21:29:12 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 21:29:12 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v3] In-Reply-To: References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: On Mon, 10 Jul 2023 20:40:45 GMT, Jiangli Zhou wrote: >> Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. > > Jiangli Zhou 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311606 > - Merge branch 'master' into JDK-8311606 > - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c I'm reading the bug report and I want to understand this better. Why is this function in particular a problem ? What is special about it vs many others ? You wrote "when statically linking with JDK." Which would mean statically linking this code (in the JDK) with another JDK ? What exactly is this scenario. And you say 'potential problem'. Have you seen an 'actual problem' ? You hint at 'a certain jpeg library'. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14794#issuecomment-1629754021 From duke at openjdk.org Mon Jul 10 21:51:24 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 10 Jul 2023 21:51:24 GMT Subject: Integrated: 8304503: Modernize debugging jvm args in demo netbeans projects In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com> References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com> Message-ID: On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos wrote: > Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. > > The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging: > > > > > > > > > They should instead just do: > > > > > > Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout. > > `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/` This pull request has now been integrated. Changeset: 940a4e12 Author: Eirik Bjorsnos Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/940a4e12d1b304fb841f5bcdbd2b62fac692f3b1 Stats: 42 lines in 14 files changed: 0 ins; 21 del; 21 mod 8304503: Modernize debugging jvm args in demo netbeans projects Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13101 From prr at openjdk.org Mon Jul 10 22:32:02 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 22:32:02 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute In-Reply-To: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Fri, 30 Jun 2023 10:00:46 GMT, Alexander Scherbatiy wrote: > To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: > > java JavaSidesAttributePrinting ONE_SIDED > java JavaSidesAttributePrinting DUPLEX > > > The sample calls PrinterJob print method with the given sides attribute. > The pages are printed according to the printer default settings not according to the provided Sides attributes. > > The fix propagates Sides attribute > - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method > - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method 1) The test doesn't seem to check whether the printer actually supports two-sided printing (!) You need to see if the value you use is supported else skip it 2) The test text is so similar .. and the user clearly is expected to "know" what "TWO_SIDED_LONG_EDGE" means. I think you need to add a window that explains that "up to" THREE tests will run and it will test all the cases supported by the printer and you need to add words explaining each case 3) SHORT_EDGE doesn't seem to work for me. Hmm not working from Safari either so that can't be JDK code's problem ------------- PR Comment: https://git.openjdk.org/jdk/pull/14727#issuecomment-1629816695 From prr at openjdk.org Mon Jul 10 22:41:16 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 10 Jul 2023 22:41:16 GMT Subject: RFR: 8166900: If you wrap a JTable in a JLayer, the cursor is moved to the last row of table by you press the page down key. [v2] In-Reply-To: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> References: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> Message-ID: <4QsylCUkX5DOWYH04uo4jfvytTTpjJKHRzDbLg5c1FA=.b7335657-6b0d-4b8b-a0d1-edca3f60a89f@github.com> On Fri, 23 Jun 2023 03:14:21 GMT, Prasanta Sadhukhan wrote: >> If a JTable is wrapped in JLayer and first row is selected and VK_PAGE_DOWN is pressed, the last row of the table is selected instead of the next row after current viewport. >> This is because table.getParent.getSize() returns the whole table size >> whereas it should be the JViewport which size should be used to calculate the "delta" to be used to scroll the table and select the row and "SwingUtilities.getUnwrappedParent(table)" gets the viewport. >> >> Tested against SwingSet2 too where it worked too. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Formatting Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14614#pullrequestreview-1523137964 From serb at openjdk.org Mon Jul 10 23:14:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 10 Jul 2023 23:14:12 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 00:04:08 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test runs in 2 modes - as automated and manual test. >> >> CASE 1 : ... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > minor test changes src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 135: > 133: if ((initFlags & kCGEventFlagMaskSecondaryFn) != 0) { > 134: initFlags ^= kCGEventFlagMaskSecondaryFn; > 135: } Can you please double check how the lines below affected the usecase you fix, especially: > CGEnableEventStateCombining - Pass true to specify that the actual key and mouse state are merged with the application-specified state in a synthetic event; otherwise, pass false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1258996129 From jiangli at openjdk.org Tue Jul 11 00:05:14 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 00:05:14 GMT Subject: RFR: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c [v3] In-Reply-To: References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: On Mon, 10 Jul 2023 21:26:21 GMT, Phil Race wrote: >> Jiangli Zhou 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 three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8311606 >> - Merge branch 'master' into JDK-8311606 >> - JDK-8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c > > I'm reading the bug report and I want to understand this better. > > Why is this function in particular a problem ? What is special about it vs many others ? > > You wrote "when statically linking with JDK." > > Which would mean statically linking this code (in the JDK) with another JDK ? What exactly is this scenario. > > And you say 'potential problem'. Have you seen an 'actual problem' ? You hint at 'a certain jpeg library'. @prrace thanks for looking into this issue. > I'm reading the bug report and I want to understand this better. > > Why is this function in particular a problem ? What is special about it vs many others ? > > You wrote "when statically linking with JDK." > > Which would mean statically linking this code (in the JDK) with another JDK ? What exactly is this scenario. The linking failure due to duplicate `read_icc_profile` symbol occur when statically linking the Java launcher executable with JDK `libjavajpeg.a` and user library code together. Only one version of the JDK/hotspot static libraries are linked with. No multiple JDK are linked together. > > And you say 'potential problem'. Have you seen an 'actual problem' ? You hint at 'a certain jpeg library'. I found a public reference to the code that I was referring to: https://github.com/mm2/Little-CMS/blob/master/utils/jpgicc/iccjpeg.c#L165 When testing JDK static linking capability, we ran into the linking failure with a test case: ld: error: duplicate symbol: read_icc_profile >>> defined at imageioJPEG.c:1295 (/tmp/jdkbuild/srcs/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c:1295) >>> libjavajpeg_relocatable.o:(read_icc_profile) in archive third_party/java/jdk/jdk11-k8/lib_static/libjavajpeg.a >>> defined at iccjpeg.c >>> .../iccjpeg.o:(.text+0x0) clang: error: linker command failed with exit code 1 (use -v to see invocation) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14794#issuecomment-1629895714 From serb at openjdk.org Tue Jul 11 00:08:06 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 00:08:06 GMT Subject: RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane [v2] In-Reply-To: References: Message-ID: <8N8z7s8zs93yIwu87qAe0hRjDr6vHJlba2FQhEgiF0U=.fef7bdd2-ebd9-4bf2-8d4f-a87f401dc84f@github.com> On Mon, 10 Jul 2023 19:27:35 GMT, Alexey Ivanov wrote: >> It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. >> >> https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 >> >> After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. >> >> I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace >> >> **Fix** >> >> The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. >> >> I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb >> >> Client tests are green. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Add Robot.waitForIdle > > It ensures getViewportSize in the test is called > after AwtScrollPane::_SetSpans completes on the > toolkit thread. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14815#pullrequestreview-1523200649 From serb at openjdk.org Tue Jul 11 00:22:54 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 00:22:54 GMT Subject: RFR: 8166900: If you wrap a JTable in a JLayer, the cursor is moved to the last row of table by you press the page down key. [v2] In-Reply-To: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> References: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com> Message-ID: On Fri, 23 Jun 2023 03:14:21 GMT, Prasanta Sadhukhan wrote: >> If a JTable is wrapped in JLayer and first row is selected and VK_PAGE_DOWN is pressed, the last row of the table is selected instead of the next row after current viewport. >> This is because table.getParent.getSize() returns the whole table size >> whereas it should be the JViewport which size should be used to calculate the "delta" to be used to scroll the table and select the row and "SwingUtilities.getUnwrappedParent(table)" gets the viewport. >> >> Tested against SwingSet2 too where it worked too. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Formatting Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14614#pullrequestreview-1523212573 From jwaters at openjdk.org Tue Jul 11 01:30:21 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 11 Jul 2023 01:30:21 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 01:56:31 GMT, Julian Waters wrote: > Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/14795#issuecomment-1629955860 From serb at openjdk.org Tue Jul 11 02:12:52 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 02:12:52 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 01:56:31 GMT, Julian Waters wrote: > move a few standard library headers to the top so macro definitions don't break them Just to double check, do we have such macro definitions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14795#issuecomment-1629993765 From jwaters at openjdk.org Tue Jul 11 02:18:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 11 Jul 2023 02:18:01 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 01:56:31 GMT, Julian Waters wrote: > Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code We include windows.h in a vast amount of source files, which defines min and max utilities. This breaks the min max declarations from the standard library cmath header. -DNOMINMAX is not possible because a lot of code does actually use the min and max macros ------------- PR Comment: https://git.openjdk.org/jdk/pull/14795#issuecomment-1629997387 From serb at openjdk.org Tue Jul 11 02:18:14 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 02:18:14 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v2] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Wed, 5 Jul 2023 23:51:11 GMT, Liam Miller-Cushon wrote: >> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 6355567: AdobeMarkerSegment causes failure to read valid JPEG Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14779#pullrequestreview-1523296132 From psadhukhan at openjdk.org Tue Jul 11 03:21:16 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Jul 2023 03:21:16 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v9] In-Reply-To: References: Message-ID: > Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. > > Before fix SwingSet2 demo (Windows Classic InternalFrame) > ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) 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/14555/files - new: https://git.openjdk.org/jdk/pull/14555/files/ec2c9abc..308b04bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=07-08 Stats: 68 lines in 2 files changed: 25 ins; 27 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/14555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14555/head:pull/14555 PR: https://git.openjdk.org/jdk/pull/14555 From psadhukhan at openjdk.org Tue Jul 11 03:21:17 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Jul 2023 03:21:17 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v8] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:19:30 GMT, Alexey Ivanov wrote: > May I suggest a simplified version of the test [`InternalFrameTitleButtonTest.java`](https://github.com/aivanov-jdk/jdk/blob/6decd8ae82ed95f0c4bda9089d1e05eb084567b9/test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java)? > > Its `test` method is shorter; I moved the condition to its own method `testButtonSize` where an internal frame title button is passed as well as an offset for width that is different for classic and visual-style-enabled L&F. This also avoids checking which L&F is selected. > > Here's [the diff](https://github.com/aivanov-jdk/jdk/compare/ec2c9ab..6decd8a#diff-f941d2d497179f4da7530480b24522ccd05da02ca24c6e3fa55824d4199529e1) on top of your latest update. > > What do you think? OK. updated to your version..seems precise..thanks... > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 59: > >> 57: import javax.swing.UIManager; >> 58: import javax.swing.plaf.basic.BasicInternalFrameTitlePane; >> 59: import javax.swing.plaf.UIResource; > > I got a different list of imports: see [commit 389cd03](https://github.com/aivanov-jdk/jdk/commit/389cd03c5630e41bc20c60579d6a339590d36fbc). > > The list of imports should be sorted, but it's not sorted here. The imports from `java.beans` should be after `java.awt` rather inside `javax` packages. In OpenJDK, we decided to put internal packages below public packages, so `SwingUtilities2` goes below `javax.*` packages. There's still wildcard import: `TMSchema.*`. > > The [complete sorted list of imports](https://github.com/aivanov-jdk/jdk/blob/389cd03c5630e41bc20c60579d6a339590d36fbc/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L28-L68) as produced by *Optimize Imports* command in IDEA. ok..updated.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1630040255 PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1259125032 From tr at openjdk.org Tue Jul 11 04:16:54 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Jul 2023 04:16:54 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 12:46:26 GMT, Alexey Ivanov wrote: >>> > > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. >>> > >>> > >>> > Is it require to address? >>> >>> I'd rather say ?yes?. Since you're trying to improve border rendering, it's better to fix this inconsistency too. >>> >>> But to get pixel-perfect rendering, you may need to remove the scale transform. >> >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > > I admit I am confused to which part it refers. > > I re-checked your after screenshot and it looks fine to me. The shadow is followed by white highlight. There was background colour seen between these two colours in the before-fix screenshot. > > There's still a 2-pixel background colour under the highlight. Yet it is present in the before-fix too, so it looks it is designed this way for a smoother 3D shading effect. @aivanov-jdk @kumarabhi006 Any comments on this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1630083790 From tr at openjdk.org Tue Jul 11 04:19:20 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Jul 2023 04:19:20 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v2] In-Reply-To: <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com> Message-ID: On Tue, 20 Jun 2023 20:33:32 GMT, Phil Race wrote: >>> This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution. >> >> It is possible that the width of the sting isn't calculated correctly, which could explain ?cut off? label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues. > >> > This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution. >> >> It is possible that the width of the sting isn't calculated correctly, which could explain ?cut off? label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues. > > So long as such a margin doesn't just become another workaround fix, so > > Step 1 - measure it correctly > Step 2 - add a pixel of clear margin space for added aesthetics. @prrace @aivanov-jdk @kumarabhi006 Any comments on this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1630084595 From serb at openjdk.org Tue Jul 11 04:47:44 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 04:47:44 GMT Subject: RFR: 6211126: ICC_ColorSpace.toCIEXYZ(float[]): NPE is not specified Message-ID: The specification of some methods has been updated to include current behaviour on null. ------------- Commit messages: - tests - 6211126: ICC_ColorSpace.toCIEXYZ(float[]): NPE is not specified Changes: https://git.openjdk.org/jdk/pull/14821/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14821&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6211126 Stats: 193 lines in 8 files changed: 180 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14821.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14821/head:pull/14821 PR: https://git.openjdk.org/jdk/pull/14821 From duke at openjdk.org Tue Jul 11 07:27:14 2023 From: duke at openjdk.org (Jeremy) Date: Tue, 11 Jul 2023 07:27:14 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v2] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Wed, 5 Jul 2023 23:51:11 GMT, Liam Miller-Cushon wrote: >> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 6355567: AdobeMarkerSegment causes failure to read valid JPEG Does anyone want to reinstate a test for this? I created a simple 10x10 black jpeg that reproduces the problem: https://drive.google.com/file/d/15rhf9-aMqajgoc3OKFhJq92hIu4OmG32/view?usp=sharing ------------- PR Comment: https://git.openjdk.org/jdk/pull/14779#issuecomment-1630290126 From abhiscxk at openjdk.org Tue Jul 11 07:52:14 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 11 Jul 2023 07:52:14 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com> <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com> <4aP-UFbjf51-x-WJa-E3o4ecjJJw4fhPgXUEXtkvvM8=.6d6f42ea-281d-4886-994d-948fe9823648@github.com> <_BEr15ASBn4AAaO7WkLe6vIXqOUNSDLskogaCDBvkg8=.531ed829-3bfa-4f57-9282-24808a10ffc7@github.com> Message-ID: <1U7T7V8kBDeage4GMFDauiUyKEDSf1uxPkIVrCb4ro4=.ac1df111-e141-4624-bc22-734a6a607ddf@github.com> On Thu, 6 Jul 2023 11:54:41 GMT, Alexey Ivanov wrote: >>> Do you think it is correct? >>> >>> I admit refactoring / rewriting accessibility implementation for JComboBox is out of scope in this bug. Yet the current way doesn't feel right. >> >> I think so. >> If I am not wrong the non-editable JComboBox doesn't have any editor, so the arrowButton width and height is equal to the combobox width and height. This results in arrowbutton rendering for entire display area of combobox. Due to this we are getting the accessible interface invoked for combobox button. > > Yes, non-editable combo box doesn't have the editor. Yet the arrowButton is not what displays the text. It is for this reason that I think it is wrong that the button becomes the main component which handles accessibility for combo box if it's not editable. It is not the button that displays the text. > > Setting accessible name in `doRendererPaint` doesn't feel right either. As per our discussion, I didn't find other way to set the accessible name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1259330533 From aivanov at openjdk.org Tue Jul 11 10:28:09 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 10:28:09 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v9] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 03:21:16 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thank you! It looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1523949779 From tr at openjdk.org Tue Jul 11 10:56:47 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Jul 2023 10:56:47 GMT Subject: RFR: 8280482: Window transparency bug on Linux Message-ID: The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neither didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. ------------- Commit messages: - Fix + Automated test Changes: https://git.openjdk.org/jdk/pull/14825/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280482 Stats: 151 lines in 2 files changed: 149 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From tr at openjdk.org Tue Jul 11 11:30:00 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Jul 2023 11:30:00 GMT Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v9] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 03:21:16 GMT, Prasanta Sadhukhan wrote: >> Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. >> >> Before fix SwingSet2 demo (Windows Classic InternalFrame) >> ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) >> >> After fix >> ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks good to me. ------------- Marked as reviewed by tr (Committer). PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1524048187 From aivanov at openjdk.org Tue Jul 11 11:51:23 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 11:51:23 GMT Subject: RFR: 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final Message-ID: A small clean-up of `awt.ScrollPane` code: 1. Remove the redundant initialiser for `vs` in `layout` and move the declaration to where it's used. (One less `Dimension` object is created.) 2. Mark the `scroller` field of the `PeerFixer` class as `final`. Perhaps, the `PeerFixer` class could be `final` too. ------------- Commit messages: - 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final Changes: https://git.openjdk.org/jdk/pull/14827/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311805 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14827.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14827/head:pull/14827 PR: https://git.openjdk.org/jdk/pull/14827 From aivanov at openjdk.org Tue Jul 11 13:46:23 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 13:46:23 GMT Subject: Integrated: 8311689: Wrong visible amount in Adjustable of ScrollPane In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 17:23:22 GMT, Alexey Ivanov wrote: > It proved that `ScrollPane.layout` depends on the result of `WScrollPanePeer.childResized`, specifically on `setSpans` which recalculates the spans and sets the insets. > > https://github.com/openjdk/jdk/blob/b285ed72aebe2d802fa9c071372cea6c09870b9a/src/java.desktop/share/classes/java/awt/ScrollPane.java#L514-L521 > > After the fix for [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` that is called in `childResized` is run asynchronously on the toolkit thread. Therefore `getViewportSize` uses the wrong insets which don't take into account the size of the scroll bar. Because of it, the `visibleAmount` field of adjustables is also wrong, and the scroll pane cannot display a portion of its child component. > > I overlooked this dependency even when I was fixing the first regression, [JDK-8310054](https://bugs.openjdk.org/browse/JDK-8310054). Had I followed Harshitha's advice in #14478, I would've fixed this problem too. Similarly, Phil's intuition was right: `setSpans` should be synchronous. @honkar-jdk @prrace > > **Fix** > > The fix is to run `AwtScrollPane::_SetSpans` synchronously using `AwtToolkit::InvokeFunction`. > > I also addressed [Sergey's concern](https://github.com/openjdk/jdk/pull/14478#discussion_r1239049983): `VerifyState` is now called after `SetInsets`. @mrserb > > Client tests are green. This pull request has now been integrated. Changeset: b3f34039 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b Stats: 98 lines in 2 files changed: 96 ins; 1 del; 1 mod 8311689: Wrong visible amount in Adjustable of ScrollPane Reviewed-by: prr, honkar, serb ------------- PR: https://git.openjdk.org/jdk/pull/14815 From aivanov at openjdk.org Tue Jul 11 14:57:48 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 14:57:48 GMT Subject: [jdk21] RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane Message-ID: This is a clean backport of [JDK-8311689](https://bugs.openjdk.org/browse/JDK-8311689) which is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923). --- > This pull request contains a backport of commit [b3f34039](https://github.com/openjdk/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Alexey Ivanov on 11 Jul 2023 and was reviewed by Phil Race, Harshitha Onkar and Sergey Bylokhov. @prrace @honkar-jdk @mrserb ------------- Commit messages: - Backport b3f34039fedd3c49404783ec880e1885dceb296b Changes: https://git.openjdk.org/jdk21/pull/111/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311689 Stats: 98 lines in 2 files changed: 96 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk21/pull/111.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/111/head:pull/111 PR: https://git.openjdk.org/jdk21/pull/111 From honkar at openjdk.org Tue Jul 11 15:53:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 11 Jul 2023 15:53:20 GMT Subject: [jdk21] RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 14:47:58 GMT, Alexey Ivanov wrote: > This is a clean backport of [JDK-8311689](https://bugs.openjdk.org/browse/JDK-8311689) which is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923). > > --- > >> This pull request contains a backport of commit [b3f34039](https://github.com/openjdk/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Alexey Ivanov on 11 Jul 2023 and was reviewed by Phil Race, Harshitha Onkar and Sergey Bylokhov. > > @prrace @honkar-jdk @mrserb Marked as reviewed by honkar (Committer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/111#pullrequestreview-1524601464 From cushon at openjdk.org Tue Jul 11 15:54:56 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 11 Jul 2023 15:54:56 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v3] In-Reply-To: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: > Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Restore the test https://github.com/openjdk/jdk/pull/14779#issuecomment-1630290126 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14779/files - new: https://git.openjdk.org/jdk/pull/14779/files/24a77ead..8af02be6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14779&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14779&range=01-02 Stats: 59 lines in 2 files changed: 59 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14779/head:pull/14779 PR: https://git.openjdk.org/jdk/pull/14779 From cushon at openjdk.org Tue Jul 11 15:54:57 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 11 Jul 2023 15:54:57 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v2] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Tue, 11 Jul 2023 07:24:36 GMT, Jeremy wrote: > Does anyone want to reinstate a test for this? I created a simple 10x10 black jpeg that reproduces the problem: > > https://drive.google.com/file/d/15rhf9-aMqajgoc3OKFhJq92hIu4OmG32/view?usp=sharing Thanks! I have reinstated the test with that jpeg ------------- PR Comment: https://git.openjdk.org/jdk/pull/14779#issuecomment-1631070360 From jiangli at openjdk.org Tue Jul 11 16:57:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 16:57:23 GMT Subject: Integrated: 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c In-Reply-To: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> References: <1GRV8h9APQ4EUc1yDaER_9cdksDCT2Au67o-n7Zid90=.2fd2e2a9-c7da-4b80-b612-fe5d7853bfe3@github.com> Message-ID: On Fri, 7 Jul 2023 00:44:33 GMT, Jiangli Zhou wrote: > Please review this trivial PR that changes read_icc_profile() to static function to avoid static linking failure due to duplicate symbol issue. This pull request has now been integrated. Changeset: e154b0d6 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/e154b0d6cdde3071b2c43abd8aacc79c51914564 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/14794 From prr at openjdk.org Tue Jul 11 16:58:13 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 11 Jul 2023 16:58:13 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v3] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Tue, 11 Jul 2023 15:54:56 GMT, Liam Miller-Cushon wrote: >> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Restore the test > > https://github.com/openjdk/jdk/pull/14779#issuecomment-1630290126 re-approving with test ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14779#pullrequestreview-1524718186 From azvegint at openjdk.org Tue Jul 11 17:12:10 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 11 Jul 2023 17:12:10 GMT Subject: [jdk21] RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 14:47:58 GMT, Alexey Ivanov wrote: > This is a clean backport of [JDK-8311689](https://bugs.openjdk.org/browse/JDK-8311689) which is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923). > > --- > >> This pull request contains a backport of commit [b3f34039](https://github.com/openjdk/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Alexey Ivanov on 11 Jul 2023 and was reviewed by Phil Race, Harshitha Onkar and Sergey Bylokhov. > > @prrace @honkar-jdk @mrserb Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/111#pullrequestreview-1524745144 From azvegint at openjdk.org Tue Jul 11 17:16:02 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 11 Jul 2023 17:16:02 GMT Subject: RFR: 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 11:44:15 GMT, Alexey Ivanov wrote: > A small clean-up of `awt.ScrollPane` code: > > 1. Remove the redundant initialiser for `vs` in `layout` and move the declaration to where it's used. (One less `Dimension` object is created.) > 2. Mark the `scroller` field of the `PeerFixer` class as `final`. > > Perhaps, the `PeerFixer` class could be `final` too. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14827#pullrequestreview-1524752861 From prr at openjdk.org Tue Jul 11 17:21:20 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 11 Jul 2023 17:21:20 GMT Subject: [jdk21] RFR: 8311689: Wrong visible amount in Adjustable of ScrollPane In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 14:47:58 GMT, Alexey Ivanov wrote: > This is a clean backport of [JDK-8311689](https://bugs.openjdk.org/browse/JDK-8311689) which is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923). > > --- > >> This pull request contains a backport of commit [b3f34039](https://github.com/openjdk/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Alexey Ivanov on 11 Jul 2023 and was reviewed by Phil Race, Harshitha Onkar and Sergey Bylokhov. > > @prrace @honkar-jdk @mrserb Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/111#pullrequestreview-1524764598 From serb at openjdk.org Tue Jul 11 17:52:55 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 11 Jul 2023 17:52:55 GMT Subject: RFR: 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final In-Reply-To: References: Message-ID: <_x-b32igr1kbo9RSWrvVxysUJbQ9LrbKcvPA_EKC3oA=.ecc6e8f3-b432-47c5-9be7-51861e02ae40@github.com> On Tue, 11 Jul 2023 11:44:15 GMT, Alexey Ivanov wrote: > A small clean-up of `awt.ScrollPane` code: > > 1. Remove the redundant initialiser for `vs` in `layout` and move the declaration to where it's used. (One less `Dimension` object is created.) > 2. Mark the `scroller` field of the `PeerFixer` class as `final`. > > Perhaps, the `PeerFixer` class could be `final` too. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14827#pullrequestreview-1524832856 From prr at openjdk.org Tue Jul 11 18:11:15 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 11 Jul 2023 18:11:15 GMT Subject: RFR: 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 11:44:15 GMT, Alexey Ivanov wrote: > A small clean-up of `awt.ScrollPane` code: > > 1. Remove the redundant initialiser for `vs` in `layout` and move the declaration to where it's used. (One less `Dimension` object is created.) > 2. Mark the `scroller` field of the `PeerFixer` class as `final`. > > Perhaps, the `PeerFixer` class could be `final` too. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14827#pullrequestreview-1524866303 From honkar at openjdk.org Tue Jul 11 18:16:07 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 11 Jul 2023 18:16:07 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 23:11:21 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> minor test changes > > src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 135: > >> 133: if ((initFlags & kCGEventFlagMaskSecondaryFn) != 0) { >> 134: initFlags ^= kCGEventFlagMaskSecondaryFn; >> 135: } > > Can you please double check how the lines below affected the usecase you fix, especially: >> CGEnableEventStateCombining - Pass true to specify that the actual key and mouse state are merged with the application-specified state in a synthetic event; otherwise, pass false. @mrserb I checked by changing `CGEnableEventStateCombining()` to `false` with the updated code and it didn't make any difference. Works the same when I test it with the reproducer. I will check again to see if there is any difference in the final flag bits that is used to post the event. Did you also mean trying out different options available for the following lines with the original code intact? // Let our event's modifier key state blend with local hardware events CGEnableEventStateCombining(TRUE); // Don't let our events block local hardware events CGSetLocalEventsFilterDuringSupressionState( kCGEventFilterMaskPermitAllEvents, kCGEventSupressionStateSupressionInterval); CGSetLocalEventsFilterDuringSupressionState( kCGEventFilterMaskPermitAllEvents, kCGEventSupressionStateRemoteMouseDrag); While going through Apple documentation about [CGEnableEventStateCombining(boolean doCombineState)](https://developer.apple.com/documentation/coregraphics/1541787-cgenableeventstatecombining?language=objc) it states: _When called with doCombineState equal to false, this function initializes local (per application) state tracking information to a state of all keys, modifiers, and mouse buttons up. When called with doCombineState equal to true, the current global state of keys, modifiers, and mouse buttons are used in generating events._ So I think CGEnableEventStateCombining should be set to TRUE as it is configured now ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1260107279 From aivanov at openjdk.org Tue Jul 11 18:48:21 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 18:48:21 GMT Subject: [jdk21] Integrated: 8311689: Wrong visible amount in Adjustable of ScrollPane In-Reply-To: References: Message-ID: <_tbchZ_QN8Ch8j5_TLt-hxaPH1ZjIE6MdcdMi4Uiifg=.83dadb64-d0b7-4c7c-8590-bc1faa4f08e8@github.com> On Tue, 11 Jul 2023 14:47:58 GMT, Alexey Ivanov wrote: > This is a clean backport of [JDK-8311689](https://bugs.openjdk.org/browse/JDK-8311689) which is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923). > > --- > >> This pull request contains a backport of commit [b3f34039](https://github.com/openjdk/jdk/commit/b3f34039fedd3c49404783ec880e1885dceb296b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Alexey Ivanov on 11 Jul 2023 and was reviewed by Phil Race, Harshitha Onkar and Sergey Bylokhov. > > @prrace @honkar-jdk @mrserb This pull request has now been integrated. Changeset: 480dc220 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk21/commit/480dc220bf640c1bc0396639c94562ba0ad079b4 Stats: 98 lines in 2 files changed: 96 ins; 1 del; 1 mod 8311689: Wrong visible amount in Adjustable of ScrollPane Reviewed-by: honkar, azvegint, prr Backport-of: b3f34039fedd3c49404783ec880e1885dceb296b ------------- PR: https://git.openjdk.org/jdk21/pull/111 From aivanov at openjdk.org Tue Jul 11 19:45:11 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 11 Jul 2023 19:45:11 GMT Subject: Integrated: 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 11:44:15 GMT, Alexey Ivanov wrote: > A small clean-up of `awt.ScrollPane` code: > > 1. Remove the redundant initialiser for `vs` in `layout` and move the declaration to where it's used. (One less `Dimension` object is created.) > 2. Mark the `scroller` field of the `PeerFixer` class as `final`. > > Perhaps, the `PeerFixer` class could be `final` too. This pull request has now been integrated. Changeset: aac903db Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/aac903dbfb7dfb42464cad23aa9f1d536b55cfc1 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final Reviewed-by: azvegint, serb, prr ------------- PR: https://git.openjdk.org/jdk/pull/14827 From azvegint at openjdk.org Tue Jul 11 21:17:12 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 11 Jul 2023 21:17:12 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 01:56:31 GMT, Julian Waters wrote: > Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code src/java.desktop/windows/native/libawt/windows/awt_new.cpp line 99: > 97: } > 98: > 99: return nullptr; Shouldn't it be the `ptr`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14795#discussion_r1260287702 From dnguyen at openjdk.org Tue Jul 11 22:01:14 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 11 Jul 2023 22:01:14 GMT Subject: RFR: 8280482: Window transparency bug on Linux In-Reply-To: References: Message-ID: <7FpPK6kYB386fDpE8sYCItbPTdZ1NXJFBKexBPNsemw=.33db7d9a-c230-44c5-8e5b-49a6bef03f2b@github.com> On Tue, 11 Jul 2023 10:50:13 GMT, Tejesh R wrote: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Suggested some minor changes. I ran the changes and test in CI as well, and it passed with a higher repetition test. Test looks fine to me on Linux. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 79: > 77: .getScreenDevices(); > 78: > 79: if(screens.length < 2) { Suggestion: if (screens.length < 2) { test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 80: > 78: > 79: if(screens.length < 2) { > 80: System.out.println("Testing aborted. Required min of 2 screens. Found : " + screens.length ); There are a few lines like this that exceed the line character limit. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 120: > 118: double windowXPos = window.getBounds().getX(); > 119: double screen1Width = screens[0].getDefaultConfiguration().getBounds().getWidth(); > 120: System.out.println("window x Position : " + windowXPos + ", screen[0] width : " + screen1Width); Line character limit ------------- PR Review: https://git.openjdk.org/jdk/pull/14825#pullrequestreview-1525196838 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1260312859 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1260311802 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1260313265 From prr at openjdk.org Tue Jul 11 22:02:18 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 11 Jul 2023 22:02:18 GMT Subject: RFR: 6211126: ICC_ColorSpace.toCIEXYZ(float[]): NPE is not specified In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 00:52:50 GMT, Sergey Bylokhov wrote: > The specification of some methods has been updated to include current behaviour on null. I think this is OK. The two things that popped into my head were (1) Should the abstract methods in ColorSpace really dictate what the concrete methods should do, but (a) We already do some of that (b) it is hard to imagine a scenario in which the args aren't needed so NPE would only be averted if some implementation decided to handle it in an unlikely way (2) should the concrete methods explicitly check for null and immediately throw NPE but (b) above should mean it isn't needed, and the AIOBE cases seem like they might be the ones that need it more but don't seem to have an explicit check. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14821#pullrequestreview-1525214060 From jwaters at openjdk.org Wed Jul 12 01:07:20 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 12 Jul 2023 01:07:20 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 [v2] In-Reply-To: References: Message-ID: <-ndJIS2OOsoj13rij4cSfgIuisM73GUANyLzpZZgRWs=.e3d72860-aa01-4241-a069-bb60a632aa02@github.com> > Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code Julian Waters has updated the pull request incrementally with one additional commit since the last revision: awt_new.cpp: Do not return nullptr always... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14795/files - new: https://git.openjdk.org/jdk/pull/14795/files/88e899f4..59d8c8bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14795&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14795&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14795/head:pull/14795 PR: https://git.openjdk.org/jdk/pull/14795 From jwaters at openjdk.org Wed Jul 12 01:07:21 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 12 Jul 2023 01:07:21 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 21:12:10 GMT, Alexander Zvegintsev wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> awt_new.cpp: Do not return nullptr always... > > src/java.desktop/windows/native/libawt/windows/awt_new.cpp line 99: > >> 97: } >> 98: >> 99: return nullptr; > > Shouldn't it be the `ptr`? Oops, you're right. Good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14795#discussion_r1260438696 From tr at openjdk.org Wed Jul 12 04:59:30 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 12 Jul 2023 04:59:30 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/4549f392..eff75632 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=00-01 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From mbaesken at openjdk.org Wed Jul 12 07:14:18 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 12 Jul 2023 07:14:18 GMT Subject: RFR: JDK-8311917: MAP_FAILED definition seems to be obsolete in src/java.desktop/unix/native/common/awt/fontpath.c Message-ID: There is a MAP_FAILED definition in src/java.desktop/unix/native/common/awt/fontpath.c but it is never used in the coding and seems to be obsolete. ------------- Commit messages: - JDK-8311917 Changes: https://git.openjdk.org/jdk/pull/14843/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14843&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311917 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14843.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14843/head:pull/14843 PR: https://git.openjdk.org/jdk/pull/14843 From psadhukhan at openjdk.org Wed Jul 12 08:38:28 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Jul 2023 08:38:28 GMT Subject: RFR: 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time Message-ID: Due to some threading issues, Progress Monitor is not shown in macos.. Seems like we need to call ProgressMonitor swing component in EDT.. ------------- Commit messages: - 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time - 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time - Merge branch 'master' of github.com:prsadhuk/jdk - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Revert "Fix" - Fix Changes: https://git.openjdk.org/jdk/pull/14844/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14844&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311881 Stats: 11 lines in 1 file changed: 6 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14844/head:pull/14844 PR: https://git.openjdk.org/jdk/pull/14844 From azvegint at openjdk.org Wed Jul 12 10:23:56 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 12 Jul 2023 10:23:56 GMT Subject: RFR: 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 07:36:56 GMT, Prasanta Sadhukhan wrote: > Due to some threading issues, Progress Monitor is not shown in macos.. > Seems like we need to call ProgressMonitor swing component in EDT.. Marked as reviewed by azvegint (Reviewer). test/jdk/javax/swing/ProgressMonitor/ProgressTest.java line 81: > 79: if ((total % (1024*1024)) == 0) { > 80: try { > 81: EventQueue.invokeAndWait(() -> { I think we could use `invokeLater` here for slightly faster test execution. ------------- PR Review: https://git.openjdk.org/jdk/pull/14844#pullrequestreview-1526018891 PR Review Comment: https://git.openjdk.org/jdk/pull/14844#discussion_r1260958300 From azvegint at openjdk.org Wed Jul 12 10:32:13 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 12 Jul 2023 10:32:13 GMT Subject: RFR: 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 07:36:56 GMT, Prasanta Sadhukhan wrote: > Due to some threading issues, Progress Monitor is not shown in macos.. It's more like we didn't meet the conditions for the ProgressMonitor to appear. https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/ProgressMonitor.html > Initially, there is no ProgressDialog. After the first millisToDecideToPopup milliseconds (default 500) the progress monitor will predict how long the operation will take. If it is longer than millisToPopup (default 2000, 2 seconds) a ProgressDialog will be popped up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14844#issuecomment-1632252412 From honkar at openjdk.org Wed Jul 12 17:46:46 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 12 Jul 2023 17:46:46 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v6] In-Reply-To: References: Message-ID: > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > The test runs in 2 modes - as automated and manual test. > > CASE 1 : As automated test. No user interaction needed. > CASE 2 : When r... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: bitwise not,test changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/2b682e7b..78928d88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=04-05 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From honkar at openjdk.org Wed Jul 12 17:48:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 12 Jul 2023 17:48:20 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 20:24:47 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> minor test changes > > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 261: > >> 259: boolean condition = expectedResult.equals(EXPECTED_RESULT_CTRL) >> 260: ? (jTextArea.getCaretPosition() >> 261: != Integer.parseInt(EXPECTED_RESULT_CTRL)) > > You pass different expected result strings but here you always compare `expectedResult` to `EXPECTED_RESULT_CTRL`. Is it intentional? Do I miss anything? > > I haven't run the test. @aivanov-jdk Will be restructuring test case using Predicate as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1261514490 From prr at openjdk.org Wed Jul 12 19:33:03 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 12 Jul 2023 19:33:03 GMT Subject: RFR: JDK-8311917: MAP_FAILED definition seems to be obsolete in src/java.desktop/unix/native/common/awt/fontpath.c In-Reply-To: References: Message-ID: <4TFER1kN-criVm62JsBVpBzMSqufW6N84ECXeLuUM7g=.869935a9-a8f8-42d0-8d2b-932364aa2c5e@github.com> On Wed, 12 Jul 2023 07:07:05 GMT, Matthias Baesken wrote: > There is a MAP_FAILED definition in src/java.desktop/unix/native/common/awt/fontpath.c but it is never used in the coding and seems to be obsolete. I did some digging and this was used in a function related to obtaining font dirs on Solaris. I suppose the definition was needed because the function was still compiled on Linux. That function was removed a long time ago, even before the Solaris port was removed. So this is indeed obsolete. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14843#pullrequestreview-1527102069 From azvegint at openjdk.org Wed Jul 12 23:46:20 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 12 Jul 2023 23:46:20 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 [v2] In-Reply-To: <-ndJIS2OOsoj13rij4cSfgIuisM73GUANyLzpZZgRWs=.e3d72860-aa01-4241-a069-bb60a632aa02@github.com> References: <-ndJIS2OOsoj13rij4cSfgIuisM73GUANyLzpZZgRWs=.e3d72860-aa01-4241-a069-bb60a632aa02@github.com> Message-ID: On Wed, 12 Jul 2023 01:07:20 GMT, Julian Waters wrote: >> Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > awt_new.cpp: Do not return nullptr always... Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14795#pullrequestreview-1527375797 From jwaters at openjdk.org Thu Jul 13 01:02:29 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 13 Jul 2023 01:02:29 GMT Subject: RFR: 8311380: Prepare java.desktop for C++17 [v2] In-Reply-To: <-ndJIS2OOsoj13rij4cSfgIuisM73GUANyLzpZZgRWs=.e3d72860-aa01-4241-a069-bb60a632aa02@github.com> References: <-ndJIS2OOsoj13rij4cSfgIuisM73GUANyLzpZZgRWs=.e3d72860-aa01-4241-a069-bb60a632aa02@github.com> Message-ID: On Wed, 12 Jul 2023 01:07:20 GMT, Julian Waters wrote: >> Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > awt_new.cpp: Do not return nullptr always... Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14795#issuecomment-1633384928 From jwaters at openjdk.org Thu Jul 13 01:02:29 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 13 Jul 2023 01:02:29 GMT Subject: Integrated: 8311380: Prepare java.desktop for C++17 In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 01:56:31 GMT, Julian Waters wrote: > Despite the fancy name, all this change does is move a few standard library headers to the top so macro definitions don't break them, remove the register specifiers from allocation methods, and remove dynamic exception specifiers from AWT code This pull request has now been integrated. Changeset: fb90af88 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/fb90af881badf143163c7d0b9961152c2a12cd84 Stats: 79 lines in 14 files changed: 17 ins; 30 del; 32 mod 8311380: Prepare java.desktop for C++17 Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/14795 From mbaesken at openjdk.org Thu Jul 13 07:14:22 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 07:14:22 GMT Subject: RFR: JDK-8311917: MAP_FAILED definition seems to be obsolete in src/java.desktop/unix/native/common/awt/fontpath.c In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 07:07:05 GMT, Matthias Baesken wrote: > There is a MAP_FAILED definition in src/java.desktop/unix/native/common/awt/fontpath.c but it is never used in the coding and seems to be obsolete. Hi Phil, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14843#issuecomment-1633688637 From mbaesken at openjdk.org Thu Jul 13 07:14:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 07:14:23 GMT Subject: Integrated: JDK-8311917: MAP_FAILED definition seems to be obsolete in src/java.desktop/unix/native/common/awt/fontpath.c In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 07:07:05 GMT, Matthias Baesken wrote: > There is a MAP_FAILED definition in src/java.desktop/unix/native/common/awt/fontpath.c but it is never used in the coding and seems to be obsolete. This pull request has now been integrated. Changeset: a38a421f Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a38a421f62efbcc0fc9c6a08738b5f0ab38a4594 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8311917: MAP_FAILED definition seems to be obsolete in src/java.desktop/unix/native/common/awt/fontpath.c Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/14843 From asemenov at openjdk.org Thu Jul 13 13:40:25 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 13 Jul 2023 13:40:25 GMT Subject: RFR: 8302687 Implement interfaces and shared code for announcement feature [v5] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 17:56:04 GMT, Artem Semenov wrote: >> This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature. >> >> CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org") >> >> @mrserb @prrace @azuev-java please review > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update You don't have to close anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13001#issuecomment-1634261976 From philip.race at oracle.com Thu Jul 13 15:27:55 2023 From: philip.race at oracle.com (Philip Race) Date: Thu, 13 Jul 2023 08:27:55 -0700 Subject: IMPORTANT REMINDER: 2 Reviews (ie approvals) are required for most client-libs changes Message-ID: Please see "Code Reviews" on the Group page https://openjdk.org/groups/client-libs/ where it says The Java Client Library Group has always standardized on two approvals - where at least one must have the Reviewer role. Historically this was addressed entirely by social conventions but today the tooling plays a role - and the JDK project is set up to mark a PR as ready for integration after a single approval by a person with the Reviewer role - which is not consistent with the Client Libraries policy. The tooling cannot automatically enforce this on a per-module basis and it is not reasonable to expect others to add "/reviewers 2" to every PR. The fixer therefore needs to understand the policies and wait for a second approval. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ As an example of a PR about which there was zero urgency and should have had a 2nd approval see https://github.com/openjdk/jdk/pull/14795 -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Thu Jul 13 18:59:35 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 13 Jul 2023 18:59:35 GMT Subject: RFR: 6211202: ColorSpace.getInstance(int): IAE is not specified Message-ID: <-pvkexKT2T0O8y3TQ1wrdkrUoaj_Tw6Aq1YDR1ILHWg=.37c193da-4a87-4482-bd40-a64520b9cacc@github.com> * Added @throws IllegalArgumentException to the specification of java.awt.color.ColorSpace.getInstance(int) * Deleted duplicate text about IllegalArgumentException from the java.awt.color.ICC_Profile.getInstance(int) ------------- Commit messages: - 6211202: ColorSpace.getInstance(int): IAE is not specified Changes: https://git.openjdk.org/jdk/pull/14860/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6211202 Stats: 20 lines in 3 files changed: 15 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14860/head:pull/14860 PR: https://git.openjdk.org/jdk/pull/14860 From prr at openjdk.org Thu Jul 13 19:05:15 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 13 Jul 2023 19:05:15 GMT Subject: RFR: 6355567: AdobeMarkerSegment causes failure to read valid JPEG [v3] In-Reply-To: References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Tue, 11 Jul 2023 15:54:56 GMT, Liam Miller-Cushon wrote: >> Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Restore the test > > https://github.com/openjdk/jdk/pull/14779#issuecomment-1630290126 Since Sergey also reviewed, this is OK to push now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14779#issuecomment-1634748843 From prr at openjdk.org Thu Jul 13 19:08:10 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 13 Jul 2023 19:08:10 GMT Subject: RFR: 6211202: ColorSpace.getInstance(int): IAE is not specified In-Reply-To: <-pvkexKT2T0O8y3TQ1wrdkrUoaj_Tw6Aq1YDR1ILHWg=.37c193da-4a87-4482-bd40-a64520b9cacc@github.com> References: <-pvkexKT2T0O8y3TQ1wrdkrUoaj_Tw6Aq1YDR1ILHWg=.37c193da-4a87-4482-bd40-a64520b9cacc@github.com> Message-ID: <7bRpmkMI_pylcot5Bty_r1tT1oVgtNUHa0-9_u6dgiU=.a0f75d0a-6212-4f94-a994-788fbbadea4c@github.com> On Thu, 13 Jul 2023 05:13:45 GMT, Sergey Bylokhov wrote: > * Added @throws IllegalArgumentException to the specification of java.awt.color.ColorSpace.getInstance(int) > * Deleted duplicate text about IllegalArgumentException from the java.awt.color.ICC_Profile.getInstance(int) Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14860#pullrequestreview-1529084295 From cushon at openjdk.org Thu Jul 13 19:40:17 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 13 Jul 2023 19:40:17 GMT Subject: Integrated: 6355567: AdobeMarkerSegment causes failure to read valid JPEG In-Reply-To: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> References: <7GABsBKwKLN26NRSk_Xf3SjSxissBawbo51ReZYjxN0=.7653137f-ebab-459a-9770-4e4c0989aca4@github.com> Message-ID: On Wed, 5 Jul 2023 23:19:39 GMT, Liam Miller-Cushon wrote: > Please review this fix for JDK-6355567, which updates AdobeMarkerSegment to use the reported length of the segment instead of assuming it's always exactly 14 bytes. This pull request has now been integrated. Changeset: c7c6d47a Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/c7c6d47a07100f6c81af6cfad301ec1bda77adf7 Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod 6355567: AdobeMarkerSegment causes failure to read valid JPEG Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/14779 From thomas.stuefe at gmail.com Thu Jul 13 20:24:43 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 13 Jul 2023 22:24:43 +0200 Subject: IMPORTANT REMINDER: 2 Reviews (ie approvals) are required for most client-libs changes In-Reply-To: References: Message-ID: I think it would be less confusing all around to have a general requirement for 2 reviewers across the whole OpenJDK. On Thu, Jul 13, 2023 at 5:28?PM Philip Race wrote: > Please see "Code Reviews" on the Group page > https://openjdk.org/groups/client-libs/ where it says > > The Java Client Library Group has always standardized on two approvals - > where at least one must have the Reviewer role. > Historically this was addressed entirely by social conventions but today > the tooling plays a role - and the JDK project is set up to mark a PR as > ready for integration after a single approval by a person with the Reviewer > role - which is not consistent with the Client Libraries policy. > The tooling cannot automatically enforce this on a per-module basis and it > is not reasonable to expect others to add "/reviewers 2" to every PR. > The fixer therefore needs to understand the policies and wait for a second > approval. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > As an example of a PR about which there was zero urgency and should have > had a 2nd approval see > > https://github.com/openjdk/jdk/pull/14795 > > -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 13 20:33:11 2023 From: philip.race at oracle.com (Philip Race) Date: Thu, 13 Jul 2023 13:33:11 -0700 Subject: IMPORTANT REMINDER: 2 Reviews (ie approvals) are required for most client-libs changes In-Reply-To: References: Message-ID: <943370ff-6ec1-3673-c630-133130eec22d@oracle.com> That would be nice but I suspect it would not be easy to get agreement on that. At least the dev guide also says "Some teams may require more Reviewers." https://openjdk.org/guide/#fixing-a-bug And it recommends 24 business hrs as well .. "In general all PRs should be open for at least 24 hours to allow for reviewers in all time zones to get a chance to see it. It may actually happen that even 24 hours isn?t enough. Take into account weekends, holidays, and vacation times throughout the world and you?ll realize that a change that requires more than just a trivial review may have to be open for a while. In some areastrivial changes are allowed to be pushed without the 24 hour delay. Ask your reviewers if you think this applies to your change." https://openjdk.org/guide/#life-of-a-pr -phil. On 7/13/23 1:24 PM, Thomas St?fe wrote: > I think it would be less confusing all around to have a general > requirement for 2 reviewers across the whole OpenJDK. > > On Thu, Jul 13, 2023 at 5:28?PM Philip Race > wrote: > > Please see "Code Reviews" on the Group page > https://openjdk.org/groups/client-libs/ where it says > > The Java Client Library Group has always standardized on two > approvals - where at least one must have the Reviewer role. > Historically this was addressed entirely by social conventions but > today the tooling plays a role - and the JDK project is set up to > mark a PR as ready for integration after a single approval by a > person with the Reviewer role - which is not consistent with the > Client Libraries policy. > The tooling cannot automatically enforce this on a per-module > basis and it is not reasonable to expect others to add "/reviewers > 2" to every PR. > The fixer therefore needs to understand the policies and wait for > a second approval. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > As an example of a PR about which there was zero urgency and > should have had a 2nd approval see > > https://github.com/openjdk/jdk/pull/14795 > > -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Fri Jul 14 05:48:21 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 14 Jul 2023 05:48:21 GMT Subject: Withdrawn: 8049347: HTMLDocument throws NPE for Block Tag In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 12:43:18 GMT, Prasanta Sadhukhan wrote: > Trying to iterate for HEAD HTML tag or for any other "Block" Tag results in NPE due to some spurious unhandled code which just return NULL. > Removing the code solves this problem and also does not cause any regression in clientlibs test. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14466 From abhiscxk at openjdk.org Fri Jul 14 05:51:12 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 14 Jul 2023 05:51:12 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v4] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 08:28:22 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Please check for spaces as per standard. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 76: > 74: > 75: table = new JTable(data, columnNames); > 76: table.setSize(WIDTH,HEIGHT); Suggestion: table.setSize(WIDTH, HEIGHT); test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 87: > 85: w = SCALE * size.width; > 86: h = SCALE * size.height; > 87: imgHeader = new BufferedImage((int)(w),(int)(h),BufferedImage.TYPE_INT_RGB); Suggestion: imgHeader = new BufferedImage((int)(w), (int)(h), BufferedImage.TYPE_INT_RGB); test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 110: > 108: verticalLineCol = (int)(table.getTableHeader(). > 109: getColumnModel().getColumn(0).getWidth() * SCALE) - 2; > 110: expectedRGB = imgData.getRGB(verticalLineCol,0); Suggestion: expectedRGB = imgData.getRGB(verticalLineCol, 0); test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 112: > 110: expectedRGB = imgData.getRGB(verticalLineCol,0); > 111: > 112: for(int i = 0; i < imgHeader.getHeight(); i++) { Suggestion: for (int i = 0; i < imgHeader.getHeight(); i++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 113: > 111: > 112: for(int i = 0; i < imgHeader.getHeight(); i++) { > 113: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { Suggestion: for (int j = verticalLineCol; j < verticalLineCol + 3; j++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 114: > 112: for(int i = 0; i < imgHeader.getHeight(); i++) { > 113: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { > 114: if(expectedRGB != imgHeader.getRGB(j, i)) { Suggestion: if (expectedRGB != imgHeader.getRGB(j, i)) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 120: > 118: } > 119: > 120: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { Suggestion: for (int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 121: > 119: > 120: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { > 121: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { Suggestion: for (int j = verticalLineCol; j < verticalLineCol + 3; j++) { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 122: > 120: for(int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { > 121: for(int j = verticalLineCol; j < verticalLineCol + 3; j++) { > 122: if(expectedRGB != imgData.getRGB(j, i)) { Suggestion: if (expectedRGB != imgData.getRGB(j, i)) { ------------- PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1529638406 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263315454 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263316040 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263316535 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263317092 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263317252 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263316846 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263317500 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263317559 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1263317675 From tr at openjdk.org Fri Jul 14 07:35:47 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 14 Jul 2023 07:35:47 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: References: Message-ID: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R 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/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/a3c5da4b..0f2557fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From tr at openjdk.org Fri Jul 14 07:43:00 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 14 Jul 2023 07:43:00 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v3] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Spacing fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/85b2dfde..9ddb85f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=01-02 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From abhiscxk at openjdk.org Fri Jul 14 07:47:55 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 14 Jul 2023 07:47:55 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> References: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> Message-ID: <8O44sYTTA9lLYzMwHTO8FEpbprE8iY8DutCPYZeD40A=.711a18cf-38e8-4195-9139-8a26642edb7a@github.com> On Fri, 14 Jul 2023 07:35:47 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix Test verified. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1529802159 From tr at openjdk.org Fri Jul 14 09:35:13 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 14 Jul 2023 09:35:13 GMT Subject: RFR: 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time In-Reply-To: References: Message-ID: <9bHr9xk0hMakfCikSeNicXMt5B-bhBFdph3R37bJXZc=.9f6d669f-1d71-48f5-a98a-b707dcfc6ba6@github.com> On Wed, 12 Jul 2023 07:36:56 GMT, Prasanta Sadhukhan wrote: > Due to some threading issues, Progress Monitor is not shown in macos.. > Seems like we need to call ProgressMonitor swing component in EDT.. The issue is not specific to MacOS, I'm able to reproduce in windows too. Fix applies to windows too. Marked as reviewed by tr (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14844#pullrequestreview-1529964274 PR Review: https://git.openjdk.org/jdk/pull/14844#pullrequestreview-1529965284 From alexsch at openjdk.org Fri Jul 14 14:35:48 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 14 Jul 2023 14:35:48 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v2] In-Reply-To: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: <_zDA9S8iVH-n_LhHRezmim7cKOsm-Ybf_9X_Pc4E49w=.26f6b7fa-464e-4d72-baf4-d013581b7e09@github.com> > To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: > > java JavaSidesAttributePrinting ONE_SIDED > java JavaSidesAttributePrinting DUPLEX > > > The sample calls PrinterJob print method with the given sides attribute. > The pages are printed according to the printer default settings not according to the provided Sides attributes. > > The fix propagates Sides attribute > - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method > - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Check supported sides attributes in the test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14727/files - new: https://git.openjdk.org/jdk/pull/14727/files/7246677c..65c9a23a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=00-01 Stats: 66 lines in 1 file changed: 49 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14727/head:pull/14727 PR: https://git.openjdk.org/jdk/pull/14727 From alexsch at openjdk.org Fri Jul 14 14:44:57 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 14 Jul 2023 14:44:57 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v3] In-Reply-To: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: > To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: > > java JavaSidesAttributePrinting ONE_SIDED > java JavaSidesAttributePrinting DUPLEX > > > The sample calls PrinterJob print method with the given sides attribute. > The pages are printed according to the printer default settings not according to the provided Sides attributes. > > The fix propagates Sides attribute > - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method > - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Local supportedSides variable is used insted of supportedSides field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14727/files - new: https://git.openjdk.org/jdk/pull/14727/files/65c9a23a..4480595c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14727/head:pull/14727 PR: https://git.openjdk.org/jdk/pull/14727 From alexsch at openjdk.org Fri Jul 14 14:50:12 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 14 Jul 2023 14:50:12 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v3] In-Reply-To: References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Fri, 14 Jul 2023 14:44:57 GMT, Alexander Scherbatiy wrote: >> To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: >> >> java JavaSidesAttributePrinting ONE_SIDED >> java JavaSidesAttributePrinting DUPLEX >> >> >> The sample calls PrinterJob print method with the given sides attribute. >> The pages are printed according to the printer default settings not according to the provided Sides attributes. >> >> The fix propagates Sides attribute >> - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method >> - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Local supportedSides variable is used insted of supportedSides field The test is updated to check the supported sides attributes. The test automatically passes if the number of supported attributes is equal or less than one. A simple explanation is added which describes what needs to be printed when one sided, duplex, or tumble attribute is used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14727#issuecomment-1635972111 From achung at openjdk.org Fri Jul 14 20:02:07 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 14 Jul 2023 20:02:07 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> References: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> Message-ID: On Fri, 14 Jul 2023 07:35:47 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix Can this test be run on other L&Fs as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1636353018 From prr at openjdk.org Fri Jul 14 21:17:15 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 14 Jul 2023 21:17:15 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v3] In-Reply-To: References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Fri, 14 Jul 2023 14:44:57 GMT, Alexander Scherbatiy wrote: >> To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: >> >> java JavaSidesAttributePrinting ONE_SIDED >> java JavaSidesAttributePrinting DUPLEX >> >> >> The sample calls PrinterJob print method with the given sides attribute. >> The pages are printed according to the printer default settings not according to the provided Sides attributes. >> >> The fix propagates Sides attribute >> - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method >> - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Local supportedSides variable is used insted of supportedSides field Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14727#pullrequestreview-1531055729 From ngubarkov at openjdk.org Sat Jul 15 21:55:21 2023 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Sat, 15 Jul 2023 21:55:21 GMT Subject: RFR: 8269806: Emoji rendering on Linux [v20] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 14:31:34 GMT, Nikita Gubarkov wrote: >> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR >> It includes: >> - Bitmap glyph loading via Freetype >> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint >> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs >> - Small fixes in related code like null-checks which could cause NPE & comment typos > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > EmojiFont CRLF -> LF Celebrating two years ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/4798#issuecomment-1636896911 From duke at openjdk.org Mon Jul 17 03:43:17 2023 From: duke at openjdk.org (Jeremy) Date: Mon, 17 Jul 2023 03:43:17 GMT Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint [v3] In-Reply-To: References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com> Message-ID: On Fri, 16 Jun 2023 23:16:53 GMT, Jeremy wrote: >> # Problem Summary >> >> For non-opaque windows, Window#paint calls `gg.fillRect(0, 0, getWidth(), getHeight())` before `super.paint(g)`. >> >> This can cause flickering on Mac, and the flickering seems to have gotten much worse in recent JVMs. (See movie attachments to original ticket.) >> >> # Discussion >> >> This is my 2nd PR for this ticket. The original is [here](https://github.com/openjdk/jdk/pull/12993); that proposed change was IMO more invasive/scarier. It was auto-closed after 8 weeks of inactivity, and I'd rather offer this PR instead. >> >> In that previous discussion Alan Snyder framed the core problem as a "lack of synchronization" (see [comment here](https://github.com/openjdk/jdk/pull/12993#issuecomment-1467528061)). If the monitor refreshes/flushes after we've called `fillRect` *but before we finish `super.paint`*: it makes sense that we'd see a flicker. >> >> I agree with Alan, but I think the problem can also be framed as a mixing-Swing-with-AWT issue. (Which IMO will involve an easier fix.) >> >> This PR is a low-risk change (relative to the previous PR) that intercepts calls to repaint a Window that is also RootPaneContainer. Now we'll redirect those calls to paint the JRootPane instead. This means we'll exclusively paint within Swing's/RepaintManager's double-buffered architecture, so we bypass the risky call to `fillRect` on the screen's Graphics2D. (And this change occurs within RepaintManager, so we're clearly already in Swing's architecture.) >> >> So with this change: we paint everything to the double-buffer, and the *only time* we paint to the Window's Graphics2D is when have set up a AlphaComposite.Src and replace its contents with our buffer's contents. >> >> # Tests >> >> This PR includes a new test for 8303950 itself. This is pretty self-explanatory: we repaint a trivial animation for a few seconds and use the Robot to see if a pixel is the expected color. >> >> This PR also includes a test called `bug8303950_legacyWindowPaintBehavior` that creates a grid of 4 windows with varying opacity/backgrounds: >> >> image >> >> I was surprised by how these windows rendered, but I don't think that's worth debating here. This test simply makes sure that we preserve this preexisting behavior. The broad "rules" appear to be: >> 1. If a JComponent identifies as opaque (see `JComponent.isOpaque`) then the JComponent's background is used. (I... > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8303950: removing unnecessary whitespace in unit test > > See https://github.com/openjdk/jdk/pull/14363#pullrequestreview-1484315506 @aivanov-jdk IIRC this ticket (a P3) was initially assigned to you, and I asked to look at it instead. It looks like for now this PR is stalled, so please feel free to reassign the openJDK ticket (or make any other appropriate changes) if needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14363#issuecomment-1637330958 From tr at openjdk.org Mon Jul 17 04:39:18 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 17 Jul 2023 04:39:18 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: References: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> Message-ID: On Fri, 14 Jul 2023 19:59:21 GMT, Alisen Chung wrote: > Can this test be run on other L&Fs as well? No, the fix and test is specific to Metal L&F. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1637364476 From duke at openjdk.org Mon Jul 17 05:59:25 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 17 Jul 2023 05:59:25 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library Message-ID: Hi Reviewers, Observations : 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). 2. For Play back device always loading proper device GUID irrespective of com Initialization. Test: Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. Please review the changes and let me know your comments if any. Regards, Renjith. ------------- Commit messages: - JDK-8301846 :Invalid TargetDataLine after screen lock when using JFileChooser or COM library - Update full name Changes: https://git.openjdk.org/jdk/pull/14898/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301846 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14898/head:pull/14898 PR: https://git.openjdk.org/jdk/pull/14898 From jwaters at openjdk.org Mon Jul 17 06:52:20 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 17 Jul 2023 06:52:20 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 Message-ID: After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed ------------- Commit messages: - 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 Changes: https://git.openjdk.org/jdk/pull/14899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312147 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14899/head:pull/14899 PR: https://git.openjdk.org/jdk/pull/14899 From duke at openjdk.org Mon Jul 17 08:24:44 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 17 Jul 2023 08:24:44 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Observations : > 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). > 2. For Play back device always loading proper device GUID irrespective of com Initialization. > > Test: > Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. > To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. > > Please review the changes and let me know your comments if any. > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14898/files - new: https://git.openjdk.org/jdk/pull/14898/files/53a378dd..98106e99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14898/head:pull/14898 PR: https://git.openjdk.org/jdk/pull/14898 From psadhukhan at openjdk.org Mon Jul 17 08:43:28 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 17 Jul 2023 08:43:28 GMT Subject: Integrated: 8140527: JInternalFrame has incorrect title button width In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 10:04:53 GMT, Prasanta Sadhukhan wrote: > Title buttons under Widows Classic L&F got their sizes from the XP desktop theme in which button width can be bigger than height. It is construed as XP bug where sizes aren't updated properly so it uses height units for width for XP and later windows. The proposed fix uses the [same technique](https://github.com/openjdk/jdk/blob/a0595761ef35c4eec8cb84326a869b9473cd5bba/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java#L78-L82) for Classic and forces title buttons to be square and to fit the frame title in height. > > Before fix SwingSet2 demo (Windows Classic InternalFrame) > ![image](https://github.com/openjdk/jdk/assets/43534309/3d6ec539-5e17-46ce-aba5-e724af6085fe) > > After fix > ![image](https://github.com/openjdk/jdk/assets/43534309/db0135e4-d7f3-41a4-bbfa-e8e95cbd071d) This pull request has now been integrated. Changeset: acf591e8 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/acf591e856ce4b43303b1578bd64a8c9ab0063ea Stats: 187 lines in 3 files changed: 153 ins; 15 del; 19 mod 8140527: JInternalFrame has incorrect title button width 8139392: JInternalFrame has incorrect padding Co-authored-by: Alexey Ivanov Reviewed-by: aivanov, tr ------------- PR: https://git.openjdk.org/jdk/pull/14555 From aturbanov at openjdk.org Mon Jul 17 09:46:56 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 17 Jul 2023 09:46:56 GMT Subject: RFR: 8312165: Fix typos in java.desktop Message-ID: Found many typos in java.desktop by IDEA's inspection `Proofreading | Typo` ------------- Commit messages: - [PATCH] Fix typos in java.desktop - [PATCH] Fix typos in java.desktop - [PATCH] Fix typos in java.desktop Changes: https://git.openjdk.org/jdk/pull/14847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14847&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312165 Stats: 455 lines in 187 files changed: 0 ins; 0 del; 455 mod Patch: https://git.openjdk.org/jdk/pull/14847.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14847/head:pull/14847 PR: https://git.openjdk.org/jdk/pull/14847 From psadhukhan at openjdk.org Mon Jul 17 14:40:18 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 17 Jul 2023 14:40:18 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> References: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> Message-ID: <7VihlI15By9TMAUfh3j6XGDGEknphFxmXsnVgMFNOVg=.51c1b8c7-a121-4f6f-b020-320285700e80@github.com> On Fri, 14 Jul 2023 07:35:47 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix I hope you have run this test on all mach5 platforms test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 38: > 36: * @bug 8311031 > 37: * @library /java/awt/regtesthelpers > 38: * @build PassFailJFrame I guess it's no longer manual so this dependency should be removed.. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 56: > 54: TableHeaderBorderPositionTest.Test(); > 55: } catch (Exception e) { > 56: throw new RuntimeException(e); I guess there's no need of `Test()` to have `throws Exception` signature and therefore no need to have this try-catch block.. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 122: > 120: for (int i = 0; i < table.getRowCount() * table.getRowHeight() * SCALE; i++) { > 121: for (int j = verticalLineCol; j < verticalLineCol + 3; j++) { > 122: if (expectedRGB != imgData.getRGB(j, i)) { You probably can write the bufferedimage into png file for debugging help during fail case.. ------------- PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1532945302 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1265455225 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1265461514 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1265464749 From honkar at openjdk.org Mon Jul 17 19:09:29 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 17 Jul 2023 19:09:29 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > The test runs in 2 modes - as automated and manual test. > > CASE 1 : As automated test. No user interaction needed. > CASE 2 : When r... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: test changes: added CountDownLatch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/78928d88..8f7d04a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=05-06 Stats: 42 lines in 1 file changed: 21 ins; 10 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From serb at openjdk.org Mon Jul 17 20:29:04 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 17 Jul 2023 20:29:04 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v5] In-Reply-To: References: Message-ID: <1APzuprOI76V3CZL5UWOoncW9svhJkDvlgawrRKENkc=.bd1efb96-5511-4b56-8409-db6452673bdf@github.com> On Tue, 11 Jul 2023 18:13:05 GMT, Harshitha Onkar wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 135: >> >>> 133: if ((initFlags & kCGEventFlagMaskSecondaryFn) != 0) { >>> 134: initFlags ^= kCGEventFlagMaskSecondaryFn; >>> 135: } >> >> Can you please double check how the lines below affected the usecase you fix, especially: >>> CGEnableEventStateCombining - Pass true to specify that the actual key and mouse state are merged with the application-specified state in a synthetic event; otherwise, pass false. > > @mrserb I checked by changing `CGEnableEventStateCombining()` to `false` with the updated code and it didn't make any difference. Works the same when I test it with the reproducer. I will check again to see if there is any difference in the final flag bits that is used to post the event. > > Did you also mean trying out different options available for the following lines with the original code intact? > > > // Let our event's modifier key state blend with local hardware events > CGEnableEventStateCombining(TRUE); > > // Don't let our events block local hardware events > CGSetLocalEventsFilterDuringSupressionState( > kCGEventFilterMaskPermitAllEvents, > kCGEventSupressionStateSupressionInterval); > > CGSetLocalEventsFilterDuringSupressionState( > kCGEventFilterMaskPermitAllEvents, > kCGEventSupressionStateRemoteMouseDrag); > > > Apple documentation about [CGEnableEventStateCombining(boolean doCombineState)](https://developer.apple.com/documentation/coregraphics/1541787-cgenableeventstatecombining?language=objc) it states: > > _When called with doCombineState equal to false, this function initializes local (per application) state tracking information to a state of all keys, modifiers, and mouse buttons up. When called with doCombineState equal to true, the current global state of keys, modifiers, and mouse buttons are used in generating events._ > > So I think CGEnableEventStateCombining should be set to TRUE as it is configured now ? I just interested how this change might affect that props. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1265862090 From serb at openjdk.org Mon Jul 17 20:35:04 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 17 Jul 2023 20:35:04 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 19:09:29 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test runs in 2 modes - as automated and manual test. >> >> CASE 1 : ... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test changes: added CountDownLatch Just to clarify an idea of this change. We would like to maintain the "flag" keys pressed by the user and maintain the list of current flags. So if the user will press SHIFT key, we will use that modifier for all next keys until shift will be released. It looks similar to how the mouseMove is implemented in CRobot, where we maintain the mouseLastX/mouseLastY, and we ignore the current location of the mouse for clicks, but use the latest saved value. Probably we can do the same on the java side in this patch? it will simplify the native code a bit. BTW do we need to set all this modifiers for the mouse clicks as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1638827736 From serb at openjdk.org Mon Jul 17 21:45:02 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 17 Jul 2023 21:45:02 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 06:45:59 GMT, Julian Waters wrote: > After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed The log of the GA: >=== Output from failing command(s) repeated here === >* For target support_native_java.desktop_libawt_CmdIDList.obj: >CmdIDList.cpp d:\a\jdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Toolkit.h(257): error C2220: the following warning is treated as an error d:\a\jdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Toolkit.h(257): warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow) ... (rest of output omitted) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14899#issuecomment-1638926129 From honkar at openjdk.org Mon Jul 17 23:56:13 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 17 Jul 2023 23:56:13 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 19:09:29 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test runs in 2 modes - as automated and manual test. >> >> CASE 1 : ... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test changes: added CountDownLatch @mrserb > Just to clarify an idea of this change. We would like to maintain the "flag" keys pressed by the user and maintain the list of current flags. So if the user will press SHIFT key, we will use that modifier for all next keys until shift will be released. That is correct. > It looks similar to how the mouseMove is implemented in CRobot, where we maintain the mouseLastX/mouseLastY, and we ignore the current location of the mouse for clicks, but use the latest saved value. > Probably we can do the same on the java side in this patch? it will simplify the native code a bit. Yes, the code for mouseEvent looks similar to what we are trying to achieve for keyEvent but there are a few differences too- - `mouseEvent(int lastX, int lastY, int buttonsState, boolean isButtonsDownState, boolean isMouseMove)`, lastX & lastY are already part of the parameters being sent from Java to native side. - `keyEvent(int javaKeyCode, boolean keydown)` - Are you suggesting that a modifier flag state be sent from Java to native side? This would involve changing the present native `keyEvent` signature and adding code to native side to evaluate the new modifier flag state from Java and then map it to the corresponding [kCGEventFlagMask](https://developer.apple.com/documentation/coregraphics/cgeventflags/kcgeventflagmaskalphashift?language=objc). Having everything on native side seems to be easier because with the present fix, the equivalent modifier flag mask is obtained using javaKeyCode + key state and a quick `NSDictionary modifierKeyToMaskMap` lookup without the need of adding or changing keyEvent signature. > BTW do we need to set all this modifiers for the mouse clicks as well? I don't think so as the issue (details below) occurs only when flagState is obtained using - `CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState)` which was the case for keyEvents. **Issue:** _With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. The physical mouse movement causes the event flags to be reset._ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1639050801 From jwaters at openjdk.org Tue Jul 18 01:43:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 18 Jul 2023 01:43:43 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 [v2] In-Reply-To: References: Message-ID: > After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Missed specifier in awt_Toolkit.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14899/files - new: https://git.openjdk.org/jdk/pull/14899/files/b528c374..166b1fd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14899&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14899&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14899/head:pull/14899 PR: https://git.openjdk.org/jdk/pull/14899 From jwaters at openjdk.org Tue Jul 18 01:43:45 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 18 Jul 2023 01:43:45 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 06:45:59 GMT, Julian Waters wrote: > After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed Oops, looks like 8311380 missed an exception specifier in awt_Toolkit.h. It should be ok now ------------- PR Comment: https://git.openjdk.org/jdk/pull/14899#issuecomment-1639146532 From tr at openjdk.org Tue Jul 18 04:36:50 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 18 Jul 2023 04:36:50 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v6] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/0f2557fb..bfb3ae8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=04-05 Stats: 22 lines in 1 file changed: 14 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From tr at openjdk.org Tue Jul 18 04:36:51 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 18 Jul 2023 04:36:51 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v5] In-Reply-To: <7VihlI15By9TMAUfh3j6XGDGEknphFxmXsnVgMFNOVg=.51c1b8c7-a121-4f6f-b020-320285700e80@github.com> References: <_Y0R46fN-HbQ9munTnsj12xGlGG2wlJ522wd_YcWmU4=.5dc0ac50-2d07-4ab1-b73a-2cf99cb17b3f@github.com> <7VihlI15By9TMAUfh3j6XGDGEknphFxmXsnVgMFNOVg=.51c1b8c7-a121-4f6f-b020-320285700e80@github.com> Message-ID: On Mon, 17 Jul 2023 14:35:29 GMT, Prasanta Sadhukhan wrote: > I hope you have run this test on all mach5 platforms I have updated the review comments and mach5 platform runs show green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1639411059 From psadhukhan at openjdk.org Tue Jul 18 04:49:06 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Jul 2023 04:49:06 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v6] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 04:36:50 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1534156925 From jpai at openjdk.org Tue Jul 18 07:06:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 07:06:30 GMT Subject: RFR: 8312151: Deprecate for removal the -Xdebug option Message-ID: Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151? As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216 ------------- Commit messages: - 8312151: Deprecate for removal the -Xdebug option Changes: https://git.openjdk.org/jdk/pull/14918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312151 Stats: 35 lines in 22 files changed: 0 ins; 8 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From jpai at openjdk.org Tue Jul 18 07:06:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 07:06:30 GMT Subject: RFR: 8312151: Deprecate for removal the -Xdebug option In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151? > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216 I would like inputs on the `test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java` test. That test launches `java` passing it the `-Xdebug` option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. `-Xdebug` has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639615535 From alanb at openjdk.org Tue Jul 18 07:36:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 07:36:14 GMT Subject: RFR: 8312151: Deprecate for removal the -Xdebug option In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151? > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216 The launcher option -debug is an alias for -Xdebug so should be deprecated too. The history on these options goes back a long way, but obsolete since JDK 6 and the removal of JVMDI at least. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639660251 From jpai at openjdk.org Tue Jul 18 07:36:12 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 07:36:12 GMT Subject: RFR: 8312151: Deprecate for removal the -Xdebug option [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8312151? > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > A CSR has been drafted for this change https://bugs.openjdk.org/browse/JDK-8312216 Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: update java man page for -Xdebug deprecation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14918/files - new: https://git.openjdk.org/jdk/pull/14918/files/e165dc24..a8d472ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From jpai at openjdk.org Tue Jul 18 07:58:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 07:58:58 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v3] In-Reply-To: References: Message-ID: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: include -debug (alias) option in the deprecated log message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14918/files - new: https://git.openjdk.org/jdk/pull/14918/files/a8d472ad..e5472701 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From jpai at openjdk.org Tue Jul 18 08:11:04 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 08:11:04 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v3] In-Reply-To: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> References: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> Message-ID: On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > include -debug (alias) option in the deprecated log message Given that https://bugs.openjdk.org/browse/JDK-8227229 had more historical details about `-Xdebug` and `-debug`, I've updated this PR to link to that issue and also drafted CSR afresh https://bugs.openjdk.org/browse/JDK-8312220 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1639725244 From abhiscxk at openjdk.org Tue Jul 18 10:03:08 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 18 Jul 2023 10:03:08 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v6] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 04:36:50 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by abhiscxk (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1534675604 From alanb at openjdk.org Tue Jul 18 11:04:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 11:04:18 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v3] In-Reply-To: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> References: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> Message-ID: On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > include -debug (alias) option in the deprecated log message src/java.base/share/classes/sun/launcher/resources/launcher.properties line 137: > 135: \ -Xcheck:jni perform additional checks for JNI functions\n\ > 136: \ -Xcomp forces compilation of methods on first invocation\n\ > 137: \ -Xdebug deprecated and may be removed in a future release.\n\ This drops "does nothing" so no longer clear that the option doesn't do anything. It could be changed to "does nothing; deprecated for removal in a future release". Alternatively maybe it would be better to just remove it from the -X output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14918#discussion_r1266609817 From jpai at openjdk.org Tue Jul 18 12:41:32 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 12:41:32 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v4] In-Reply-To: References: Message-ID: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestion for -Xdebug output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14918/files - new: https://git.openjdk.org/jdk/pull/14918/files/e5472701..78498068 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From jpai at openjdk.org Tue Jul 18 12:41:32 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 12:41:32 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v3] In-Reply-To: References: <03lsUFJ5QhNnuzzLmwbwH0-nOhehHUQRWVxvRYwwCTs=.ab7157e2-b075-4a06-9a51-9d1484765995@github.com> Message-ID: On Tue, 18 Jul 2023 11:01:33 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> include -debug (alias) option in the deprecated log message > > src/java.base/share/classes/sun/launcher/resources/launcher.properties line 137: > >> 135: \ -Xcheck:jni perform additional checks for JNI functions\n\ >> 136: \ -Xcomp forces compilation of methods on first invocation\n\ >> 137: \ -Xdebug deprecated and may be removed in a future release.\n\ > > This drops "does nothing" so no longer clear that the option doesn't do anything. It could be changed to "does nothing; deprecated for removal in a future release". Alternatively maybe it would be better to just remove it from the -X output. Hello Alan, I updated the PR to use your suggested wording. I thought it's of no harm to let it be present in the -X output until we actually remove it (soon). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14918#discussion_r1266705837 From alanb at openjdk.org Tue Jul 18 16:56:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 16:56:15 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v4] In-Reply-To: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> References: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> Message-ID: On Tue, 18 Jul 2023 12:41:32 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion for -Xdebug output I think ParseArguments (in libjli/java.c) could be changed so that it doesn't translate -debug to -Xdebug, instead it can print a warning, like it does for -Xfuture. The reason is -debug is a java launcher option, it's not known to the VM and means that Arguments::parse_each_vm_init_arg doesn't need to mention -debug when it warns about -Xdebug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1640592323 From prr at openjdk.org Tue Jul 18 20:28:43 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 18 Jul 2023 20:28:43 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 [v2] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 01:43:43 GMT, Julian Waters wrote: >> After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missed specifier in awt_Toolkit.h I verified the build on our CI systems. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14899#pullrequestreview-1535854146 From serb at openjdk.org Tue Jul 18 21:10:44 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Jul 2023 21:10:44 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 [v2] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 01:43:43 GMT, Julian Waters wrote: >> After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missed specifier in awt_Toolkit.h Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14899#pullrequestreview-1535908214 From serb at openjdk.org Tue Jul 18 21:48:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Jul 2023 21:48:48 GMT Subject: Integrated: 6211202: ColorSpace.getInstance(int): IAE is not specified In-Reply-To: <-pvkexKT2T0O8y3TQ1wrdkrUoaj_Tw6Aq1YDR1ILHWg=.37c193da-4a87-4482-bd40-a64520b9cacc@github.com> References: <-pvkexKT2T0O8y3TQ1wrdkrUoaj_Tw6Aq1YDR1ILHWg=.37c193da-4a87-4482-bd40-a64520b9cacc@github.com> Message-ID: On Thu, 13 Jul 2023 05:13:45 GMT, Sergey Bylokhov wrote: > * Added @throws IllegalArgumentException to the specification of java.awt.color.ColorSpace.getInstance(int) > * Deleted duplicate text about IllegalArgumentException from the java.awt.color.ICC_Profile.getInstance(int) This pull request has now been integrated. Changeset: 7d9f5afe Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/7d9f5afea12e3d1a901a95ee8bf5d2d743893970 Stats: 20 lines in 3 files changed: 15 ins; 1 del; 4 mod 6211202: ColorSpace.getInstance(int): IAE is not specified Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/14860 From serb at openjdk.org Tue Jul 18 21:53:50 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Jul 2023 21:53:50 GMT Subject: Integrated: 6211126: ICC_ColorSpace.toCIEXYZ(float[]): NPE is not specified In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 00:52:50 GMT, Sergey Bylokhov wrote: > The specification of some methods has been updated to include current behaviour on null. This pull request has now been integrated. Changeset: e31df3a7 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/e31df3a7748fc36a8afe6e060917de1247bbd39b Stats: 192 lines in 8 files changed: 180 ins; 0 del; 12 mod 6211126: ICC_ColorSpace.toCIEXYZ(float[]): NPE is not specified 6211139: ICC_ColorSpace.toRGB(float[]): NPE is not specified Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/14821 From duke at openjdk.org Tue Jul 18 22:57:41 2023 From: duke at openjdk.org (Gabriel) Date: Tue, 18 Jul 2023 22:57:41 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 08:24:44 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1640700280 From serb at openjdk.org Tue Jul 18 23:17:54 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Jul 2023 23:17:54 GMT Subject: RFR: 8312191: ColorConvertOp.filter for the default destination is too slow Message-ID: I have found that MTPerLineTransformValidation - one of our slowest stress tests spends most of the time not in the code related to the colors conversion(as it was intended) but in the initialization of the native cmm-transforms. ColorConvertOp sharedOp = new ColorConvertOp(srcCS, dstCS, null); <-- slow BufferedImage dst = sharedOp.filter(src, null); The code above triggers the next sequence: 1. The destination buffered image is not set so it should be created [automatically](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L551) ->> 2. The buffered image requires the new color [model](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L588) ->> 3. The color model requires new color [space](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L563) ->> 4. The color model initialize some [LUTs](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorModel.java#L1816), **and cache it per color space** ->> 5. When the ColorConvertOp is used for the first time the color space caches some state internally if the format of the src/dst image is not changed So the critical thing above is to minimize the creation of the new color spaces, since for each new space all optimizations above should be repeated. Unfortunately, when we create the ColorConvertOp using standard icc_profile/icc_colorspace we store the profile only and [lost](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L150) the reference to the initial color space. And when later we decide to create a color model we create the new icc_color space->all optimizations resets. We do not save the reference to the color space because that way we distinguish the icc_colorspace saved using profiles, and non-icc_color spaces used as is. I think all that code should be reworked to take into account the current issue. But for now, we can fix it at least for standard types. **Important notes**: * Performance of MTPerLineTransformValidation test is increased(on my system from 3m30s to the 14s) - the number of used native transforms changed from 80000 to ~500. It can have a side effect since a few crashes(exit code 134) were reported for this test. The crashes of this test and others may disappear since the memory pressure is decreased, or the number of crashes can increase because the code for transforming will be executed in parallel more often. * The patch also affects the noop color conversion when the color space of the src and dst are the same, for example, if both are SRGB then: cmm ------------- Commit messages: - 8312191: ColorConvertOp.filter for the default destination is too slow Changes: https://git.openjdk.org/jdk/pull/14910/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14910&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312191 Stats: 82 lines in 2 files changed: 80 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14910/head:pull/14910 PR: https://git.openjdk.org/jdk/pull/14910 From serb at openjdk.org Wed Jul 19 00:09:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 19 Jul 2023 00:09:48 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 08:24:44 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp line 482: > 480: DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param) > 481: { > 482: ::CoInitializeEx(NULL, COINIT_MULTITHREADED); The documentation for the `CoInitializeEx` suggests to disable the `COINIT_DISABLE_OLE1DDE`: https://learn.microsoft.com/en-us/windows/win32/learnwin32/initializing-the-com-library I think we do not need ole1 here and can disable that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1267402244 From jwaters at openjdk.org Wed Jul 19 00:47:14 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 19 Jul 2023 00:47:14 GMT Subject: RFR: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 [v2] In-Reply-To: References: Message-ID: <036P_v7c_dOmkQyQXGQiAMCKNL4jumDmCuuvXZBSHFE=.e6322b9c-8750-4d99-b662-0aab983df625@github.com> On Tue, 18 Jul 2023 01:43:43 GMT, Julian Waters wrote: >> After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missed specifier in awt_Toolkit.h Thanks all for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/14899#issuecomment-1641205938 From jwaters at openjdk.org Wed Jul 19 00:47:14 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 19 Jul 2023 00:47:14 GMT Subject: Integrated: 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 06:45:59 GMT, Julian Waters wrote: > After [JDK-8311380](https://bugs.openjdk.org/browse/JDK-8311380), the dynamic exception specification warning pragma can be removed This pull request has now been integrated. Changeset: 702fea8d Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/702fea8deb41fa6a4537dbda18d7d965c3752163 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod 8312147: Dynamic Exception Specification warnings are no longer required after JDK-8311380 Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/14899 From jpai at openjdk.org Wed Jul 19 07:05:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 07:05:51 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v5] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestion - report -debug usage as a warning right in the java.c code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14918/files - new: https://git.openjdk.org/jdk/pull/14918/files/78498068..b6c867b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From jpai at openjdk.org Wed Jul 19 07:10:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 07:10:42 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v4] In-Reply-To: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> References: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> Message-ID: <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com> On Tue, 18 Jul 2023 12:41:32 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion for -Xdebug output Hello Alan, > I think ParseArguments (in libjli/java.c) could be changed so that it doesn't translate -debug to -Xdebug, instead it can print a warning, like it does for -Xfuture. The reason is -debug is a java launcher option, it's not known to the VM and means that Arguments::parse_each_vm_init_arg doesn't need to mention -debug when it warns about -Xdebug. I had initially considered that but had noticed that there's a small difference between the generic warning message "Warning: %s option is deprecated and may be removed in a future release." printed by the launcher and the one printed by the VM "OpenJDK 64-Bit Server VM warning: Option -Xdebug was deprecated in JDK 22 and will likely be removed in a future release." But I think that small difference in the warning messages is OK when considered against your stated reasoning that `-debug` isn't known to the VM. I've now updated the PR to implement your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641532218 From jpai at openjdk.org Wed Jul 19 07:10:44 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 07:10:44 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v5] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - report -debug usage as a warning right in the java.c code Adding one of my previous comments again, because it's not easily visible among the bot generated comments in the GitHub UI: > I would like inputs on the test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test launches java passing it the -Xdebug option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641534305 From alanb at openjdk.org Wed Jul 19 08:00:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 08:00:43 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v5] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 07:07:40 GMT, Jaikiran Pai wrote: > I would like inputs on the test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test launches java passing it the -Xdebug option and was introduced as part of https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug has been a no-op for many releases now. Is this test still relevant and if not, should I go ahead and remove it as part of this change? The SDE class file attribute supports debugging of other languages (see JSR-45). The VM usually skips it but it has to save the bytes when a JVMTI agent has the can_get_source_debug_extension capability enabled. The debugger agent enables this capability so running with -agentlib:jdwp is enough to ensure that it is read. The -Xdebug option can be dropped from the test but otherwise I think leave it in place as it exercises a SDE that is >64k. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641606804 From alanb at openjdk.org Wed Jul 19 08:04:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 08:04:42 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v5] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - report -debug usage as a warning right in the java.c code Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1536495911 From alanb at openjdk.org Wed Jul 19 08:04:44 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 08:04:44 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v4] In-Reply-To: <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com> References: <54o5-4Raq5oX93gQrI_hfTjwiLVJGWzSBmE8VtTvK9g=.cb4c9df8-6a17-473f-9f47-6747303ba8fe@github.com> <-J8iaBQKogoLygjEnE5-2C7ZOWtWvP6EVchg1gyEblQ=.a25ca7ca-edb6-43ea-9d99-fe647aaa51eb@github.com> Message-ID: On Wed, 19 Jul 2023 07:05:45 GMT, Jaikiran Pai wrote: > I had initially considered that but had noticed that there's a small difference between the generic warning message "Warning: %s option is deprecated and may be removed in a future release." printed by the launcher and the one printed by the VM "OpenJDK 64-Bit Server VM warning: Option -Xdebug was deprecated in JDK 22 and will likely be removed in a future release." But I think that small difference in the warning messages is OK when considered against your stated reasoning that `-debug` isn't known to the VM. The different deprecation messages is a bit annoying but I think it's better than the VM printing a warning for an option that was never possible to specify to JNI CreateJavaVM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14918#issuecomment-1641612439 From jpai at openjdk.org Wed Jul 19 10:58:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 10:58:58 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v6] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: remove -Xdebug usage from SourceDebugExtension test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14918/files - new: https://git.openjdk.org/jdk/pull/14918/files/b6c867b0..79c48cb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14918&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14918/head:pull/14918 PR: https://git.openjdk.org/jdk/pull/14918 From cjplummer at openjdk.org Wed Jul 19 19:23:05 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Jul 2023 19:23:05 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v6] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove -Xdebug usage from SourceDebugExtension test Nice cleanup! Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1537863690 From azvegint at openjdk.org Thu Jul 20 00:46:50 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 00:46:50 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 04:59:30 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 807: > 805: insLog.fine(xe.toString()); > 806: } > 807: checkIfOnNewScreen(new Rectangle(scaleDown(xe.get_x()), After the fix I am unable to create a translucent window on a second screen. (you can reproduce it with your test) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1268816039 From serb at openjdk.org Thu Jul 20 01:32:52 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 20 Jul 2023 01:32:52 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v3] In-Reply-To: References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Fri, 14 Jul 2023 14:44:57 GMT, Alexander Scherbatiy wrote: >> To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: >> >> java JavaSidesAttributePrinting ONE_SIDED >> java JavaSidesAttributePrinting DUPLEX >> >> >> The sample calls PrinterJob print method with the given sides attribute. >> The pages are printed according to the printer default settings not according to the provided Sides attributes. >> >> The fix propagates Sides attribute >> - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method >> - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Local supportedSides variable is used insted of supportedSides field src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 531: > 529: } > 530: > 531: int sides = (*env)->CallIntMethod(env, srcPrinterJob, jm_getSides); it seems the code around uses the "java" types like jint. >jint copies = (*env)->CallIntMethod(env, srcPrinterJob, jm_getCopies); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14727#discussion_r1268835976 From serb at openjdk.org Thu Jul 20 01:46:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 20 Jul 2023 01:46:48 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: Message-ID: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> On Wed, 5 Jul 2023 17:45:35 GMT, Abhishek Kumar wrote: >> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. >> >> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. >> >> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. >> >> CI link is posted in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Add condition to check JLabel instance src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 233: > 231: rendererPane.paintComponent(g, c, this, left, top, cWidth, height, shouldValidate); // h - (insets.top + insets.bottom) ); > 232: > 233: // fix for 8283214 we usually do not mention the bugid in the comments, it can be found in the git history, just describe why it is needed. src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 242: > 240: ac.setAccessibleName(label.getText()); > 241: } > 242: } How it will work in other L&Fs? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1133: > 1131: if ( popup instanceof Accessible accessiblePopup) { > 1132: AccessibleContext ac = accessiblePopup.getAccessibleContext(); > 1133: ac.setAccessibleParent(comboBox); do we need to reset it back at some point? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1268840292 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1268841214 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1268842498 From serb at openjdk.org Thu Jul 20 01:46:50 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 20 Jul 2023 01:46:50 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 13:35:20 GMT, Alexey Ivanov wrote: >> I think it is not needed to return 1 from `getAccessibleChildrenCount(...)`. `getAccessibleChildrenCount(...)` is used to get the exact number of accessible child for a component and afterwards `getAccessibleChild(..., index)` method can be invoked to get the child. >> >> It should be ok to return null if the switch case condition fails or index doesn't match with case statement. Although chances of returning null is very unlikely for index 0 and 1. > > I tend to agree? there are now two children; if the condition in `getAccessibleChild` fails, it returns `null`. Nothing has changed, there's a possibility that it would return `null`. Yet it shouldn't because both editor and button implement `Accessible`. please double-check how it will work in Windows, it might be possible that jaws expects 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1268842174 From dholmes at openjdk.org Thu Jul 20 02:52:43 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Jul 2023 02:52:43 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v6] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove -Xdebug usage from SourceDebugExtension test Sorry for being late to the party :) Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1538335630 From duke at openjdk.org Thu Jul 20 03:39:03 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 20 Jul 2023 03:39:03 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Observations : > 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). > 2. For Play back device always loading proper device GUID irrespective of com Initialization. > > Test: > Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. > To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. > > Please review the changes and let me know your comments if any. > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Disabled OLE1 from CoInit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14898/files - new: https://git.openjdk.org/jdk/pull/14898/files/98106e99..0999df8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14898/head:pull/14898 PR: https://git.openjdk.org/jdk/pull/14898 From duke at openjdk.org Thu Jul 20 03:41:41 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 20 Jul 2023 03:41:41 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: Message-ID: <7GH28GHKrzjqadFV69fhe6JfYpF5w9hmwHP5wVU7oSo=.c96b9d4d-39cc-476b-a306-ad8a38d3d540@github.com> On Wed, 19 Jul 2023 00:07:05 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright year > > src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp line 482: > >> 480: DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param) >> 481: { >> 482: ::CoInitializeEx(NULL, COINIT_MULTITHREADED); > > The documentation for the `CoInitializeEx` suggests to disable the `COINIT_DISABLE_OLE1DDE`: > https://learn.microsoft.com/en-us/windows/win32/learnwin32/initializing-the-com-library > > I think we do not need ole1 here and can disable that. @mrserb, thank you for your review I have disabled ole1 by adding the flag `COINIT_DISABLE_OLE1DDE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1268894199 From tr at openjdk.org Thu Jul 20 03:51:41 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 20 Jul 2023 03:51:41 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: <-yFGTkcI2Y-gJAd9X_RBwcERkCnxQNKFZy9gJPdOD0k=.6390a3f7-4b06-4b97-95ed-e98c2dc58d36@github.com> On Thu, 20 Jul 2023 00:43:54 GMT, Alexander Zvegintsev wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 807: > >> 805: insLog.fine(xe.toString()); >> 806: } >> 807: checkIfOnNewScreen(new Rectangle(scaleDown(xe.get_x()), > > After the fix I am unable to create a translucent window on a second screen. (you can reproduce it with your test) Yeah, with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix the transparency issue is resolved. So this bug focus on the correcting the opaque window seen in default (Starting from half of default screen). As highlighted in the below image. ![image](https://github.com/openjdk/jdk/assets/94159358/ebf45077-5308-4e43-a265-2026ef198e11) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1268900952 From tr at openjdk.org Thu Jul 20 09:48:12 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 20 Jul 2023 09:48:12 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left Message-ID: Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. ------------- Commit messages: - Fix + Automated Test Changes: https://git.openjdk.org/jdk/pull/14949/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6442919 Stats: 85 lines in 2 files changed: 85 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14949/head:pull/14949 PR: https://git.openjdk.org/jdk/pull/14949 From azvegint at openjdk.org Thu Jul 20 12:16:44 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 12:16:44 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: <-yFGTkcI2Y-gJAd9X_RBwcERkCnxQNKFZy9gJPdOD0k=.6390a3f7-4b06-4b97-95ed-e98c2dc58d36@github.com> References: <-yFGTkcI2Y-gJAd9X_RBwcERkCnxQNKFZy9gJPdOD0k=.6390a3f7-4b06-4b97-95ed-e98c2dc58d36@github.com> Message-ID: <-e3T9vVCsUUvU2zfKCHHlxLJE3yEM6GvyA65yb22mOo=.c14df4a4-ec94-4747-b9e7-5dad474aef6a@github.com> On Thu, 20 Jul 2023 03:49:16 GMT, Tejesh R wrote: >> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 807: >> >>> 805: insLog.fine(xe.toString()); >>> 806: } >>> 807: checkIfOnNewScreen(new Rectangle(scaleDown(xe.get_x()), >> >> After the fix I am unable to create a translucent window on a second screen. (you can reproduce it with your test) > > Yeah, with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix the transparency issue is resolved. So this bug focus on the correcting the opaque window seen in default (Starting from half of default screen). As highlighted in the below image. > ![image](https://github.com/openjdk/jdk/assets/94159358/ebf45077-5308-4e43-a265-2026ef198e11) I see, just the TejeshR13:branch_8280482(from this PR) branch does not contain JDK-8006421 fix. That's why I observed this behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269372134 From azvegint at openjdk.org Thu Jul 20 13:24:45 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 13:24:45 GMT Subject: RFR: 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS Message-ID: This test fails in macOS 13, making the CI noise. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/14956/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14956&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312459 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14956/head:pull/14956 PR: https://git.openjdk.org/jdk/pull/14956 From psadhukhan at openjdk.org Thu Jul 20 13:36:40 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Jul 2023 13:36:40 GMT Subject: RFR: 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:17:48 GMT, Alexander Zvegintsev wrote: > This test fails in macOS 13, making the CI noise. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14956#pullrequestreview-1539281573 From azvegint at openjdk.org Thu Jul 20 13:39:50 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 13:39:50 GMT Subject: Integrated: 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:17:48 GMT, Alexander Zvegintsev wrote: > This test fails in macOS 13, making the CI noise. This pull request has now been integrated. Changeset: fe419101 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/fe419101411d47f81f2dc5f95605308780302fcb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/14956 From azvegint at openjdk.org Thu Jul 20 14:13:49 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 14:13:49 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 04:59:30 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 45: > 43: * @bug 8280482 > 44: * @key headful > 45: * @requires (os.family == "linux") Did you check it on other systems? What prevents this test to be available on all systems? test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 46: > 44: * @key headful > 45: * @requires (os.family == "linux") > 46: * @library /java/awt/regtesthelpers Is the regtesthepers actually being used? test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 62: > 60: createGUI(); > 61: } finally { > 62: for (Window win : windowList) { Looks like you don't wait for possible `graphicsConfiguration` change events to come here, and start closing all windows. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 98: > 96: }); > 97: > 98: Thread.sleep(100); I think that we can show all the windows at once without this delay to speed up the test execution. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 116: > 114: windowList.add(window); > 115: > 116: window.addPropertyChangeListener("graphicsConfiguration", Probably it is worth adding the listener before calling `setVisible`. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 128: > 126: //Check if GC is changed for windows positioned in screen 0. > 127: > 128: if (windowXPos < screen1Width) { This type of check fails for following display arrangement ![image](https://github.com/openjdk/jdk/assets/77687766/e2881415-9ecd-4695-bcc0-2dc98ccd382e) I suggest to check if window's GraphicsConfiguration is associated with correct screen device (e.g. check if the window bounds within the `window.getGraphicsConfiguration().getDevice().getBounds()`). It also seems more reliable to me if we don't check the GraphicsConfiguration only within the `graphicsConfiguration` change event, but unconditionally after some delay after the window is displayed (in case the event doesn't occur). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269501381 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269413142 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269505202 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269519493 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269475424 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269410573 From tr at openjdk.org Thu Jul 20 15:32:43 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 20 Jul 2023 15:32:43 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:55:43 GMT, Alexander Zvegintsev wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 45: > >> 43: * @bug 8280482 >> 44: * @key headful >> 45: * @requires (os.family == "linux") > > Did you check it on other systems? What prevents this test to be available on all systems? Didn't check on other systems, since the fix is in X11. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269637734 From serb at openjdk.org Thu Jul 20 15:55:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 20 Jul 2023 15:55:48 GMT Subject: RFR: 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:17:48 GMT, Alexander Zvegintsev wrote: > This test fails in macOS 13, making the CI noise. Both bugs mentioned in the problemlist do not have any references/logs about macos x64 please attach it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14956#issuecomment-1644177340 From duke at openjdk.org Thu Jul 20 16:01:59 2023 From: duke at openjdk.org (duke) Date: Thu, 20 Jul 2023 16:01:59 GMT Subject: Withdrawn: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:16:19 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776) > > This is tracked in JBS as > - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776) > > Adds the 4 and 8 digits color hex notations to CSS.java, as described in : > CSS Color Module Level 4 > W3C Candidate Recommendation Snapshot, 5 July 2022 > [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation) > > Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10317 From duke at openjdk.org Thu Jul 20 16:05:10 2023 From: duke at openjdk.org (duke) Date: Thu, 20 Jul 2023 16:05:10 GMT Subject: Withdrawn: JDK-8292276 : Add named colors from CSS Color Module Level 4 In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 20:00:29 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) > > This is tracked in JBS as > - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276) > > Adds missing color names, defined by CSS Level 4, in CSS.java : > CSS Color Module Level 4 > W3C Candidate Recommendation Snapshot, 5 July 2022 > [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color) > > Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9825 From azvegint at openjdk.org Thu Jul 20 16:32:58 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 16:32:58 GMT Subject: RFR: 8312459: Problem list java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java for macOS In-Reply-To: References: Message-ID: <8XOcGLx5uhtzsRRjBDV8yCwehDNER_duafVAp5PreS0=.f69dc12d-68d1-4a18-a133-9fe78b1578c7@github.com> On Thu, 20 Jul 2023 15:52:37 GMT, Sergey Bylokhov wrote: > Both bugs mentioned in the problemlist do not have any references/logs about macos x64 please attach it. It does not differ from the jtr file from windows attached to 7099223, but I added in a comment. As for the 8274106, I have no logs for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14956#issuecomment-1644233004 From tr at openjdk.org Thu Jul 20 17:35:42 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 20 Jul 2023 17:35:42 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 12:46:39 GMT, Alexander Zvegintsev wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 128: > >> 126: //Check if GC is changed for windows positioned in screen 0. >> 127: >> 128: if (windowXPos < screen1Width) { > > This type of check fails for following display arrangement > ![image](https://github.com/openjdk/jdk/assets/77687766/e2881415-9ecd-4695-bcc0-2dc98ccd382e) > > I suggest to check if window's GraphicsConfiguration is associated with correct screen device > (e.g. check if the window bounds within the `window.getGraphicsConfiguration().getDevice().getBounds()`). > > It also seems more reliable to me if we don't check the GraphicsConfiguration only within the `graphicsConfiguration` change event, but unconditionally after some delay after the window is displayed (in case the event doesn't occur). _I suggest to check if window's GraphicsConfiguration is associated with correct screen device (e.g. check if the window bounds within the window.getGraphicsConfiguration().getDevice().getBounds())._ I didn't get this suggestion. Does it means to compare GC or the position of every `window` with corresponding `window.getGraphicsConfiguration().getBounds()`.......? `window.getGraphicsConfiguration().getBounds()` shows same for all the windows, either in primary/secondary monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269767136 From azvegint at openjdk.org Thu Jul 20 19:23:40 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Jul 2023 19:23:40 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: <18CgGenQq2sp6wFEzg_h4QTdq5hto5KXwHjg-yeEPR4=.39e54bc6-3a5d-4e3c-992f-7540dce5ed7f@github.com> On Thu, 20 Jul 2023 17:32:13 GMT, Tejesh R wrote: > shows same for all the windows, either in primary/secondary monitor. For me it is not true: [GCBounds.java.txt](https://github.com/openjdk/jdk/files/12113425/GCBounds.java.txt) > Screen bounds java.awt.Rectangle[x=0,y=0,width=2560,height=1440] Frame gc bounds: java.awt.Rectangle[x=0,y=0,width=2560,height=1440] Screen bounds java.awt.Rectangle[x=2560,y=0,width=1920,height=1200] Frame gc bounds: java.awt.Rectangle[x=2560,y=0,width=1920,height=1200] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1269873449 From serb at openjdk.org Fri Jul 21 03:35:44 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 21 Jul 2023 03:35:44 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 09:40:41 GMT, Tejesh R wrote: > Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). > The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java line 51: > 49: UIManager.getInstalledLookAndFeels()) { > 50: String className = laf.getName().toLowerCase(); > 51: if (className.contains("motif") || className.contains("mac")) { The test does not have a headful keyword so in the CI it was tested on a headless system where the GTK l&f is unsupported. Please double-check - do we need to skip it here or not? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270192494 From serb at openjdk.org Fri Jul 21 03:38:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 21 Jul 2023 03:38:48 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 03:39:03 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Disabled OLE1 from CoInit Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14898#pullrequestreview-1540413483 From tr at openjdk.org Fri Jul 21 03:42:39 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 03:42:39 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left In-Reply-To: References: Message-ID: <8KM_cw64gdQ_srKLZXktsQ01bMRp9oTtXEMiZqd8jFU=.de937282-8353-4b76-a7a7-d19eca521079@github.com> On Fri, 21 Jul 2023 03:32:58 GMT, Sergey Bylokhov wrote: >> Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). >> The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. > > test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java line 51: > >> 49: UIManager.getInstalledLookAndFeels()) { >> 50: String className = laf.getName().toLowerCase(); >> 51: if (className.contains("motif") || className.contains("mac")) { > > The test does not have a headful keyword so in the CI it was tested on a headless system where the GTK l&f is unsupported. Please double-check - do we need to skip it here or not? Yeah, I can see from log that it is unsupported. I will skip it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270195003 From serb at openjdk.org Fri Jul 21 03:42:56 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 21 Jul 2023 03:42:56 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 23:53:16 GMT, Harshitha Onkar wrote: >I don't think it is applicable for mouse clicks, as the issue (details below) occurs only when flagState is obtained using - CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState) which was the case for keyEvents. I can double-check on this again. yes, please. if the physical mouse movement causes the "event flags" to be reset, then what about "event flags" for mouse events ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1644939509 From tr at openjdk.org Fri Jul 21 03:56:03 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 03:56:03 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v2] In-Reply-To: References: Message-ID: > Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). > The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Skip GTK L&F ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14949/files - new: https://git.openjdk.org/jdk/pull/14949/files/5c304bdb..6578d8a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14949&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14949&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14949/head:pull/14949 PR: https://git.openjdk.org/jdk/pull/14949 From tr at openjdk.org Fri Jul 21 03:56:03 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 03:56:03 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v2] In-Reply-To: <8KM_cw64gdQ_srKLZXktsQ01bMRp9oTtXEMiZqd8jFU=.de937282-8353-4b76-a7a7-d19eca521079@github.com> References: <8KM_cw64gdQ_srKLZXktsQ01bMRp9oTtXEMiZqd8jFU=.de937282-8353-4b76-a7a7-d19eca521079@github.com> Message-ID: On Fri, 21 Jul 2023 03:39:53 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java line 51: >> >>> 49: UIManager.getInstalledLookAndFeels()) { >>> 50: String className = laf.getName().toLowerCase(); >>> 51: if (className.contains("motif") || className.contains("mac")) { >> >> The test does not have a headful keyword so in the CI it was tested on a headless system where the GTK l&f is unsupported. Please double-check - do we need to skip it here or not? > > Yeah, I can see from log that it is unsupported. I will skip it. The fix doesn't apply to GTK too, thanks for pointing it out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270199239 From dnguyen at openjdk.org Fri Jul 21 06:27:55 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 21 Jul 2023 06:27:55 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 03:56:03 GMT, Tejesh R wrote: >> Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). >> The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Skip GTK L&F src/java.desktop/share/classes/sun/swing/FilePane.java line 1936: > 1934: } > 1935: > 1936: contextMenu.applyComponentOrientation(getFileChooser().getComponentOrientation()); I see that this bug is old. Seems like a simple way to fix this and I see similar calls for other UI elements, like JMenu. It looks like in JMenu, it iterates through all components and sets it orientation, but it looks like the popup is the only problem, so looks fine. You still need to update the year in the header of FilePane. test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java line 76: > 74: try { > 75: UIManager.setLookAndFeel(laf.getClassName()); > 76: System.out.println("Set L&F : "+laf.getName()); Suggestion: System.out.println("Set L&F : " + laf.getName()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270269782 PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270269958 From tr at openjdk.org Fri Jul 21 07:00:08 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 07:00:08 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v3] In-Reply-To: References: Message-ID: > Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). > The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14949/files - new: https://git.openjdk.org/jdk/pull/14949/files/6578d8a3..41811eb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14949&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14949&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14949/head:pull/14949 PR: https://git.openjdk.org/jdk/pull/14949 From tr at openjdk.org Fri Jul 21 07:00:08 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 07:00:08 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v2] In-Reply-To: References: Message-ID: <2p2_w9fTGSVhDwfjOflj12QpbOeki5_mMrYB6P4X3KU=.c9afcd87-eae8-4384-86bf-0e6dd0a43702@github.com> On Fri, 21 Jul 2023 06:23:29 GMT, Damon Nguyen wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip GTK L&F > > src/java.desktop/share/classes/sun/swing/FilePane.java line 1936: > >> 1934: } >> 1935: >> 1936: contextMenu.applyComponentOrientation(getFileChooser().getComponentOrientation()); > > I see that this bug is old. Seems like a simple way to fix this and I see similar calls for other UI elements, like JMenu. It looks like in JMenu, it iterates through all components and sets it orientation, but it looks like the popup is the only problem, so looks fine. > > You still need to update the year in the header of FilePane. Yeah, `applyComponentOrientation ` iterates through all the child components and sets the orientation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14949#discussion_r1270292308 From tr at openjdk.org Fri Jul 21 08:08:04 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 08:08:04 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: References: Message-ID: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Copywrite year update - Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/eff75632..327d2b5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=01-02 Stats: 79 lines in 2 files changed: 28 ins; 38 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From tr at openjdk.org Fri Jul 21 08:10:44 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 08:10:44 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 12:48:54 GMT, Alexander Zvegintsev wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 46: > >> 44: * @key headful >> 45: * @requires (os.family == "linux") >> 46: * @library /java/awt/regtesthelpers > > Is the regtesthepers actually being used? Removed. > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 62: > >> 60: createGUI(); >> 61: } finally { >> 62: for (Window win : windowList) { > > Looks like you don't wait for possible `graphicsConfiguration` change events to come here, and start closing all windows. Since GC change event is removed now and also added some delay. > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 98: > >> 96: }); >> 97: >> 98: Thread.sleep(100); > > I think that we can show all the windows at once without this delay to speed up the test execution. Removed. Also No need to test for full screen I guess, just the top row checking will be fine I guess. Updated the test to check only for top row. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270364344 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270365563 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270367132 From tr at openjdk.org Fri Jul 21 08:10:46 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 08:10:46 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: <18CgGenQq2sp6wFEzg_h4QTdq5hto5KXwHjg-yeEPR4=.39e54bc6-3a5d-4e3c-992f-7540dce5ed7f@github.com> References: <18CgGenQq2sp6wFEzg_h4QTdq5hto5KXwHjg-yeEPR4=.39e54bc6-3a5d-4e3c-992f-7540dce5ed7f@github.com> Message-ID: On Thu, 20 Jul 2023 19:20:52 GMT, Alexander Zvegintsev wrote: >> _I suggest to check if window's GraphicsConfiguration is associated with correct screen device >> (e.g. check if the window bounds within the window.getGraphicsConfiguration().getDevice().getBounds())._ >> I didn't get this suggestion. Does it means to compare GC or the position of every `window` with corresponding `window.getGraphicsConfiguration().getBounds()`.......? `window.getGraphicsConfiguration().getBounds()` shows same for all the windows, either in primary/secondary monitor. > >> shows same for all the windows, either in primary/secondary monitor. > > For me it is not true: > > [GCBounds.java.txt](https://github.com/openjdk/jdk/files/12113425/GCBounds.java.txt) > >> Screen bounds java.awt.Rectangle[x=0,y=0,width=2560,height=1440] > Frame gc bounds: java.awt.Rectangle[x=0,y=0,width=2560,height=1440] > Screen bounds java.awt.Rectangle[x=2560,y=0,width=1920,height=1200] > Frame gc bounds: java.awt.Rectangle[x=2560,y=0,width=1920,height=1200] Looks like I was checking for `window.getGraphicsConfiguration().getBounds()` right after making it visible, waiting for the events to finish up gives right values. I have updated the test and validation is moved outside the GC change event. Tested multiple times and the test looks fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270364023 From azvegint at openjdk.org Fri Jul 21 09:40:53 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 21 Jul 2023 09:40:53 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 08:08:21 GMT, Tejesh R wrote: > Also No need to test for full screen I guess, just the top row checking will be fine I guess. This area is very dependent from screen arrangement: ![image](https://github.com/openjdk/jdk/assets/77687766/79fe8b04-7cdf-493b-bf2d-2f653d1af134) ![image](https://github.com/openjdk/jdk/assets/77687766/0cc5a552-a437-4a40-bfe8-20dbf8ba43fd) ![image](https://github.com/openjdk/jdk/assets/77687766/994c0ca0-c28f-482d-81e8-f21a9c7e9af7) ![image](https://github.com/openjdk/jdk/assets/77687766/7662602f-1f4e-421f-8cc1-25524049e133) ![image](https://github.com/openjdk/jdk/assets/77687766/86978049-b385-48ee-8058-ab8a9dbb3eb2) ![image](https://github.com/openjdk/jdk/assets/77687766/1255b7ec-2e3b-4a5e-ae36-0ca59462843a) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270473696 From tr at openjdk.org Fri Jul 21 09:48:41 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 09:48:41 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 09:37:54 GMT, Alexander Zvegintsev wrote: >> Removed. Also No need to test for full screen I guess, just the top row checking will be fine I guess. Updated the test to check only for top row. > >> Also No need to test for full screen I guess, just the top row checking will be fine I guess. > > This area is very dependent from screen arrangement: > > ![image](https://github.com/openjdk/jdk/assets/77687766/79fe8b04-7cdf-493b-bf2d-2f653d1af134) > > ![image](https://github.com/openjdk/jdk/assets/77687766/0cc5a552-a437-4a40-bfe8-20dbf8ba43fd) > > > ![image](https://github.com/openjdk/jdk/assets/77687766/994c0ca0-c28f-482d-81e8-f21a9c7e9af7) > > ![image](https://github.com/openjdk/jdk/assets/77687766/7662602f-1f4e-421f-8cc1-25524049e133) > > ![image](https://github.com/openjdk/jdk/assets/77687766/86978049-b385-48ee-8058-ab8a9dbb3eb2) > ![image](https://github.com/openjdk/jdk/assets/77687766/1255b7ec-2e3b-4a5e-ae36-0ca59462843a) Ok, didn't try with these settings. Will check for full screen then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270481466 From tr at openjdk.org Fri Jul 21 09:57:11 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 09:57:11 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v4] In-Reply-To: References: Message-ID: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/327d2b5d..c9946e67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=02-03 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From azvegint at openjdk.org Fri Jul 21 09:57:11 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 21 Jul 2023 09:57:11 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:29:39 GMT, Tejesh R wrote: >> test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 45: >> >>> 43: * @bug 8280482 >>> 44: * @key headful >>> 45: * @requires (os.family == "linux") >> >> Did you check it on other systems? What prevents this test to be available on all systems? > > Didn't check on other systems, since the fix is in X11. So we should check this, just in case other systems have similar issues. (and remove the requires tag if there are no issues). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270476689 From azvegint at openjdk.org Fri Jul 21 09:57:12 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 21 Jul 2023 09:57:12 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 08:08:04 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Copywrite year update > - Review fix test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 113: > 111: } > 112: } else if (windowList.get(windowList.size() - 1).getBounds(). > 113: intersects(screens[1].getDefaultConfiguration().getBounds())) { What if user has more than 2 screens? It looks like the 3rd and subsequent screens are not tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270480983 From tr at openjdk.org Fri Jul 21 10:56:28 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 10:56:28 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v5] In-Reply-To: References: Message-ID: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/c9946e67..4e47192a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=03-04 Stats: 28 lines in 1 file changed: 9 ins; 14 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From tr at openjdk.org Fri Jul 21 10:56:30 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 10:56:30 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 09:40:33 GMT, Alexander Zvegintsev wrote: >> Didn't check on other systems, since the fix is in X11. > > So we should check this, just in case other systems have similar issues. > (and remove the requires tag if there are no issues). I verified with Windows and Mac, not issue found. Removing the linux specific tag and other unused tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270539216 From tr at openjdk.org Fri Jul 21 10:56:34 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Jul 2023 10:56:34 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 09:45:02 GMT, Alexander Zvegintsev wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Copywrite year update >> - Review fix > > test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 113: > >> 111: } >> 112: } else if (windowList.get(windowList.size() - 1).getBounds(). >> 113: intersects(screens[1].getDefaultConfiguration().getBounds())) { > > What if user has more than 2 screens? > It looks like the 3rd and subsequent screens are not tested. I have made the validation as per number of screens now. I guess this is fine to check multiple screens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1270540012 From jpai at openjdk.org Fri Jul 21 13:01:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 21 Jul 2023 13:01:49 GMT Subject: Integrated: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. > > As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. This pull request has now been integrated. Changeset: 842d6329 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/842d6329cf5a3da8df7eddb195b5fcb7baadbdc3 Stats: 41 lines in 25 files changed: 0 ins; 9 del; 32 mod 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 Reviewed-by: alanb, cjplummer, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/14918 From alexsch at openjdk.org Fri Jul 21 14:36:09 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 21 Jul 2023 14:36:09 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v4] In-Reply-To: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: > To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: > > java JavaSidesAttributePrinting ONE_SIDED > java JavaSidesAttributePrinting DUPLEX > > > The sample calls PrinterJob print method with the given sides attribute. > The pages are printed according to the printer default settings not according to the provided Sides attributes. > > The fix propagates Sides attribute > - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method > - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Change int type to jint for sides variable in CPrinterJob.m ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14727/files - new: https://git.openjdk.org/jdk/pull/14727/files/4480595c..e028ebff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14727/head:pull/14727 PR: https://git.openjdk.org/jdk/pull/14727 From alexsch at openjdk.org Fri Jul 21 14:55:45 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 21 Jul 2023 14:55:45 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v3] In-Reply-To: References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Thu, 20 Jul 2023 01:30:06 GMT, Sergey Bylokhov wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Local supportedSides variable is used insted of supportedSides field > > src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 531: > >> 529: } >> 530: >> 531: int sides = (*env)->CallIntMethod(env, srcPrinterJob, jm_getSides); > > it seems the code around uses the "java" types like jint. >>jint copies = (*env)->CallIntMethod(env, srcPrinterJob, jm_getCopies); Could you review the updated fix? `int` type is changed to `jint` for sides variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14727#discussion_r1270769489 From aivanov at openjdk.org Fri Jul 21 18:56:45 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 21 Jul 2023 18:56:45 GMT Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint [v3] In-Reply-To: References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com> Message-ID: On Mon, 17 Jul 2023 03:39:39 GMT, Jeremy wrote: > @aivanov-jdk IIRC this ticket (a P3) was initially assigned to you, and I asked to look at it instead. It looks like for now this PR is stalled, so please feel free to reassign the openJDK ticket (or make any other appropriate changes) if needed. @mickleness It's not assigned to me now. I can't even find that it was assigned to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14363#issuecomment-1646114611 From serb at openjdk.org Fri Jul 21 19:21:43 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 21 Jul 2023 19:21:43 GMT Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides attribute [v4] In-Reply-To: References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: On Fri, 21 Jul 2023 14:36:09 GMT, Alexander Scherbatiy wrote: >> To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: >> >> java JavaSidesAttributePrinting ONE_SIDED >> java JavaSidesAttributePrinting DUPLEX >> >> >> The sample calls PrinterJob print method with the given sides attribute. >> The pages are printed according to the printer default settings not according to the provided Sides attributes. >> >> The fix propagates Sides attribute >> - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method >> - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Change int type to jint for sides variable in CPrinterJob.m Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14727#pullrequestreview-1541717663 From abhiscxk at openjdk.org Fri Jul 21 19:36:48 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 21 Jul 2023 19:36:48 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> References: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> Message-ID: On Thu, 20 Jul 2023 01:41:46 GMT, Sergey Bylokhov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add condition to check JLabel instance > > src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 242: > >> 240: ac.setAccessibleName(label.getText()); >> 241: } >> 242: } > > How it will work in other L&Fs? In case of other LAFs except **Aqua** in MacOS, the accessible component invoked for screen magnifier is an instance of `AccessibleJComboBox` and subsequently the a11y API called on `AccessibleJComboBox` to return the accessible name. But for aqua, the accessible component invoked for screen magnifier is an instance for `AquaComboBoxButton`, so it is required to return the accessible button instance for a11y APIs to get called for retrieving accessible name. > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1133: > >> 1131: if ( popup instanceof Accessible accessiblePopup) { >> 1132: AccessibleContext ac = accessiblePopup.getAccessibleContext(); >> 1133: ac.setAccessibleParent(comboBox); > > do we need to reset it back at some point? I don't think so, as comboBox is the accessible parent for popup. Moreover, this piece of code is unchanged for the current fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1271014965 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1271015991 From abhiscxk at openjdk.org Fri Jul 21 19:42:00 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 21 Jul 2023 19:42:00 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: > The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. > > Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. > > Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. > > CI link is posted in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: bugid removed in comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14497/files - new: https://git.openjdk.org/jdk/pull/14497/files/47195a92..1686c546 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497 PR: https://git.openjdk.org/jdk/pull/14497 From abhiscxk at openjdk.org Fri Jul 21 19:42:02 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 21 Jul 2023 19:42:02 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> References: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> Message-ID: On Thu, 20 Jul 2023 01:39:59 GMT, Sergey Bylokhov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add condition to check JLabel instance > > src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 233: > >> 231: rendererPane.paintComponent(g, c, this, left, top, cWidth, height, shouldValidate); // h - (insets.top + insets.bottom) ); >> 232: >> 233: // fix for 8283214 > > we usually do not mention the bugid in the comments, it can be found in the git history, just describe why it is needed. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1271017933 From abhiscxk at openjdk.org Fri Jul 21 19:54:49 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 21 Jul 2023 19:54:49 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 19:42:00 GMT, Abhishek Kumar wrote: >> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. >> >> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. >> >> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. >> >> CI link is posted in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > bugid removed in comments > @mrserb please double-check how it will work in Windows, it might be possible that jaws expects 1. I will check this and update if there is any change in announcement with JAWS with this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1646171886 From duke at openjdk.org Fri Jul 21 20:10:46 2023 From: duke at openjdk.org (Jeremy) Date: Fri, 21 Jul 2023 20:10:46 GMT Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint [v3] In-Reply-To: References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com> Message-ID: <9f95-rSOOmF6IcA_7TVsgrZafNBpF47Owa3rs7eG0NI=.f7ecc724-8ef3-4486-b4e7-d3ab7d1db9ca@github.com> On Fri, 16 Jun 2023 23:16:53 GMT, Jeremy wrote: >> # Problem Summary >> >> For non-opaque windows, Window#paint calls `gg.fillRect(0, 0, getWidth(), getHeight())` before `super.paint(g)`. >> >> This can cause flickering on Mac, and the flickering seems to have gotten much worse in recent JVMs. (See movie attachments to original ticket.) >> >> # Discussion >> >> This is my 2nd PR for this ticket. The original is [here](https://github.com/openjdk/jdk/pull/12993); that proposed change was IMO more invasive/scarier. It was auto-closed after 8 weeks of inactivity, and I'd rather offer this PR instead. >> >> In that previous discussion Alan Snyder framed the core problem as a "lack of synchronization" (see [comment here](https://github.com/openjdk/jdk/pull/12993#issuecomment-1467528061)). If the monitor refreshes/flushes after we've called `fillRect` *but before we finish `super.paint`*: it makes sense that we'd see a flicker. >> >> I agree with Alan, but I think the problem can also be framed as a mixing-Swing-with-AWT issue. (Which IMO will involve an easier fix.) >> >> This PR is a low-risk change (relative to the previous PR) that intercepts calls to repaint a Window that is also RootPaneContainer. Now we'll redirect those calls to paint the JRootPane instead. This means we'll exclusively paint within Swing's/RepaintManager's double-buffered architecture, so we bypass the risky call to `fillRect` on the screen's Graphics2D. (And this change occurs within RepaintManager, so we're clearly already in Swing's architecture.) >> >> So with this change: we paint everything to the double-buffer, and the *only time* we paint to the Window's Graphics2D is when have set up a AlphaComposite.Src and replace its contents with our buffer's contents. >> >> # Tests >> >> This PR includes a new test for 8303950 itself. This is pretty self-explanatory: we repaint a trivial animation for a few seconds and use the Robot to see if a pixel is the expected color. >> >> This PR also includes a test called `bug8303950_legacyWindowPaintBehavior` that creates a grid of 4 windows with varying opacity/backgrounds: >> >> image >> >> I was surprised by how these windows rendered, but I don't think that's worth debating here. This test simply makes sure that we preserve this preexisting behavior. The broad "rules" appear to be: >> 1. If a JComponent identifies as opaque (see `JComponent.isOpaque`) then the JComponent's background is used. (I... > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8303950: removing unnecessary whitespace in unit test > > See https://github.com/openjdk/jdk/pull/14363#pullrequestreview-1484315506 OK, maybe I'm mistaken. Thanks for checking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14363#issuecomment-1646186252 From honkar at openjdk.org Fri Jul 21 21:12:45 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 21 Jul 2023 21:12:45 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 03:39:27 GMT, Sergey Bylokhov wrote: >> @mrserb >> >>> Just to clarify an idea of this change. We would like to maintain the "flag" keys pressed by the user and maintain the list of current flags. So if the user will press SHIFT key, we will use that modifier for all next keys until shift will be released. >> >> That is correct. >> >>> It looks similar to how the mouseMove is implemented in CRobot, where we maintain the mouseLastX/mouseLastY, and we ignore the current location of the mouse for clicks, but use the latest saved value. >> >> >>> Probably we can do the same on the java side in this patch? it will simplify the native code a bit. >> >> Yes, the code for mouseEvent looks similar to what we are trying to achieve for keyEvent but there are a few differences too- >> - `mouseEvent(int lastX, int lastY, int buttonsState, boolean isButtonsDownState, boolean isMouseMove)`, lastX & lastY are already part of the parameters being sent from Java to native side. >> >> - `keyEvent(int javaKeyCode, boolean keydown)` - Are you suggesting that a modifier flag state be sent from Java to native side? This would involve changing the present native `keyEvent` signature and adding code to native side to evaluate the new modifier flag state from Java and then map it to the corresponding [kCGEventFlagMask](https://developer.apple.com/documentation/coregraphics/cgeventflags/kcgeventflagmaskalphashift?language=objc). >> >> Having everything on native side seems to be easier because with the present fix, the equivalent modifier flag mask is obtained using javaKeyCode + key state and a quick `NSDictionary modifierKeyToMaskMap` lookup without the need of adding or changing keyEvent signature. >> >>> BTW do we need to set all this modifiers for the mouse clicks as well? >> >> I don't think it is applicable for mouse clicks, as the issue (details below) occurs only when flagState is obtained using - `CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState)` which was the case for keyEvents. I can double-check on this again. >> >> **Issue:** >> _With the original code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. The physical mouse movement causes the event flags to be reset._ > >>I don't think it is applicable for mouse clicks, as the issue (details below) occurs only when flagState is obtained using - CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState) which was the case for keyEvents. I can double-check on this again. > > yes, please. > if the physical mouse movement causes the "event flags" to be reset, then what about "event flags" for mouse events @mrserb > if the physical mouse movement causes the "event flags" to be reset, then what about "event flags" for mouse events Robot's mouse events are handled differently in comparison to keyEvents , mouse events are processed by going through `CRobot_mouseEvent` > `HandleRobotButton` > `PostMouseEvent` within CRobot.m. Current flag state of the event source is never queried for mouseEvents, so the issue of resetting of event flag does not occur. Moreover `initFlags` which is queried in initRobot is used within `CRobot_keyEvent` only. Additionally, I believe concurrent external manual mouse movement is not supported when Robot is performing mouse events. This would produce erroneous result. For example, running MouseLocationOnScreen.java test or any location related test with Robot + simultaneous external mouse movement will fail. So the question of handling physical external mouse movements during Robot's mouse events looks to be invalid or not applicable here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1646242299 From serb at openjdk.org Sat Jul 22 09:35:39 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 22 Jul 2023 09:35:39 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v3] In-Reply-To: References: Message-ID: <92ZZb4esgls0s4RuxbQE9sB8lIgGOH168dkVO2Qyypg=.8d555dbc-d178-48cd-b906-d5fe1e6227ad@github.com> On Fri, 21 Jul 2023 07:00:08 GMT, Tejesh R wrote: >> Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). >> The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14949#pullrequestreview-1542074541 From abhiscxk at openjdk.org Sun Jul 23 10:43:42 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Sun, 23 Jul 2023 10:43:42 GMT Subject: RFR: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left [v3] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 07:00:08 GMT, Tejesh R wrote: >> Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). >> The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by abhiscxk (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14949#pullrequestreview-1542226475 From serb at openjdk.org Sun Jul 23 22:01:00 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 23 Jul 2023 22:01:00 GMT Subject: RFR: 8312535: MidiSystem.getSoundbank() throws unexpected SecurityException Message-ID: * The doPrivileged block is added to fix SecurityException * The usage of the property moved to static, now the "change" of the property at runtime will not affect the code ------------- Commit messages: - Update GetSoundBankSecurityException.java - Update JARSoundbankReader.java - update bugid - rename test - Update JARSoundbankReader.java - test Changes: https://git.openjdk.org/jdk/pull/14986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312535 Stats: 66 lines in 3 files changed: 59 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14986/head:pull/14986 PR: https://git.openjdk.org/jdk/pull/14986 From serb at openjdk.org Mon Jul 24 00:42:02 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Jul 2023 00:42:02 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. [v6] In-Reply-To: References: Message-ID: <008EyQXLq0HU1oJC1c3YjwmVBqTT29FASv6I48hXsTw=.7b01979a-023c-4062-9f5a-cc19b845f776@github.com> On Fri, 23 Jun 2023 20:24:21 GMT, Alisen Chung wrote: >> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize >> All client tests passed after change > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added test cases, fixed spacing src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 989: > 987: synchronized (lock) { > 988: try { > 989: lock.wait(); Are we sure that waiting forever is a good thing? Can this request be ignored by the OS for any reason? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1271610554 From tr at openjdk.org Mon Jul 24 08:25:57 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 24 Jul 2023 08:25:57 GMT Subject: Integrated: 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 09:40:41 GMT, Tejesh R wrote: > Popup menu is created on mouse click, hence the orientation for FileChooser won't apply to the popup menu created. Hence the fix address the issue by applying the FileChooser orientation when it is created on mouse operation (Right Click). > The test does not apply to Motif and Aqua Look And Feel since right click is not supported on filePane of FileChooser, hence it is skipped. The fix is tested in CI and it is green. This pull request has now been integrated. Changeset: ab821aa2 Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/ab821aa24f248e042d367ccd908fc1f68ebe8333 Stats: 88 lines in 2 files changed: 87 ins; 0 del; 1 mod 6442919: JFilechooser popup still left-to-right when JFilechooser is set to right-to-left Reviewed-by: serb, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/14949 From psadhukhan at openjdk.org Mon Jul 24 09:25:50 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 09:25:50 GMT Subject: Integrated: 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 07:36:56 GMT, Prasanta Sadhukhan wrote: > Due to some threading issues, Progress Monitor is not shown in macos.. > Seems like we need to call ProgressMonitor swing component in EDT.. This pull request has now been integrated. Changeset: 197981b4 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/197981b431fb7c7e6740ac45a671b99d1c7583c6 Stats: 11 lines in 1 file changed: 6 ins; 1 del; 4 mod 8311881: jdk/javax/swing/ProgressMonitor/ProgressTest.java does not show the ProgressMonitorInputStream all the time Reviewed-by: azvegint, tr ------------- PR: https://git.openjdk.org/jdk/pull/14844 From psadhukhan at openjdk.org Mon Jul 24 09:37:07 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 09:37:07 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() Message-ID: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself. Fix is made to treat setText as in edit mode and commit the changes made to it. ------------- Commit messages: - 5032471: JFormattedTextField does not use editformatter on initial focus with setText() - 5032471: JFormattedTextField does not use editformatter on initial focus with setText() - Merge branch 'master' of github.com:prsadhuk/jdk - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Revert "Fix" - Fix Changes: https://git.openjdk.org/jdk/pull/14993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-5032471 Stats: 138 lines in 2 files changed: 138 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14993/head:pull/14993 PR: https://git.openjdk.org/jdk/pull/14993 From aivanov at openjdk.org Mon Jul 24 10:00:46 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 10:00:46 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 03:39:03 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Disabled OLE1 from CoInit src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp line 482: > 480: DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param) > 481: { > 482: ::CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE); You're changing the COM for this thread from `COINIT_APARTMENTTHREADED` to `COINIT_MULTITHREADED`. Do DirectSound objects support multi-threading? I couldn't find anything quickly. A Microsoft sample for [Creating the Device Object](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee416365(v=vs.85)) uses `CoInitializeEx(NULL, 0)`. The documentation for [`CoInitializeEx`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex) says, ?You need to initialize the COM library on a thread before you call any of the library functions?? This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1272027291 From shade at openjdk.org Mon Jul 24 10:29:04 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Jul 2023 10:29:04 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 Message-ID: There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] #elif __GNUC__ >= 7 || __clang_major__ >= 10 ^~~~~~~~~~~~~~~ There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) Additional testing: - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/14995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312591 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14995/head:pull/14995 PR: https://git.openjdk.org/jdk/pull/14995 From shade at openjdk.org Mon Jul 24 10:44:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Jul 2023 10:44:49 GMT Subject: RFR: 8312592: New parentheses warnings after HarfBuzz 7.2.0 update Message-ID: At least GCC 6 fail the build with warnings-as-errors here: ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc: In function 'void _collect_layout_variation_indices(hb_subset_plan_t*)': ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc:389:83: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] if (unlikely (!plan->check_success (font = _get_hb_font_with_variations (plan)))) { ^ ../src/java.desktop/share/native/libharfbuzz/hb.hh:259:46: note: in definition of macro 'unlikely' #define unlikely(expr) (__builtin_expect (!!(expr), 0)) ^~~~ This is caused by HarfBuzz update to 7.2.0, [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) Instead of fixing the HarfBuzz sources in-tree, it is cleaner to disable the warning. Lots of follow-ups after this HarfBuzz update did the same. Additional testing: - [x] Linux x86_64 fastdebug build on affected systems ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/14996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312592 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14996/head:pull/14996 PR: https://git.openjdk.org/jdk/pull/14996 From aivanov at openjdk.org Mon Jul 24 10:45:43 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 10:45:43 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 03:39:03 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Disabled OLE1 from CoInit The test case attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) breaks after `JFileChooser` is created and the screen is locked and unlocked. I wonder if `JFileChooser` operations are affected by the suggested fix: can `JFileChooser` still navigate to virtual folders on Windows and display file icons correctly while playing and/or recording audio? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1647665207 From jiefu at openjdk.org Mon Jul 24 11:11:39 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 24 Jul 2023 11:11:39 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: <37W3UOIqir0tE-DwgkParwFrzvXu9JwkyU4UO2XZCd0=.71319088-4c02-4927-8fec-414b0745ae5d@github.com> On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) LGTM ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14995#pullrequestreview-1543250707 From dmarkov at openjdk.org Mon Jul 24 16:36:55 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Mon, 24 Jul 2023 16:36:55 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. [v6] In-Reply-To: <008EyQXLq0HU1oJC1c3YjwmVBqTT29FASv6I48hXsTw=.7b01979a-023c-4062-9f5a-cc19b845f776@github.com> References: <008EyQXLq0HU1oJC1c3YjwmVBqTT29FASv6I48hXsTw=.7b01979a-023c-4062-9f5a-cc19b845f776@github.com> Message-ID: On Mon, 24 Jul 2023 00:38:52 GMT, Sergey Bylokhov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> added test cases, fixed spacing > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 989: > >> 987: synchronized (lock) { >> 988: try { >> 989: lock.wait(); > > Are we sure that waiting forever is a good thing? Can this request be ignored by the OS for any reason? It is very unlikely that we are waiting forever here unless there are some serious problems with corresponding platform API. I understand your concern and agree that waiting for some reasonable time instead of forever is more suitable here. @alisenchung Can you open a bug to replace forever waiting with timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1272499505 From aivanov at openjdk.org Mon Jul 24 17:58:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 17:58:59 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 21:09:56 GMT, Harshitha Onkar wrote: > Additionally, I believe concurrent external manual mouse movement is not supported when Robot is performing mouse events. This would produce erroneous result. I don't think it's correct to say that such a situation is *not supported*. From this point of view, the situation described in the bug is not supported either. Yet you are fixing this scenario. If the user moves the mouse when Robot generates mouse events, it is expected to produce erroneous results because the mouse ends up in the wrong position when Robot issues further events ? essentially it breaks the assumptions in the test. So, we should check whether the internal flags passed to the generated events remain valid. But it could be not as easy to verify as in this case. Are mouse events affected if the user types text on the keyboard while Robot is moving the mouse? It's a mirrored scenario to the one described in the bug. The position of mouse remains intact, yet flags may change by concurrent keyboard input. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1648353847 From aivanov at openjdk.org Mon Jul 24 18:33:50 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 18:33:50 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 19:09:29 GMT, Harshitha Onkar wrote: >> **Problem:** >> >> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 >> >> This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) >> >> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. >> >> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. >> >> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. >> >> - The physical mouse movement causes the event flags to be reset. >> >> **Impact:** >> >> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) >> >> **Proposed Fix:** >> >> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. >> >> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. >> >> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. >> >> **Testing:** >> >> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. >> The test runs in 2 modes - as automated and manual test. >> >> CASE 1 : ... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test changes: added CountDownLatch src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 317: > 315: initFlags = keyPressed > 316: ? (initFlags | flagMaskValue) // add flag bits if modifier key pressed > 317: : (initFlags & ~flagMaskValue); // clear flag bits if modifier key released `initFlags` is modified as each event is generated; does it store the *init* flags? src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 322: > 320: > 321: CGEventFlags flags = CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState); > 322: flags = (initFlags & allModifiersMask) | (flags & (~allModifiersMask)); Suggestion: flags = (initFlags & allModifiersMask) | (flags & (~allModifiersMask)); test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 101: > 99: countDownLatch = new CountDownLatch(1); > 100: invokeAndWait(RobotModifierMaskTest::createInstructionsUI); > 101: robot.waitForIdle(); Technically, `waitForIdle` isn't needed here: you start waiting for the user to click the Start button. Without it, the waiting time may be reduced by a small amount of time. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 107: > 105: if (!testStarted) { > 106: throw new RuntimeException("Test Failed: Manual test timed out!!"); > 107: } Suggestion: if (!countDownLatch.await(2, TimeUnit.MINUTES)) { throw new RuntimeException("Test Failed: Manual test timed out!!"); } } If `await` timed out, the user didn't click the Start button. Thus, `testStarted` becomes redundant. test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 245: > 243: private static void createTestUI() { > 244: String mode = isManual ? "MANUAL" : "AUTOMATED"; > 245: jFrame = new JFrame("RobotModifierMaskTest - Mode: " + mode); Should you dispose of the instruction frame in the manual mode? test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 277: > 275: } > 276: > 277: private static class CustomWindowAdapter extends WindowAdapter { Suggestion: private static class CloseWindowHandler extends WindowAdapter { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272589627 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272589982 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272598208 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272600122 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272609498 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272606228 From honkar at openjdk.org Mon Jul 24 18:52:43 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 18:52:43 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 17:55:49 GMT, Alexey Ivanov wrote: > If the user moves the mouse when Robot generates mouse events, it is expected to produce erroneous results because the mouse ends up in the wrong position when Robot issues further events ? essentially it breaks the assumptions in the test. Correct in case of Robot's mouse events + simultaneous manual/user mouse movement it leads to wrong position which causes tests to fail. But the case being fixed here consists of Robot keyEvents (NOT Robot's mouseEvents) + simultaneous manual/user mouse movement. > So, we should check whether the internal flags passed to the generated events remain valid. But it could be not as easy to verify as in this case. > > Are mouse events affected if the user types text on the keyboard while Robot is moving the mouse? It's a mirrored scenario to the one described in the bug. The position of mouse remains intact, yet flags may change by concurrent keyboard input. I see your point. I think based on what @mrserb and you have discussed, I see 3 cases here 1. Robot mouse events + external manual mouse move- In this case user mouse events will cause the mouse to be at wrong position thus causing erroneous result as expected. And this is not a valid use case. 2. Robot key events + external manual mouse move - This is the case being fixed for accessibility keyboard use case. 3. Robot mouse events + external manual key events - As you mentioned this is a mirrored scenario and based on initial testing it works as expected - tested by automating mouse moves with Robot (without clicks or drag) and external key presses. I'll have to check the flag state in this case - at the starting of the test and at the end. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1648437392 From aivanov at openjdk.org Mon Jul 24 19:08:44 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 19:08:44 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: <79gEAdLGQ6JUT9ZuKIf0nU5eIUSCMTke22KsXI1QHkQ=.14677f78-cded-409c-8dd6-2f83e17bf04d@github.com> On Fri, 21 Jul 2023 03:39:27 GMT, Sergey Bylokhov wrote: >> @mrserb >> >>> Just to clarify an idea of this change. We would like to maintain the "flag" keys pressed by the user and maintain the list of current flags. So if the user will press SHIFT key, we will use that modifier for all next keys until shift will be released. >> >> That is correct. >> >>> It looks similar to how the mouseMove is implemented in CRobot, where we maintain the mouseLastX/mouseLastY, and we ignore the current location of the mouse for clicks, but use the latest saved value. >> >> >>> Probably we can do the same on the java side in this patch? it will simplify the native code a bit. >> >> Yes, the code for mouseEvent looks similar to what we are trying to achieve for keyEvent but there are a few differences too- >> - `mouseEvent(int lastX, int lastY, int buttonsState, boolean isButtonsDownState, boolean isMouseMove)`, lastX & lastY are already part of the parameters being sent from Java to native side. >> >> - `keyEvent(int javaKeyCode, boolean keydown)` - Are you suggesting that a modifier flag state be sent from Java to native side? This would involve changing the present native `keyEvent` signature and adding code to native side to evaluate the new modifier flag state from Java and then map it to the corresponding [kCGEventFlagMask](https://developer.apple.com/documentation/coregraphics/cgeventflags/kcgeventflagmaskalphashift?language=objc). >> >> Having everything on native side seems to be easier because with the present fix, the equivalent modifier flag mask is obtained using javaKeyCode + key state and a quick `NSDictionary modifierKeyToMaskMap` lookup without the need of adding or changing keyEvent signature. >> >>> BTW do we need to set all this modifiers for the mouse clicks as well? >> >> I don't think it is applicable for mouse clicks, as the issue (details below) occurs only when flagState is obtained using - `CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState)` which was the case for keyEvents. I can double-check on this again. >> >> **Issue:** >> _With the original code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. The physical mouse movement causes the event flags to be reset._ > >>I don't think it is applicable for mouse clicks, as the issue (details below) occurs only when flagState is obtained using - CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState) which was the case for keyEvents. I can double-check on this again. > > yes, please. > if the physical mouse movement causes the "event flags" to be reset, then what about "event flags" for mouse events > I see your point. I think based on what @mrserb and you have discussed, I see 3 cases here: > > 1. Robot mouse events + external manual mouse move- In this case user mouse events will cause the mouse to be at wrong position thus causing erroneous result as expected. And this is not a valid use case. What I mean is to look further whether this situation affects any internal state of Robot so that wrong mouse events are posted. It could still be a possible scenario. Consider Robot is moving mouse slowly, the user presses a mouse button; the following events generated by the robot should indicate the mouse button is pressed until the user releases the mouse button. There's also the **fourth possibility**: Robot generates keyboard events while the user presses modifier keys on the keyboard. It's an invalid scenario for tests but not impossible. Should the robot combine its internal state with the global hardware state? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1648461865 From aivanov at openjdk.org Mon Jul 24 19:28:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 19:28:53 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 19:42:00 GMT, Abhishek Kumar wrote: >> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. >> >> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. >> >> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. >> >> CI link is posted in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > bugid removed in comments src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 34: > 32: > 33: import apple.laf.JRSUIState; > 34: import apple.laf.JRSUIConstants.*; I think we should expand all wild card imports. test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 50: > 48: "1) Enable Screen magnifier on the Mac \n\n" + > 49: "System Preference -> Accessibility -> Zoom -> " + > 50: "Select ( Enable Hover Text) \n\n" + Suggestion: "Select "Enable Hover Text"\n\n" + test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 58: > 56: InvocationTargetException { > 57: PassFailJFrame passFailJFrame = new PassFailJFrame( > 58: "JMenu Screen Magnifier Test Instructions", INSTRUCTIONS, 5, 12, 40); Suggestion: "JComboBox Screen Magnifier Test Instructions", INSTRUCTIONS, 5, 12, 40); test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 63: > 61: passFailJFrame.awaitAndCheck(); > 62: } > 63: private static void createAndShowUI() { Suggestion: } private static void createAndShowUI() { Please add a blank line between methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272649266 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272662065 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272659964 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272660357 From aivanov at openjdk.org Mon Jul 24 19:28:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 19:28:56 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> Message-ID: On Fri, 21 Jul 2023 19:32:07 GMT, Abhishek Kumar wrote: >> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 242: >> >>> 240: ac.setAccessibleName(label.getText()); >>> 241: } >>> 242: } >> >> How it will work in other L&Fs? > > In case of other LAFs except **Aqua** in MacOS, the accessible component invoked for screen magnifier is an instance of `AccessibleJComboBox` and subsequently the a11y API called on `AccessibleJComboBox` to return the accessible name. > > But for aqua, the accessible component invoked for screen magnifier is an instance for `AquaComboBoxButton`, so it is required to return the accessible button instance for a11y APIs to get called for retrieving accessible name. That's exactly my concern: in other L&Fs `AccessibleJComboBox` handles the scenario yet in Aqua L&F it is handled by a different component which is not a problem okay per se. What is a problem is that retrieving the accessible name depends on paint: * if `AquaComboBoxButton.paint` hasn't been called for whatever reason, there's no accessible name; * if the value in the combo box is changed, the accessible name isn't updated until paint occurs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272656451 From honkar at openjdk.org Mon Jul 24 19:36:45 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 19:36:45 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: <79gEAdLGQ6JUT9ZuKIf0nU5eIUSCMTke22KsXI1QHkQ=.14677f78-cded-409c-8dd6-2f83e17bf04d@github.com> References: <79gEAdLGQ6JUT9ZuKIf0nU5eIUSCMTke22KsXI1QHkQ=.14677f78-cded-409c-8dd6-2f83e17bf04d@github.com> Message-ID: On Mon, 24 Jul 2023 19:06:23 GMT, Alexey Ivanov wrote: > What I mean is to look further whether this situation affects any internal state of Robot so that wrong mouse events are posted. > > It could still be a possible scenario. Consider Robot is moving mouse slowly, the user presses a mouse button; the following events generated by the robot should indicate the mouse button is pressed until the user releases the mouse button. > > There's also the **fourth possibility**: Robot generates keyboard events while the user presses modifier keys on the keyboard. It's an invalid scenario for tests but not impossible. Should the robot combine its internal state with the global hardware state? @aivanov-jdk Makes sense. Thanks for clarifying. I'll verify flag state for the cases discussed above and that we are not making any unexpected state changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14744#issuecomment-1648494523 From prr at openjdk.org Mon Jul 24 20:13:40 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Jul 2023 20:13:40 GMT Subject: RFR: 8312592: New parentheses warnings after HarfBuzz 7.2.0 update In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:37:43 GMT, Aleksey Shipilev wrote: > At least GCC 6 fail the build with warnings-as-errors here: > > > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc: In function 'void _collect_layout_variation_indices(hb_subset_plan_t*)': > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc:389:83: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] > if (unlikely (!plan->check_success (font = _get_hb_font_with_variations (plan)))) { > ^ > ../src/java.desktop/share/native/libharfbuzz/hb.hh:259:46: note: in definition of macro 'unlikely' > #define unlikely(expr) (__builtin_expect (!!(expr), 0)) > ^~~~ > > > This is caused by HarfBuzz update to 7.2.0, [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) > > Instead of fixing the HarfBuzz sources in-tree, it is cleaner to disable the warning. Lots of follow-ups after this HarfBuzz update did the same. > > Additional testing: > - [x] Linux x86_64 fastdebug build on affected systems Since gcc8 didn't complain about this, its probably just the older versions. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14996#pullrequestreview-1544191827 From aivanov at openjdk.org Mon Jul 24 20:14:45 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 24 Jul 2023 20:14:45 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: Message-ID: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> On Tue, 18 Jul 2023 18:00:11 GMT, Gabriel wrote: > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 It didn't, the test case still produces truncated names. Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1648538107 From prr at openjdk.org Mon Jul 24 20:20:42 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Jul 2023 20:20:42 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) This is not so obvious. This is a 3rd party header file. Seems we should discuss with upstream. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14995#issuecomment-1648545344 From prr at openjdk.org Mon Jul 24 20:26:41 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Jul 2023 20:26:41 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h line 62: > 60: # define SPA_FALLTHROUGH [[clang::fallthrough]]; > 61: #elif defined(__GNUC__) && __GNUC__ >= 7 > 62: # define SPA_FALLTHROUGH __attribute__ ((fallthrough)); Upstream still has this issue/bug. https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/include/spa/utils/defs.h Do they intend to support only GNUC 7 and up ? Not clear. Best to ask. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1272718039 From honkar at openjdk.org Mon Jul 24 21:46:48 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 21:46:48 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 18:05:32 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> test changes: added CountDownLatch > > src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m line 317: > >> 315: initFlags = keyPressed >> 316: ? (initFlags | flagMaskValue) // add flag bits if modifier key pressed >> 317: : (initFlags & ~flagMaskValue); // clear flag bits if modifier key released > > `initFlags` is modified as each event is generated; does it store the *init* flags? `initFlags` is appended with or cleared off modifier flag bits, as a result `initFlag` value at the beginning and end of the test will remain same. To make sure only necessary flag bits are modified and we are not introducing new flag bits or clearing out something that is already present or known to the system, the `initFlag` is not used directly in `CGEventSetFlags` but it is copied over to a local `flag` variable as follows which is then used in `CGEventSetFlags` API and post the event. CGEventFlags flags = CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState); flags = (initFlags & allModifiersMask) | (flags & (~allModifiersMask)); The second line copies over all the flag bits corresponding to modifier flags (if present in initFlags) and all the bits already present. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272787893 From honkar at openjdk.org Mon Jul 24 21:59:47 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 21:59:47 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 18:27:20 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> test changes: added CountDownLatch > > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 245: > >> 243: private static void createTestUI() { >> 244: String mode = isManual ? "MANUAL" : "AUTOMATED"; >> 245: jFrame = new JFrame("RobotModifierMaskTest - Mode: " + mode); > > Should you dispose of the instruction frame in the manual mode? Since I'm reusing the same `jFrame` variable, disposing of jFrame is handled in the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272796737 From serb at openjdk.org Mon Jul 24 23:07:40 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Jul 2023 23:07:40 GMT Subject: RFR: 8312592: New parentheses warnings after HarfBuzz 7.2.0 update In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:37:43 GMT, Aleksey Shipilev wrote: > At least GCC 6 fail the build with warnings-as-errors here: > > > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc: In function 'void _collect_layout_variation_indices(hb_subset_plan_t*)': > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc:389:83: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] > if (unlikely (!plan->check_success (font = _get_hb_font_with_variations (plan)))) { > ^ > ../src/java.desktop/share/native/libharfbuzz/hb.hh:259:46: note: in definition of macro 'unlikely' > #define unlikely(expr) (__builtin_expect (!!(expr), 0)) > ^~~~ > > > This is caused by HarfBuzz update to 7.2.0, [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) > > Instead of fixing the HarfBuzz sources in-tree, it is cleaner to disable the warning. Lots of follow-ups after this HarfBuzz update did the same. > > Additional testing: > - [x] Linux x86_64 fastdebug build on affected systems Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14996#pullrequestreview-1544403456 From honkar at openjdk.org Mon Jul 24 23:27:57 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 23:27:57 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v8] In-Reply-To: References: Message-ID: > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) > > This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. > > - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys. > The test runs in 2 modes - as automated and manual test. > > CASE 1 : As automated test. No user interaction needed. > CASE 2 : When r... Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: - minor change - test review changes: removed testStarted ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14744/files - new: https://git.openjdk.org/jdk/pull/14744/files/8f7d04a2..54757ae4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=06-07 Stats: 23 lines in 2 files changed: 5 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14744/head:pull/14744 PR: https://git.openjdk.org/jdk/pull/14744 From honkar at openjdk.org Mon Jul 24 23:27:59 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 24 Jul 2023 23:27:59 GMT Subject: RFR: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 18:16:21 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> test changes: added CountDownLatch > > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 107: > >> 105: if (!testStarted) { >> 106: throw new RuntimeException("Test Failed: Manual test timed out!!"); >> 107: } > > Suggestion: > > if (!countDownLatch.await(2, TimeUnit.MINUTES)) { > throw new RuntimeException("Test Failed: Manual test timed out!!"); > } > } > > If `await` timed out, the user didn't click the Start button. > > Thus, `testStarted` becomes redundant. Updated. > test/jdk/java/awt/Robot/RobotModifierMaskTest.java line 245: > >> 243: private static void createTestUI() { >> 244: String mode = isManual ? "MANUAL" : "AUTOMATED"; >> 245: jFrame = new JFrame("RobotModifierMaskTest - Mode: " + mode); > > Should you dispose of the instruction frame in the manual mode? Added try & finally block for instruction frame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272848182 PR Review Comment: https://git.openjdk.org/jdk/pull/14744#discussion_r1272848955 From jiangli at openjdk.org Tue Jul 25 00:18:48 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Jul 2023 00:18:48 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code Message-ID: Please review the simple fix that changes start|stop_timer to static. ------------- Commit messages: - Change 'start|stop_timer' to be static. Changes: https://git.openjdk.org/jdk/pull/15006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312626 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15006/head:pull/15006 PR: https://git.openjdk.org/jdk/pull/15006 From serb at openjdk.org Tue Jul 25 04:30:39 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 25 Jul 2023 04:30:39 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 00:13:12 GMT, Jiangli Zhou wrote: > Please review the simple fix that changes start|stop_timer to static. I was thinking of asking you to see if there are any other variables or functions in this file that could be made static, but it looks like xx_timer are the only one left. Can you please confirm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15006#issuecomment-1649106367 From duke at openjdk.org Tue Jul 25 06:43:44 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 25 Jul 2023 06:43:44 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 09:58:09 GMT, Alexey Ivanov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Disabled OLE1 from CoInit > > src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp line 482: > >> 480: DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param) >> 481: { >> 482: ::CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE); > > You're changing the COM for this thread from `COINIT_APARTMENTTHREADED` to `COINIT_MULTITHREADED`. > > Do DirectSound objects support multi-threading? I couldn't find anything quickly. > > A Microsoft sample for [Creating the Device Object](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee416365(v=vs.85)) uses `CoInitializeEx(NULL, 0)`. > > The documentation for [`CoInitializeEx`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex) says, ?You need to initialize the COM library on a thread before you call any of the library functions?? > > This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything? @aivanov-jdk, Thank you for your time and reviews, `CoInitializeEx(NULL, 0)` also resolving this problem because as per document **The default is COINIT_MULTITHREADED**. In my debug session noticed `DirectSoundCaptureEnumerate` getting called ahead of thread call or ::CoInitialize and that was the root cause this failure. For resolving this found 3 ways and all works: 1 . Use COM multi-threading :- Simplest approach with respect to other solutions 2. Hold the call till CoInitialize : - Can end up in deadlock situation so that need to be taken care. 3. Do another CoInitialize before call :- not a good approach _This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything?_ `DS_StartBufferHelper` class initializing COM in thread and all member functions checking initialization status before making any calls. So another solution may be restructure the code for accessing `isInitialized()` method from outer methods and proceed. (approach 2 in better way) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1273063731 From duke at openjdk.org Tue Jul 25 07:04:43 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 25 Jul 2023 07:04:43 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> References: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> Message-ID: On Mon, 24 Jul 2023 20:11:26 GMT, Alexey Ivanov wrote: > > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 > > It didn't, the test case still produces truncated names. > > Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. Partially fixing, with the fix this was the output on my machine : _mixer 0: >>Port Speakers (Realtek(R) Audio)<< mixer 1: >>Port Microphone Array (Realtek(R) Au<< mixer 2: >>Primary Sound Driver<< mixer 3: >>Speakers (Realtek(R) Audio)<< mixer 4: >>Primary Sound Capture Driver<< mixer 5: >>Microphone Array (Realtek(R) Audio)<<_ Without fix would be like this: _mixer 5: >>Microphone Array (Realtek(R) Au<<_ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1649239777 From shade at openjdk.org Tue Jul 25 08:48:51 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Jul 2023 08:48:51 GMT Subject: RFR: 8312592: New parentheses warnings after HarfBuzz 7.2.0 update In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:37:43 GMT, Aleksey Shipilev wrote: > At least GCC 6 fail the build with warnings-as-errors here: > > > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc: In function 'void _collect_layout_variation_indices(hb_subset_plan_t*)': > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc:389:83: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] > if (unlikely (!plan->check_success (font = _get_hb_font_with_variations (plan)))) { > ^ > ../src/java.desktop/share/native/libharfbuzz/hb.hh:259:46: note: in definition of macro 'unlikely' > #define unlikely(expr) (__builtin_expect (!!(expr), 0)) > ^~~~ > > > This is caused by HarfBuzz update to 7.2.0, [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) > > Instead of fixing the HarfBuzz sources in-tree, it is cleaner to disable the warning. Lots of follow-ups after this HarfBuzz update did the same. > > Additional testing: > - [x] Linux x86_64 fastdebug build on affected systems Thanks for reviews! I am integrating to unblock some GCC 6 pipelines. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14996#issuecomment-1649393465 From shade at openjdk.org Tue Jul 25 08:48:52 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Jul 2023 08:48:52 GMT Subject: Integrated: 8312592: New parentheses warnings after HarfBuzz 7.2.0 update In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:37:43 GMT, Aleksey Shipilev wrote: > At least GCC 6 fail the build with warnings-as-errors here: > > > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc: In function 'void _collect_layout_variation_indices(hb_subset_plan_t*)': > ../src/java.desktop/share/native/libharfbuzz/hb-subset-plan.cc:389:83: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] > if (unlikely (!plan->check_success (font = _get_hb_font_with_variations (plan)))) { > ^ > ../src/java.desktop/share/native/libharfbuzz/hb.hh:259:46: note: in definition of macro 'unlikely' > #define unlikely(expr) (__builtin_expect (!!(expr), 0)) > ^~~~ > > > This is caused by HarfBuzz update to 7.2.0, [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) > > Instead of fixing the HarfBuzz sources in-tree, it is cleaner to disable the warning. Lots of follow-ups after this HarfBuzz update did the same. > > Additional testing: > - [x] Linux x86_64 fastdebug build on affected systems This pull request has now been integrated. Changeset: ea067fc3 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/ea067fc3d2b1fecda694442c7921ecb980377c1e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8312592: New parentheses warnings after HarfBuzz 7.2.0 update Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/14996 From abhiscxk at openjdk.org Tue Jul 25 09:08:44 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 09:08:44 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() In-Reply-To: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: On Mon, 24 Jul 2023 09:20:44 GMT, Prasanta Sadhukhan wrote: > When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. > Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself. > Fix is made to treat setText as in edit mode and commit the changes made to it. src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 747: > 745: > 746: @Override > 747: public void setText(String text){ Suggestion: public void setText(String text) { src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 749: > 747: public void setText(String text){ > 748: super.setText(text); > 749: if(isEdited() && isEditValid()){ Suggestion: if (isEdited() && isEditValid()) { src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 750: > 748: super.setText(text); > 749: if(isEdited() && isEditValid()){ > 750: try{ Suggestion: try { src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 752: > 750: try{ > 751: commitEdit(); > 752: } catch(ParseException pe){}//do nothing, we assume this will never happen. Suggestion: } catch (ParseException pe){} //do nothing, we assume this will never happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273228712 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273229039 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273229529 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273230054 From aivanov at openjdk.org Tue Jul 25 09:14:42 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 09:14:42 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: <1c1U2X7QWUsB3CRI3tzNCWVyUal1v_0JkHsPopBmHAI=.c6f7e8c5-d5ab-46ff-aacd-830e37c2ac04@github.com> On Thu, 20 Jul 2023 03:39:03 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Disabled OLE1 from CoInit > _mixer 5: >>Microphone Array (Realtek(R) Audio)<<_ > > Without fix would be like this: _mixer 5: >>Microphone Array (Realtek(R) Au<<_ Right. Interesting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1649436700 From aivanov at openjdk.org Tue Jul 25 09:14:45 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 09:14:45 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 09:58:09 GMT, Alexey Ivanov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Disabled OLE1 from CoInit > > src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp line 482: > >> 480: DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param) >> 481: { >> 482: ::CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE); > > You're changing the COM for this thread from `COINIT_APARTMENTTHREADED` to `COINIT_MULTITHREADED`. > > Do DirectSound objects support multi-threading? I couldn't find anything quickly. > > A Microsoft sample for [Creating the Device Object](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee416365(v=vs.85)) uses `CoInitializeEx(NULL, 0)`. > > The documentation for [`CoInitializeEx`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex) says, ?You need to initialize the COM library on a thread before you call any of the library functions?? > > This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything? > @aivanov-jdk, Thank you for your time and reviews, `CoInitializeEx(NULL, 0)` also resolving this problem because as per document **The default is COINIT_MULTITHREADED**. This is what I expected, however, the documentation for [`COINIT`](https://learn.microsoft.com/en-us/windows/win32/api/objbase/ne-objbase-coinit) doesn't spell out the value for `COINIT_MULTITHREADED`. > In my debug session noticed `DirectSoundCaptureEnumerate` getting called ahead of thread call or ::CoInitialize and that was the root cause this failure. If it is the case, I can't see that you have ensured that `DirectSoundCaptureEnumerate` is called after `CoInitialize`. Do I miss anything? > For resolving this found 3 ways and all works: > > 1. Use COM multi-threading :- Simplest approach with respect to other solutions Probably? But it is still incorrect. Initialising COM on *a thread* doesn't mean you can call COM object methods from **any thread** in your application. As the documentation says, ?You need to initialize the COM library on a thread before you call any of the library functions?? (I have this very quote in [my comment above](https://github.com/openjdk/jdk/pull/14898#discussion_r1272027291).) > 2. Hold the call till CoInitialize : - Can end up in deadlock situation so that need to be taken care. It's a challenge but it is the only right way, as far as I can see? Perhaps not to wait till `::CoInitialize` is called on a thread (see above) but to transfer a call for handling to a thread where COM is initialised. > 3. Do another CoInitialize before call :- not a good approach Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. > _This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything?_ `DS_StartBufferHelper` class initializing COM in thread and all member functions checking initialization status before making any calls. So another solution may be restructure the code for accessing `isInitialized()` method from outer methods and proceed. (approach 2 in better way) > > Tried this approach with `::CoInitialize` and observed _truncated names_, but its not failing for lock unlock workflow. As I explained above, it would still be incorrect: if enumerating sound devices requires COM, it must be initialised on the thread where you enumerate the devices. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1273238491 From aivanov at openjdk.org Tue Jul 25 11:20:48 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 11:20:48 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() In-Reply-To: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: On Mon, 24 Jul 2023 09:20:44 GMT, Prasanta Sadhukhan wrote: > When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. > Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself. > Fix is made to treat setText as in edit mode and commit the changes made to it. The bug report mentions using `setDocument()` to change the value of the formatted text field. Also, it's possible to call `getDocument().setText()`, which may still have the original bug. src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 747: > 745: > 746: @Override > 747: public void setText(String text){ Shall the explicit `{@inheritDoc}` be added? Or rather the javadoc should be modified to reflect *the updated behaviour*. There are cases where the text isn't set, right? src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 752: > 750: try{ > 751: commitEdit(); > 752: } catch(ParseException pe){}//do nothing, we assume this will never happen. Suggestion: } catch (ParseException ignored) { // Do nothing, we assume this will never happen } This way would avoid a warning by IDEA. test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 60: > 58: Robot robot = new Robot(); > 59: robot.setAutoDelay(100); > 60: JFormattedTextProblem test = new JFormattedTextProblem(); The constructor should be called on EDT because it creates lots of Swing components and Swing components are not thread-safe. test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 68: > 66: robot.keyPress(KeyEvent.VK_TAB); > 67: robot.keyRelease(KeyEvent.VK_TAB); > 68: if (!expected) { Isn't `robot.waitForIdle()` required here to allow the EDT to handle all the events? ------------- PR Review: https://git.openjdk.org/jdk/pull/14993#pullrequestreview-1545194304 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273367125 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273363168 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273368884 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273369591 From mbaesken at openjdk.org Tue Jul 25 11:23:51 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Jul 2023 11:23:51 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values Message-ID: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. see https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte especially https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value At most places in the coding the return values are already checked, but some are missing. ------------- Commit messages: - JDK-8312612 Changes: https://git.openjdk.org/jdk/pull/15015/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312612 Stats: 33 lines in 3 files changed: 20 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15015/head:pull/15015 PR: https://git.openjdk.org/jdk/pull/15015 From duke at openjdk.org Tue Jul 25 11:45:53 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 25 Jul 2023 11:45:53 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: Message-ID: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> On Tue, 25 Jul 2023 09:10:10 GMT, Alexey Ivanov wrote: > > @aivanov-jdk, Thank you for your time and reviews, `CoInitializeEx(NULL, 0)` also resolving this problem because as per document **The default is COINIT_MULTITHREADED**. > > This is what I expected, however, the documentation for [`COINIT`](https://learn.microsoft.com/en-us/windows/win32/api/objbase/ne-objbase-coinit) doesn't spell out the value for `COINIT_MULTITHREADED`. As per the declaration yes its 0 [tagCOINIT](https://github.com/wine-mirror/wine/blob/master/include/objbase.h) > > In my debug session noticed `DirectSoundCaptureEnumerate` getting called ahead of thread call or ::CoInitialize and that was the root cause this failure. > If it is the case, I can't see that you have ensured that `DirectSoundCaptureEnumerate` is called after `CoInitialize`. Do I miss anything? Yes, You are right in main thread no CoInitialize > > For resolving this found 3 ways and all works: > > > > 1. Use COM multi-threading :- Simplest approach with respect to other solutions > > Probably? But it is still incorrect. Initialising COM on _a thread_ doesn't mean you can call COM object methods from **any thread** in your application. > > As the documentation says, ?You need to initialize the COM library on a thread before you call any of the library functions?? (I have this very quote in [my comment above](https://github.com/openjdk/jdk/pull/14898#discussion_r1272027291).) > > > 2. Hold the call till CoInitialize : - Can end up in deadlock situation so that need to be taken care. > > It's a challenge but it is the only right way, as far as I can see? Perhaps not to wait till `::CoInitialize` is called on a thread (see above) but to transfer a call for handling to a thread where COM is initialised. These two approach didn't do ::CoInitialize in running thread (main thread) > > 3. Do another CoInitialize before call :- not a good approach > > Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` > > > _This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything?_ `DS_StartBufferHelper` class initializing COM in thread and all member functions checking initialization status before making any calls. So another solution may be restructure the code for accessing `isInitialized()` method from outer methods and proceed. (approach 2 in better way) > > Tried this approach with `::CoInitialize` and observed _truncated names_, but its not failing for lock unlock workflow. > As I explained above, it would still be incorrect: if enumerating sound devices requires COM, it must be initialised on the thread where you enumerate the devices. Got your point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1273399494 From abhiscxk at openjdk.org Tue Jul 25 11:59:20 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 11:59:20 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v7] In-Reply-To: References: Message-ID: > The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. > > Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. > > Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. > > CI link is posted in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Revert BasicComboBoxUI fix and update review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14497/files - new: https://git.openjdk.org/jdk/pull/14497/files/1686c546..525e3465 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=05-06 Stats: 85 lines in 4 files changed: 57 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/14497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497 PR: https://git.openjdk.org/jdk/pull/14497 From aivanov at openjdk.org Tue Jul 25 11:59:20 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 11:59:20 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 19:42:00 GMT, Abhishek Kumar wrote: >> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. >> >> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. >> >> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. >> >> CI link is posted in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > bugid removed in comments src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1131: > 1129: switch ( i ) { > 1130: case 0: > 1131: if ( popup instanceof Accessible accessiblePopup) { Suggestion: if (popup instanceof Accessible accessiblePopup) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1272669170 From abhiscxk at openjdk.org Tue Jul 25 12:03:48 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 12:03:48 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 19:51:26 GMT, Abhishek Kumar wrote: > > @mrserb please double-check how it will work in Windows, it might be possible that jaws expects 1. > > I will check this and update if there is any change in announcement with JAWS with this fix. @mrserb I observed the difference in announcement with JAWS with the fix. Since the magnifier is used only for macos, proposed fix is now handled in AquaComboBoxUI instead of BasicComboBoxUI. Changes in BasicComboBoxUI is reverted back. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1649698292 From abhiscxk at openjdk.org Tue Jul 25 12:03:54 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 12:03:54 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v6] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 19:11:00 GMT, Alexey Ivanov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> bugid removed in comments > > src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 34: > >> 32: >> 33: import apple.laf.JRSUIState; >> 34: import apple.laf.JRSUIConstants.*; > > I think we should expand all wild card imports. Updated. > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1131: > >> 1129: switch ( i ) { >> 1130: case 0: >> 1131: if ( popup instanceof Accessible accessiblePopup) { > > Suggestion: > > if (popup instanceof Accessible accessiblePopup) { This code segment is reverted back and handled in `AquaComboBoxUI` now. > test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 50: > >> 48: "1) Enable Screen magnifier on the Mac \n\n" + >> 49: "System Preference -> Accessibility -> Zoom -> " + >> 50: "Select ( Enable Hover Text) \n\n" + > > Suggestion: > > "Select "Enable Hover Text"\n\n" + Updated. > test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 58: > >> 56: InvocationTargetException { >> 57: PassFailJFrame passFailJFrame = new PassFailJFrame( >> 58: "JMenu Screen Magnifier Test Instructions", INSTRUCTIONS, 5, 12, 40); > > Suggestion: > > "JComboBox Screen Magnifier Test Instructions", INSTRUCTIONS, 5, 12, 40); Updated. > test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 63: > >> 61: passFailJFrame.awaitAndCheck(); >> 62: } >> 63: private static void createAndShowUI() { > > Suggestion: > > } > > private static void createAndShowUI() { > > > Please add a blank line between methods. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273426943 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273426473 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273426634 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273426830 PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273426730 From abhiscxk at openjdk.org Tue Jul 25 12:03:56 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 12:03:56 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v7] In-Reply-To: References: Message-ID: <0KtiYg1S0moqRbj_KUDj5vdpjn2WLha4R7w6DdHJwzY=.4ff91979-aea9-4eb9-80e5-0be56a8786c0@github.com> On Thu, 20 Jul 2023 01:43:18 GMT, Sergey Bylokhov wrote: > please double-check how it will work in Windows, it might be possible that jaws expects 1. @mrserb I observed the difference in announcement with JAWS with the fix. Since the magnifier is used only for macos, proposed fix is now handled in AquaComboBoxUI instead of BasicComboBoxUI. Changes in BasicComboBoxUI is reverted back. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273424339 From abhiscxk at openjdk.org Tue Jul 25 12:07:49 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 25 Jul 2023 12:07:49 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v5] In-Reply-To: References: <4GdFSlXrwsCbUzjWNneaqvOrlCcfTHFNqdnCZFOG26k=.32651341-85da-44ad-a575-57f490ffbf19@github.com> Message-ID: On Mon, 24 Jul 2023 19:18:10 GMT, Alexey Ivanov wrote: > That's exactly my concern: in other L&Fs `AccessibleJComboBox` handles the scenario yet in Aqua L&F it is handled by a different component which is not a problem okay per se. What is a problem is that retrieving the accessible name depends on paint: > > * if `AquaComboBoxButton.paint` hasn't been called for whatever reason, there's no accessible name; > > * if the value in the combo box is changed, the accessible name isn't updated until paint occurs. I rechecked again but couldn't find any other way to either set accessible name or get the current selected item other than `AquaComboBoxButton.paint`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1273430651 From aivanov at openjdk.org Tue Jul 25 13:17:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 13:17:58 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v3] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Fri, 14 Jul 2023 07:43:00 GMT, Tejesh R wrote: >> "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). >> CI testing shows green. >> After the fix at 225% scaling: >> ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Spacing fix Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 36: > 34: > 35: import java.io.File; > 36: import javax.imageio.ImageIO; `java.*` and `javax.*` packages shouldn't be mixed like that. Usually, in OpenJDK, `java.*` packages are preceded by `javax.*` packages, it's a matter of consistency; in a way, having `javax.*` packages above `java.*` ones is reasonable, the test is for Swing which is in `javax.*` space. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 42: > 40: * @bug 8301606 > 41: * @library /java/awt/regtesthelpers > 42: * @build PassFailJFrame Suggestion: The test is no longer manual, it uses no libraries. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 44: > 42: * @build PassFailJFrame > 43: * @summary Test to check if the Right aligned header > 44: * label doesn't cut off Metal Look&Feel Suggestion: * @summary Test to check if the Right aligned header * label doesn't cut off Metal Look&Feel This way the summary is easier to grasp by scanning the tags quickly, don't you agree? test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 48: > 46: */ > 47: > 48: public class JTableHeaderLabelRightAlignTest { Suggestion: */ public class JTableHeaderLabelRightAlignTest { No blank line between the class declaration and the comment above it. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 49: > 47: > 48: public class JTableHeaderLabelRightAlignTest { > 49: static JTable table; Suggestion: private static JTable table; It's better to separate it from the following constants with a blank line. Even better, the `table` field can be converted to a local variable inside the `test` method. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 62: > 60: throw new RuntimeException(e); > 61: } > 62: }); Suggestion: SwingUtilities.invokeAndWait(JTableHeaderLabelRightAlignTest::test); You can call your own methods without specifying the class. Even better, remove the `throws Exception` from the `test` method declaration and handle `IOException` when saving the image. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 65: > 63: } > 64: > 65: public static void Test() throws Exception { Suggestion: private static void test() throws Exception { It doesn't need to be public, does it? Method names in Java start with lower-case letter. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 70: > 68: BufferedImage imgHeader; > 69: double w; > 70: double h; Declare variables where they're used, there's not much sense in declaring them in advance. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 76: > 74: }; > 75: > 76: String[] columnNames = { "Size", "Size", "Size"}; Do you really need three columns and two rows? test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 79: > 77: > 78: table = new JTable(data, columnNames); > 79: table.setSize(WIDTH,HEIGHT); Suggestion: table.setSize(WIDTH, HEIGHT); test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 85: > 83: final JTableHeader header = table.getTableHeader(); > 84: TableCellRenderer renderer = header.getDefaultRenderer(); > 85: header.setDefaultRenderer(renderer); This doesn't make sense to me: you get the renderer from the header and set it back. Nothing's changed here, is it? test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 91: > 89: header.setSize(size); > 90: w = SCALE * size.width; > 91: h = SCALE * size.height; Perhaps, it make more sense to have both `w` and `h` as `int` and use `ceil` to ensure the buffered image has enough space to contain the entire image without clipping. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 108: > 106: for (int i = 1; i < imgHeader.getHeight()-3; i++) { > 107: for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { > 108: if (expectedRGB != imgHeader.getRGB(j, i)) { Suggestion: for (int i = 1; i < imgHeader.getHeight()-3; i++) { for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { if (expectedRGB != imgHeader.getRGB(j, i)) { These are coordinates, so name them as `x` and `y`. Adding the coordinates would help an engineer dealing with the test failure the clue what went wrong, that engineer could be you. The height should also be scaled: `(int) (imgHeader.getHeight() * SCALE - 3);` test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 115: > 113: } > 114: } > 115: System.out.println("Test Pass!!"); Suggestion: System.out.println("Test Passed"); ------------- PR Review: https://git.openjdk.org/jdk/pull/14464#pullrequestreview-1545367488 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273507961 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273509468 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273510820 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273475982 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273476947 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273500298 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273501354 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273490371 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273524852 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273490538 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273492672 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273494630 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273499942 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1273495855 From aivanov at openjdk.org Tue Jul 25 13:48:47 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Jul 2023 13:48:47 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v6] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 04:36:50 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix [The same comments](https://github.com/openjdk/jdk/pull/14464#discussion_r1273475982) I left in #14464 apply here. Yet this change doesn't make all the borders in the table header consistent: there are header cell borders where shadow or highlight are 1- or 2-pixel wide at 175% scale, however, there are now no cases where background colour shines between shadow and highlight. src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1114: > 1112: SwingUtilities2.drawHLine(g, 1, w-1, h-1); > 1113: g.setColor( MetalLookAndFeel.getControlHighlight() ); > 1114: SwingUtilities2.drawHLine(g, 0, w-2, 0 ); Suggestion: SwingUtilities2.drawHLine(g, 0, w-2, 0); You removed other spaces but this one's left. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 118: > 116: e.printStackTrace(); > 117: } > 118: throw new RuntimeException("Test Failed"); Avoid duplicate code, move saving the image into a separate method. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1545494792 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1273554206 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1273557351 From jiangli at openjdk.org Tue Jul 25 18:03:40 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Jul 2023 18:03:40 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code In-Reply-To: References: Message-ID: <0nZQCIcOpOjxt9aPuQEv2iIStluMWWsVJBsSHAvadcE=.2fde9668-a819-43cc-8769-4165d76d6bb1@github.com> On Tue, 25 Jul 2023 04:27:47 GMT, Sergey Bylokhov wrote: > I was thinking of asking you to see if there are any other variables or functions in this file that could be made static, but it looks like xx_timer are the only one left. Can you please confirm? @mrserb, thanks for looking into it. I just iterated though awt_ImagingLib.c as well and came to the same conclusion as yours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15006#issuecomment-1650296983 From prr at openjdk.org Tue Jul 25 18:03:51 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Jul 2023 18:03:51 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) @azvegint - Alexander please help decide what we should do here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14995#issuecomment-1650296824 From jiangli at openjdk.org Tue Jul 25 18:09:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Jul 2023 18:09:17 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code [v2] In-Reply-To: References: Message-ID: > Please review the simple fix that changes start|stop_timer to static. Jiangli Zhou 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8312626 - Change 'start|stop_timer' to be static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15006/files - new: https://git.openjdk.org/jdk/pull/15006/files/8d4e077a..223c3a74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=00-01 Stats: 213 lines in 12 files changed: 150 ins; 34 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/15006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15006/head:pull/15006 PR: https://git.openjdk.org/jdk/pull/15006 From psadhukhan at openjdk.org Wed Jul 26 03:27:41 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Jul 2023 03:27:41 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() [v2] In-Reply-To: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: > When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. > Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself. > Fix is made to treat setText as in edit mode and commit the changes made to it. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: setDocument and test fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14993/files - new: https://git.openjdk.org/jdk/pull/14993/files/6fd3a18e..79231c5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14993&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14993&range=00-01 Stats: 19 lines in 2 files changed: 14 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14993/head:pull/14993 PR: https://git.openjdk.org/jdk/pull/14993 From psadhukhan at openjdk.org Wed Jul 26 03:28:51 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Jul 2023 03:28:51 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() [v2] In-Reply-To: References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: On Tue, 25 Jul 2023 11:17:52 GMT, Alexey Ivanov wrote: > The bug report mentions using `setDocument()` to change the value of the formatted text field. Also, it's possible to call `getDocument().setText()`, which may still have the original bug. Fixed setDocument but I couldn't find Document.setText that can be called... ------------- PR Comment: https://git.openjdk.org/jdk/pull/14993#issuecomment-1650920455 From dholmes at openjdk.org Wed Jul 26 07:17:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Jul 2023 07:17:59 GMT Subject: RFR: 8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 [v6] In-Reply-To: References: Message-ID: <7l5s1UCDgEt4c34NVusIhI9fdXsoJPhuUtdHV9FMnaM=.ee4b077d-ddd0-4430-8e1d-61379b46b239@github.com> On Wed, 19 Jul 2023 10:58:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to deprecate for removal the `-Xdebug` option and `-debug` option of the `java` command? This addresses https://bugs.openjdk.org/browse/JDK-8227229. >> >> As noted in the JBS issue this option is currently a no-op and has been there only for backward compatible since even Java 8 days. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove -Xdebug usage from SourceDebugExtension test Sorry wrong browser tab ------------- PR Review: https://git.openjdk.org/jdk/pull/14918#pullrequestreview-1546982502 From psadhukhan at openjdk.org Wed Jul 26 07:23:01 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Jul 2023 07:23:01 GMT Subject: RFR: 4893524: Swing drop targets should call close() on transferred readers and streams Message-ID: The issue here is a Reader(stream) is requested to handle a drop, via DataFlavor.getReaderForText(), and then the reader is completely read, but it isn't closed. It should be closed as soon as possible to release some native resources. Fix is made to close the stream after it is being used ------------- Commit messages: - 4893524: Swing drop targets should call close() on transferred readers and streams - Merge branch 'master' of github.com:prsadhuk/jdk - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Revert "Fix" - Fix Changes: https://git.openjdk.org/jdk/pull/15033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4893524 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15033/head:pull/15033 PR: https://git.openjdk.org/jdk/pull/15033 From tr at openjdk.org Wed Jul 26 08:13:25 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 08:13:25 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v4] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/9ddb85f2..dec7dc01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=02-03 Stats: 43 lines in 1 file changed: 6 ins; 17 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From tr at openjdk.org Wed Jul 26 08:13:31 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 08:13:31 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v3] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: <69A-Kq1GiZPn08gc4KHILHGdo4iN5fXBxVFiyW9b8TA=.96351cb7-7e67-4e4e-9a98-90e2c6a8cb7b@github.com> On Tue, 25 Jul 2023 12:50:35 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Spacing fix > > test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 85: > >> 83: final JTableHeader header = table.getTableHeader(); >> 84: TableCellRenderer renderer = header.getDefaultRenderer(); >> 85: header.setDefaultRenderer(renderer); > > This doesn't make sense to me: you get the renderer from the header and set it back. Nothing's changed here, is it? Yeah, not required. > test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 108: > >> 106: for (int i = 1; i < imgHeader.getHeight()-3; i++) { >> 107: for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { >> 108: if (expectedRGB != imgHeader.getRGB(j, i)) { > > Suggestion: > > for (int i = 1; i < imgHeader.getHeight()-3; i++) { > for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { > if (expectedRGB != imgHeader.getRGB(j, i)) { > > These are coordinates, so name them as `x` and `y`. Adding the coordinates would help an engineer dealing with the test failure the clue what went wrong, that engineer could be you. > > The height should also be scaled: `(int) (imgHeader.getHeight() * SCALE - 3);` For height, I am using BufferedImage height, not TableHeader height. So I guess it is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274535701 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274537494 From tr at openjdk.org Wed Jul 26 08:14:01 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 08:14:01 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v3] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Tue, 25 Jul 2023 13:13:34 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Spacing fix > > test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 76: > >> 74: }; >> 75: >> 76: String[] columnNames = { "Size", "Size", "Size"}; > > Do you really need three columns and two rows? Not required. Reduced to two columns and one rows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274542008 From aivanov at openjdk.org Wed Jul 26 10:23:47 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Jul 2023 10:23:47 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v3] In-Reply-To: <69A-Kq1GiZPn08gc4KHILHGdo4iN5fXBxVFiyW9b8TA=.96351cb7-7e67-4e4e-9a98-90e2c6a8cb7b@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> <69A-Kq1GiZPn08gc4KHILHGdo4iN5fXBxVFiyW9b8TA=.96351cb7-7e67-4e4e-9a98-90e2c6a8cb7b@github.com> Message-ID: On Wed, 26 Jul 2023 08:08:03 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 108: >> >>> 106: for (int i = 1; i < imgHeader.getHeight()-3; i++) { >>> 107: for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { >>> 108: if (expectedRGB != imgHeader.getRGB(j, i)) { >> >> Suggestion: >> >> for (int i = 1; i < imgHeader.getHeight()-3; i++) { >> for (int j = verticalLineCol; j < verticalLineCol + 1; j++) { >> if (expectedRGB != imgHeader.getRGB(j, i)) { >> >> These are coordinates, so name them as `x` and `y`. Adding the coordinates would help an engineer dealing with the test failure the clue what went wrong, that engineer could be you. >> >> The height should also be scaled: `(int) (imgHeader.getHeight() * SCALE - 3);` > > For height, I am using BufferedImage height, not TableHeader height. So I guess it is fine. Blimey! Sorry for my confusion, you're right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274741691 From tr at openjdk.org Wed Jul 26 10:49:50 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 10:49:50 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v7] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/bfb3ae8d..343915c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=05-06 Stats: 59 lines in 2 files changed: 11 ins; 20 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From mbaesken at openjdk.org Wed Jul 26 10:50:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Jul 2023 10:50:05 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources Message-ID: In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. However this should be done as well in some early leaving with throw that can occur in this function. ------------- Commit messages: - JDK-8313164 Changes: https://git.openjdk.org/jdk/pull/15038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313164 Stats: 13 lines in 1 file changed: 10 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15038/head:pull/15038 PR: https://git.openjdk.org/jdk/pull/15038 From aivanov at openjdk.org Wed Jul 26 11:06:00 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Jul 2023 11:06:00 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v4] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Wed, 26 Jul 2023 08:13:25 GMT, Tejesh R wrote: >> "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). >> CI testing shows green. >> After the fix at 225% scaling: >> ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 54: > 52: SwingUtilities.invokeAndWait(() -> { > 53: test(); > 54: }); Suggestion: SwingUtilities.invokeAndWait(JTableHeaderLabelRightAlignTest::test); Let's resolve the warning from IDEA. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 58: > 56: > 57: private static void test() { > 58: JTable table; `JTable` is subject to the same rule: declare it where it's first used. There's no need to declare all the local variables in advance. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 64: > 62: }; > 63: > 64: String[] columnNames = { "Size", "Size"}; Suggestion: {"1", "1"} }; String[] columnNames = {"Size", "Size"}; The spaces are either on both sides or neither side. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 69: > 67: table.setSize(WIDTH, HEIGHT); > 68: ((JLabel)table.getTableHeader().getDefaultRenderer()) > 69: .setHorizontalAlignment( JLabel.RIGHT ); Suggestion: .setHorizontalAlignment(JLabel.RIGHT); No spaces inside the parentheses. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 77: > 75: int w = (int)Math.ceil(SCALE * size.width); > 76: int h = (int)Math.ceil(SCALE * size.height); > 77: BufferedImage imgHeader = new BufferedImage((w), (h), Suggestion: BufferedImage imgHeader = new BufferedImage(w, h, Reduce the noise by removing the redundant parentheses. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 97: > 95: ImageIO.write(imgHeader, "png", > 96: new File("FailureImage.png")); > 97: } catch (IOException ioException){ Suggestion: } catch (IOException ioException) { test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 100: > 98: ioException.printStackTrace(); > 99: } > 100: throw new RuntimeException("Test Failed"); Can you add the coordinates to the failure message? It will greatly help anyone who will be dealing with the test failure in the future. ------------- PR Review: https://git.openjdk.org/jdk/pull/14464#pullrequestreview-1547394594 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274787037 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274745113 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274780474 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274781411 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274782429 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274783146 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1274785323 From mbaesken at openjdk.org Wed Jul 26 11:12:41 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Jul 2023 11:12:41 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources In-Reply-To: References: Message-ID: <8ZrzKjY18T5t612T33WiYeI_t0wn5CHI-jIhhMQDTt0=.155e11b8-7f6d-45e0-a4e1-ed8846b37650@github.com> On Wed, 26 Jul 2023 10:43:20 GMT, Matthias Baesken wrote: > In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. > However this should be done as well in some early leaving with throw that can occur in this function. One additional idea - in case of failing IS_SAFE* checks (leading to the throw astd::bad_alloc) , should we add some tracing to make clear what went wrong ? We have J2dTraceLn1 / J2dTraceLn for this; unfortunately it seems to be only active for DEBUG-builds . ------------- PR Comment: https://git.openjdk.org/jdk/pull/15038#issuecomment-1651569809 From tr at openjdk.org Wed Jul 26 11:29:22 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 11:29:22 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v5] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/dec7dc01..07861e5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=03-04 Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From tr at openjdk.org Wed Jul 26 11:32:29 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Jul 2023 11:32:29 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v8] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/343915c4..d04dc7b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=06-07 Stats: 9 lines in 1 file changed: 2 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From stuefe at openjdk.org Wed Jul 26 11:34:42 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Jul 2023 11:34:42 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources In-Reply-To: References: Message-ID: <-HeYFqQivj_jHs6ARZbfk1pZ8GCsgFYMdv24vnknS-8=.b6c20cc0-0e74-4a8f-8c8a-dafae11f3001@github.com> On Wed, 26 Jul 2023 10:43:20 GMT, Matthias Baesken wrote: > In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. > However this should be done as well in some early leaving with throw that can occur in this function. Okay. Did you find this with SonarCloud? Since this is c++, it may be simpler to use RAII for this. Up to you though, the patch is also fine in its current form. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15038#pullrequestreview-1547515501 From mbaesken at openjdk.org Wed Jul 26 11:59:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Jul 2023 11:59:06 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources [v2] In-Reply-To: References: Message-ID: > In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. > However this should be done as well in some early leaving with throw that can occur in this function. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust checks and calculation of numPixels ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15038/files - new: https://git.openjdk.org/jdk/pull/15038/files/9403dc41..95283db0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15038&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15038&range=00-01 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15038/head:pull/15038 PR: https://git.openjdk.org/jdk/pull/15038 From azvegint at openjdk.org Wed Jul 26 12:07:53 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 26 Jul 2023 12:07:53 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: <1CzzHufBB1uf4zrF3_1n-HEQbCnTGWpWrYasIu0-AiM=.869ac8e6-3f96-4b75-a7e1-a52f8ab97317@github.com> On Mon, 24 Jul 2023 20:24:23 GMT, Phil Race wrote: >> There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: >> >> >> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: >> In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: >> /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] >> #elif __GNUC__ >= 7 || __clang_major__ >= 10 >> ^~~~~~~~~~~~~~~ >> >> >> There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. >> >> (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) >> >> Additional testing: >> - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) > > src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h line 62: > >> 60: # define SPA_FALLTHROUGH [[clang::fallthrough]]; >> 61: #elif defined(__GNUC__) && __GNUC__ >= 7 >> 62: # define SPA_FALLTHROUGH __attribute__ ((fallthrough)); > > Upstream still has this issue/bug. > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/include/spa/utils/defs.h > Do they intend to support only GNUC 7 and up ? Not clear. Best to ask. Ideally, this should be fixed upstream, but while we wait, we can try to fix the build failure in our source by adding definition of `__clang_major__` just before including the [pipewire/stream.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h#L36) // some comment why we are doing this #ifndef __clang_major__ #define __clang_major__ 0 #endif It looks like that the `defs.h` is the only file that uses `__clang_major__` in libxawt, so this define should be safe. But the question of GCC < 7 support remains open. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1274858361 From mbaesken at openjdk.org Wed Jul 26 12:56:50 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Jul 2023 12:56:50 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 11:59:06 GMT, Matthias Baesken wrote: >> In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. >> However this should be done as well in some early leaving with throw that can occur in this function. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust checks and calculation of numPixels Hi Thomas , I just found those while looking at some other resource alloc/freeing, no Sonatype or similar was used. Regarding RAII , not sure if something like this is used in the awt native code (or are there some good examples in awt native code?) . So I better keep it as it is, to be consistent with the codebase around it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15038#issuecomment-1651748809 From shade at openjdk.org Wed Jul 26 17:40:41 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 26 Jul 2023 17:40:41 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: <1CzzHufBB1uf4zrF3_1n-HEQbCnTGWpWrYasIu0-AiM=.869ac8e6-3f96-4b75-a7e1-a52f8ab97317@github.com> References: <1CzzHufBB1uf4zrF3_1n-HEQbCnTGWpWrYasIu0-AiM=.869ac8e6-3f96-4b75-a7e1-a52f8ab97317@github.com> Message-ID: On Wed, 26 Jul 2023 12:05:13 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h line 62: >> >>> 60: # define SPA_FALLTHROUGH [[clang::fallthrough]]; >>> 61: #elif defined(__GNUC__) && __GNUC__ >= 7 >>> 62: # define SPA_FALLTHROUGH __attribute__ ((fallthrough)); >> >> Upstream still has this issue/bug. >> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/include/spa/utils/defs.h >> Do they intend to support only GNUC 7 and up ? Not clear. Best to ask. > > Ideally, this should be fixed upstream, but while we wait, we can try to fix the build failure in our source by adding definition of `__clang_major__` just before including the [pipewire/stream.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h#L36) > > > // some comment why we are doing this > #ifndef __clang_major__ > #define __clang_major__ 0 > #endif > > > It looks like that the `defs.h` is the only file that uses `__clang_major__` in libxawt, so this define should be safe. > > > But the question of GCC < 7 support remains open. Um. If we want to minimize divergence with upstream, defining `__clang_major__` seems riskier than rewriting a single block that uses it incorrectly. Because I cannot be sure if _any other_ `ifdef` that checks `__clang_major__` would work correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1275292579 From prr at openjdk.org Wed Jul 26 17:51:52 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 26 Jul 2023 17:51:52 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) I submitted https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3386 to see what upstream say. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14995#issuecomment-1652251023 From aivanov at openjdk.org Wed Jul 26 18:21:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Jul 2023 18:21:56 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v5] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Wed, 26 Jul 2023 11:29:22 GMT, Tejesh R wrote: >> "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). >> CI testing shows green. >> After the fix at 225% scaling: >> ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 87: > 85: int expectedRGB = imgHeader.getRGB(verticalLine, 1); > 86: > 87: for (int y = 1; y < (imgHeader.getHeight() -3); y++) { Suggestion: for (int y = 1; y < (imgHeader.getHeight() - 3); y++) { test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 88: > 86: > 87: for (int y = 1; y < (imgHeader.getHeight() -3); y++) { > 88: for (int x = verticalLine; x < verticalLine + 1; x++) { This means `x` is always equal to `verticalLine`, does it? Is the for-loop needed then? test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 96: > 94: ioException.printStackTrace(); > 95: } > 96: throw new RuntimeException("Test Failed at Pos_x : " + x + ", Pos_y : " + y ); Perhaps, "Test failed at " would be enough but I'm nitpicking? More importantly, for me the test fails at 168, 24 which falls between the header cells, more specifically between the shadow and highlight. Should we verify the colours to the left of shadow border? In the updated version, the `verticalLine` is at the same location. The text in the first column touches the shadow border of the header cell; the text in the second column has 1-pixel gap. With the increased insets, I expected that the text wouldn't touch the shadow. At the same time, I can *confirm the fix is correct*: the header cell has 1-pixel border, the insets reserved the space for the 1-pixel border and 1-pixel gap; the right column didn't but it should have. Because of rounding, the header cells still look inconsistent. At 225%, 2-pixel inset is 4.5 pixels but fractional pixels are impossible, and this contributes the offsets we see in the image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1275287311 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1275287142 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1275281294 From jiangli at openjdk.org Wed Jul 26 20:20:53 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 26 Jul 2023 20:20:53 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 04:27:47 GMT, Sergey Bylokhov wrote: >> Please review the simple fix that changes start|stop_timer to static. > > I was thinking of asking you to see if there are any other variables or functions in this file that could be made static, but it looks like xx_timer are the only one left. Can you please confirm? @mrserb and other reviewers, please help approve the PR if no additional questions. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15006#issuecomment-1652435106 From jlu at openjdk.org Wed Jul 26 20:47:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 26 Jul 2023 20:47:11 GMT Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update Message-ID: Please review this PR which contains the IPS translations for updates to localized resources in the JDK since RDP1. Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN. The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations). - src/java.base/share/classes/sun/launcher/resources/launcher.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/. ------------- Commit messages: - Revert zh_CN translation of 'private' for consistency - Revert IPS newline changes to MsiInstallerStrings_en.wxl - Move CurrencyNames_xx.properties to jdk.localedata (no changes) - Remove extra quotes in 'main.usage' values in jdeprscan - Revert WinResources changing of 'resource.wxl-file-name' value - Standardize trailing WS in l10n.properties - Revert MsiInstallerStrings culture value changes - Apply WS Tool - Apply IPS translations Changes: https://git.openjdk.org/jdk/pull/15047/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15047&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312572 Stats: 223 lines in 32 files changed: 36 ins; 15 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/15047.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15047/head:pull/15047 PR: https://git.openjdk.org/jdk/pull/15047 From serb at openjdk.org Wed Jul 26 20:58:50 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Jul 2023 20:58:50 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> Message-ID: <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> On Tue, 25 Jul 2023 11:34:03 GMT, Renjith Kannath Pariyangad wrote: >>> @aivanov-jdk, Thank you for your time and reviews, `CoInitializeEx(NULL, 0)` also resolving this problem because as per document **The default is COINIT_MULTITHREADED**. >> >> This is what I expected, however, the documentation for [`COINIT`](https://learn.microsoft.com/en-us/windows/win32/api/objbase/ne-objbase-coinit) doesn't spell out the value for `COINIT_MULTITHREADED`. >> >>> In my debug session noticed `DirectSoundCaptureEnumerate` getting called ahead of thread call or ::CoInitialize and that was the root cause this failure. >> >> If it is the case, I can't see that you have ensured that `DirectSoundCaptureEnumerate` is called after `CoInitialize`. Do I miss anything? >> >>> For resolving this found 3 ways and all works: >>> >>> 1. Use COM multi-threading :- Simplest approach with respect to other solutions >> >> Probably? But it is still incorrect. Initialising COM on *a thread* doesn't mean you can call COM object methods from **any thread** in your application. >> >> As the documentation says, ?You need to initialize the COM library on a thread before you call any of the library functions?? (I have this very quote in [my comment above](https://github.com/openjdk/jdk/pull/14898#discussion_r1272027291).) >> >>> 2. Hold the call till CoInitialize : - Can end up in deadlock situation so that need to be taken care. >> >> It's a challenge but it is the only right way, as far as I can see? Perhaps not to wait till `::CoInitialize` is called on a thread (see above) but to transfer a call for handling to a thread where COM is initialised. >> >>> 3. Do another CoInitialize before call :- not a good approach >> >> Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. >> >> >>> _This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything?_ `DS_StartBufferHelper` class initializing COM in thread and all member functions checking initialization status before making any calls. So another solution may be restructure the code for accessing `isInitialized()` method from outer methods and proceed. (approach 2 in better way) >>> >>> Tried this approach with `::CoInitialize` and observed _truncated names_, but its not failing for lock unlock workflow. >> >> As I explained above, it would still be inco... > >> > @aivanov-jdk, Thank you for your time and reviews, `CoInitializeEx(NULL, 0)` also resolving this problem because as per document **The default is COINIT_MULTITHREADED**. >> >> This is what I expected, however, the documentation for [`COINIT`](https://learn.microsoft.com/en-us/windows/win32/api/objbase/ne-objbase-coinit) doesn't spell out the value for `COINIT_MULTITHREADED`. > > As per the declaration yes its 0 [tagCOINIT](https://github.com/wine-mirror/wine/blob/master/include/objbase.h) > >> > In my debug session noticed `DirectSoundCaptureEnumerate` getting called ahead of thread call or ::CoInitialize and that was the root cause this failure. > >> If it is the case, I can't see that you have ensured that `DirectSoundCaptureEnumerate` is called after `CoInitialize`. Do I miss anything? > > Yes, You are right in main thread no CoInitialize > >> > For resolving this found 3 ways and all works: >> > >> > 1. Use COM multi-threading :- Simplest approach with respect to other solutions >> >> Probably? But it is still incorrect. Initialising COM on _a thread_ doesn't mean you can call COM object methods from **any thread** in your application. >> >> As the documentation says, ?You need to initialize the COM library on a thread before you call any of the library functions?? (I have this very quote in [my comment above](https://github.com/openjdk/jdk/pull/14898#discussion_r1272027291).) >> >> > 2. Hold the call till CoInitialize : - Can end up in deadlock situation so that need to be taken care. >> >> It's a challenge but it is the only right way, as far as I can see? Perhaps not to wait till `::CoInitialize` is called on a thread (see above) but to transfer a call for handling to a thread where COM is initialised. > > These two approach didn't do ::CoInitialize in running thread (main thread) > >> > 3. Do another CoInitialize before call :- not a good approach >> >> Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. > > Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` > >> >> > _This implies that any thread which creates DirectSound objects must initialise COM first. I can't see it happening. Do I miss anything?_... > Probably? But it is still incorrect. Initialising COM on a thread doesn't mean you can call COM object methods from any thread in your application. Note that "Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time", so if we initialisethe devices on one thread using COM they will be avaliable on other threads as well. But the spec for DirectSoundEnumerate says nothing about COM... But from some examples I see ppl wrap it by the CoInitializeEx(NULL, COINIT_MULTITHREADED)/CoUninitialize(); Noe sure we can call CoInitializeEx on the main thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275476189 From aivanov at openjdk.org Wed Jul 26 21:18:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Jul 2023 21:18:53 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Wed, 26 Jul 2023 20:56:15 GMT, Sergey Bylokhov wrote: > > Probably? But it is still incorrect. Initialising COM on a thread doesn't mean you can call COM object methods from any thread in your application. > > Note that "Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time", so if we initialisethe devices on one thread using COM they will be avaliable on other threads as well. But from the threads where you initialised COM as MTA. The docs for `CoInitializeEx` clearly state you have to initialise COM before you can use it. Thus, calling methods of COM objects from an arbitrary thread in your application is wrong, isn't it? > But the spec for DirectSoundEnumerate says nothing about COM... But from some examples I see ppl wrap it by the CoInitializeEx(NULL, COINIT_MULTITHREADED)/CoUninitialize(); > > Noe sure we can call CoInitializeEx on the main thread. It's for any thread not only the main thread? You can all `AudioSystem.getMixerInfo` from any thread in a Java app, if `DirectSoundEnumerate` needs COM to be initialised even though the documentation doesn't mention it, we have to initalise COM. Thus there are two options: 1. Call `CoInitializeEx`, enumerate devices, and call `CoUninitialize`. 2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls `CoUninitialize`) if it doesn't receive more requests in a period of time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275489954 From aivanov at openjdk.org Wed Jul 26 21:18:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Jul 2023 21:18:53 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Wed, 26 Jul 2023 21:14:07 GMT, Alexey Ivanov wrote: >>> Probably? But it is still incorrect. Initialising COM on a thread doesn't mean you can call COM object methods from any thread in your application. >> >> Note that "Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time", so if we initialisethe devices on one thread using COM they will be avaliable on other threads as well. But the spec for DirectSoundEnumerate says nothing about COM... But from some examples I see ppl wrap it by the CoInitializeEx(NULL, COINIT_MULTITHREADED)/CoUninitialize(); >> >> Not sure we can call CoInitializeEx on the main thread. > >> > Probably? But it is still incorrect. Initialising COM on a thread doesn't mean you can call COM object methods from any thread in your application. >> >> Note that "Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time", so if we initialisethe devices on one thread using COM they will be avaliable on other threads as well. > > But from the threads where you initialised COM as MTA. > > The docs for `CoInitializeEx` clearly state you have to initialise COM before you can use it. Thus, calling methods of COM objects from an arbitrary thread in your application is wrong, isn't it? > >> But the spec for DirectSoundEnumerate says nothing about COM... But from some examples I see ppl wrap it by the CoInitializeEx(NULL, COINIT_MULTITHREADED)/CoUninitialize(); >> >> Noe sure we can call CoInitializeEx on the main thread. > > It's for any thread not only the main thread? You can all `AudioSystem.getMixerInfo` from any thread in a Java app, if `DirectSoundEnumerate` needs COM to be initialised even though the documentation doesn't mention it, we have to initalise COM. Thus there are two options: > > 1. Call `CoInitializeEx`, enumerate devices, and call `CoUninitialize`. > 2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls `CoUninitialize`) if it doesn't receive more requests in a period of time. > > > 3. Do another CoInitialize before call :- not a good approach > > > > Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. > > Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` Does this approach return full names for devices, without truncating them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275491546 From serb at openjdk.org Wed Jul 26 22:40:39 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Jul 2023 22:40:39 GMT Subject: RFR: 4893524: Swing drop targets should call close() on transferred readers and streams In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 07:15:56 GMT, Prasanta Sadhukhan wrote: > The issue here is a Reader(stream) is requested to handle a drop, via DataFlavor.getReaderForText(), and then the reader is completely read, but it isn't closed. It should be closed as soon as possible to release some native resources. > Fix is made to close the stream after it is being used Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15033#pullrequestreview-1548718997 From prr at openjdk.org Wed Jul 26 23:09:49 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 26 Jul 2023 23:09:49 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 10:21:52 GMT, Aleksey Shipilev wrote: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) Comment in the gitlab bug "this error is unrelated to the compiler version, it is rather caused by the -Werror=undef flag." So maybe we should ignore that, if possible just on the old tool chain ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14995#issuecomment-1652661833 From serb at openjdk.org Wed Jul 26 23:32:52 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Jul 2023 23:32:52 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Wed, 26 Jul 2023 21:16:11 GMT, Alexey Ivanov wrote: >>> > Probably? But it is still incorrect. Initialising COM on a thread doesn't mean you can call COM object methods from any thread in your application. >>> >>> Note that "Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time", so if we initialisethe devices on one thread using COM they will be avaliable on other threads as well. >> >> But from the threads where you initialised COM as MTA. >> >> The docs for `CoInitializeEx` clearly state you have to initialise COM before you can use it. Thus, calling methods of COM objects from an arbitrary thread in your application is wrong, isn't it? >> >>> But the spec for DirectSoundEnumerate says nothing about COM... But from some examples I see ppl wrap it by the CoInitializeEx(NULL, COINIT_MULTITHREADED)/CoUninitialize(); >>> >>> Noe sure we can call CoInitializeEx on the main thread. >> >> It's for any thread not only the main thread? You can all `AudioSystem.getMixerInfo` from any thread in a Java app, if `DirectSoundEnumerate` needs COM to be initialised even though the documentation doesn't mention it, we have to initalise COM. Thus there are two options: >> >> 1. Call `CoInitializeEx`, enumerate devices, and call `CoUninitialize`. >> 2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls `CoUninitialize`) if it doesn't receive more requests in a period of time. > >> > > 3. Do another CoInitialize before call :- not a good approach >> > >> > Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. >> >> Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` > > Does this approach return full names for devices, without truncating them? But if that code requare com my expectation would be that they call CoInitialize/CoUninitialize. This CoInitialize initially was added here https://bugs.openjdk.org/browse/JDK-6950553 (check the stack trace), https://github.com/openjdk/jdk/commit/b8b9c35567919f9f375cc3610d823524cf5b8582 can we check that the DAUDIO_GetDirectAudioDeviceDescription is really uses that com object w/o initialisation? >1. Call CoInitializeEx, enumerate devices, and call CoUninitialize. >2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls CoUninitialize) if it doesn't receive more requests in a period of time. We can try reuse the "Filechooser.invokeCom" machinery, but I do not think I like it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275574660 From serb at openjdk.org Wed Jul 26 23:38:43 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Jul 2023 23:38:43 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Wed, 26 Jul 2023 23:29:41 GMT, Sergey Bylokhov wrote: >>> > > 3. Do another CoInitialize before call :- not a good approach >>> > >>> > Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid. >>> >>> Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` >> >> Does this approach return full names for devices, without truncating them? > > But if that code requare com my expectation would be that they call CoInitialize/CoUninitialize. > > This CoInitialize initially was added here https://bugs.openjdk.org/browse/JDK-6950553 (check the stack trace), > https://github.com/openjdk/jdk/commit/b8b9c35567919f9f375cc3610d823524cf5b8582 can we check that the DAUDIO_GetDirectAudioDeviceDescription is really uses that com object w/o initialisation? >>1. Call CoInitializeEx, enumerate devices, and call CoUninitialize. >>2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls CoUninitialize) if it doesn't receive more requests in a period of time. > > We can try reuse the "Filechooser.invokeCom" machinery, but I do not think I like it. is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275577287 From dnguyen at openjdk.org Thu Jul 27 00:24:42 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 27 Jul 2023 00:24:42 GMT Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com> On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu wrote: > Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1. > > Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN. > > The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations). > > - src/java.base/share/classes/sun/launcher/resources/launcher.properties > - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties > - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties > > It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185: > 183: jshell.console.no.javadoc = > 184: jshell.console.do.nothing = Do nothing > 185: jshell.console.choice = Choice:\u0020 I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275600311 From serb at openjdk.org Thu Jul 27 00:29:51 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Jul 2023 00:29:51 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:09:17 GMT, Jiangli Zhou wrote: >> Please review the simple fix that changes start|stop_timer to static. > > Jiangli Zhou 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8312626 > - Change 'start|stop_timer' to be static. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15006#pullrequestreview-1548806690 From jiangli at openjdk.org Thu Jul 27 00:41:51 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 27 Jul 2023 00:41:51 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:09:17 GMT, Jiangli Zhou wrote: >> Please review the simple fix that changes start|stop_timer to static. > > Jiangli Zhou 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8312626 > - Change 'start|stop_timer' to be static. Thanks for the review and approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15006#issuecomment-1652738379 From jiangli at openjdk.org Thu Jul 27 00:52:19 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 27 Jul 2023 00:52:19 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code [v3] In-Reply-To: References: Message-ID: > Please review the simple fix that changes start|stop_timer to static. Jiangli Zhou 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8312626 - Merge branch 'master' into JDK-8312626 - Change 'start|stop_timer' to be static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15006/files - new: https://git.openjdk.org/jdk/pull/15006/files/223c3a74..887760f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=01-02 Stats: 1001 lines in 30 files changed: 521 ins; 106 del; 374 mod Patch: https://git.openjdk.org/jdk/pull/15006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15006/head:pull/15006 PR: https://git.openjdk.org/jdk/pull/15006 From duke at openjdk.org Thu Jul 27 03:41:04 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 27 Jul 2023 03:41:04 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v4] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Observations : > 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). > 2. For Play back device always loading proper device GUID irrespective of com Initialization. > > Test: > Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. > To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. > > Please review the changes and let me know your comments if any. > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Made separate CoInit for outer thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14898/files - new: https://git.openjdk.org/jdk/pull/14898/files/0999df8f..c721f88c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14898/head:pull/14898 PR: https://git.openjdk.org/jdk/pull/14898 From duke at openjdk.org Thu Jul 27 03:46:23 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 27 Jul 2023 03:46:23 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v5] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Observations : > 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). > 2. For Play back device always loading proper device GUID irrespective of com Initialization. > > Test: > Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. > To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. > > Please review the changes and let me know your comments if any. > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Added COM init for DAUDIO_GetDirectAudioDeviceDescription ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14898/files - new: https://git.openjdk.org/jdk/pull/14898/files/c721f88c..773544b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14898&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14898/head:pull/14898 PR: https://git.openjdk.org/jdk/pull/14898 From duke at openjdk.org Thu Jul 27 04:26:53 2023 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Thu, 27 Jul 2023 04:26:53 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 16 Mar 2023 08:33:35 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea Hello! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1652891259 From tr at openjdk.org Thu Jul 27 04:47:56 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 27 Jul 2023 04:47:56 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v5] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Wed, 26 Jul 2023 17:28:23 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 96: > >> 94: ioException.printStackTrace(); >> 95: } >> 96: throw new RuntimeException("Test Failed at Pos_x : " + x + ", Pos_y : " + y ); > > Perhaps, "Test failed at " would be enough but I'm nitpicking? > > More importantly, for me the test fails at 168, 24 which falls between the header cells, more specifically between the shadow and highlight. Should we verify the colours to the left of shadow border? > > In the updated version, the `verticalLine` is at the same location. The text in the first column touches the shadow border of the header cell; the text in the second column has 1-pixel gap. With the increased insets, I expected that the text wouldn't touch the shadow. > > At the same time, I can *confirm the fix is correct*: the header cell has 1-pixel border, the insets reserved the space for the 1-pixel border and 1-pixel gap; the right column didn't but it should have. > > Because of rounding, the header cells still look inconsistent. At 225%, 2-pixel inset is 4.5 pixels but fractional pixels are impossible, and this contributes the offsets we see in the image. I don't think we should verify the colors to the left of shadow border, for this particular test verifying right column of header border would do the job. VerticalLine is at the same location, can remove the for-loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1275725972 From tr at openjdk.org Thu Jul 27 04:53:28 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 27 Jul 2023 04:53:28 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v6] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/07861e5d..65b27b92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=04-05 Stats: 14 lines in 1 file changed: 2 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From tr at openjdk.org Thu Jul 27 04:56:51 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 27 Jul 2023 04:56:51 GMT Subject: RFR: 4893524: Swing drop targets should call close() on transferred readers and streams In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 07:15:56 GMT, Prasanta Sadhukhan wrote: > The issue here is a Reader(stream) is requested to handle a drop, via DataFlavor.getReaderForText(), and then the reader is completely read, but it isn't closed. It should be closed as soon as possible to release some native resources. > Fix is made to close the stream after it is being used Marked as reviewed by tr (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15033#pullrequestreview-1548997891 From tr at openjdk.org Thu Jul 27 04:58:33 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 27 Jul 2023 04:58:33 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v9] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/d04dc7b0..c11e059a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From duke at openjdk.org Thu Jul 27 04:59:48 2023 From: duke at openjdk.org (=?UTF-8?B?5p6B6YCf6JyX54mb?=) Date: Thu, 27 Jul 2023 04:59:48 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: <3Vk5sk6rxj4U8zSgYIn5rU_DOUGejldx6ChCjGKuZtg=.fca2627c-25bb-4adb-8c99-1960416846bf@github.com> On Thu, 16 Mar 2023 08:33:35 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea Any updates? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1652914080 From duke at openjdk.org Thu Jul 27 05:10:51 2023 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Thu, 27 Jul 2023 05:10:51 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: <3Vk5sk6rxj4U8zSgYIn5rU_DOUGejldx6ChCjGKuZtg=.fca2627c-25bb-4adb-8c99-1960416846bf@github.com> References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> <3Vk5sk6rxj4U8zSgYIn5rU_DOUGejldx6ChCjGKuZtg=.fca2627c-25bb-4adb-8c99-1960416846bf@github.com> Message-ID: On Thu, 27 Jul 2023 04:56:35 GMT, ???? wrote: > Any updates? Waiting for anyone to integrate... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1652920990 From jlu at openjdk.org Thu Jul 27 06:51:48 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 27 Jul 2023 06:51:48 GMT Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update In-Reply-To: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com> References: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com> Message-ID: On Thu, 27 Jul 2023 00:16:34 GMT, Damon Nguyen wrote: >> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1. >> >> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN. >> >> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations). >> >> - src/java.base/share/classes/sun/launcher/resources/launcher.properties >> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties >> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties >> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties >> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties >> >> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/. > > src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185: > >> 183: jshell.console.no.javadoc = >> 184: jshell.console.do.nothing = Do nothing >> 185: jshell.console.choice = Choice:\u0020 > > I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode. Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275806234 From mbaesken at openjdk.org Thu Jul 27 07:09:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Jul 2023 07:09:48 GMT Subject: Integrated: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 10:43:20 GMT, Matthias Baesken wrote: > In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. > However this should be done as well in some early leaving with throw that can occur in this function. This pull request has now been integrated. Changeset: b7545a69 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b7545a69a27f255cbf26071be5b88f6e3e6b3cd6 Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 mod 8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/15038 From duke at openjdk.org Thu Jul 27 09:32:53 2023 From: duke at openjdk.org (senluowx) Date: Thu, 27 Jul 2023 09:32:53 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: <38uByxzVHDByVFWOm7l6pebI7a4yxvyol6nZ5kwEmLw=.0e501b9e-58a1-427f-ae88-34184ef34668@github.com> On Wed, 28 Jun 2023 21:46:30 GMT, Nikita Provotorov wrote: > Hi, guys! I want to notice that JetBrains is working on the issue too and we're going to propose our own fix. This problem has existed for more than ten years, do you guys have time to plan ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1652972669 From duke at openjdk.org Thu Jul 27 10:20:54 2023 From: duke at openjdk.org (=?UTF-8?B?5p6B6YCf6JyX54mb?=) Date: Thu, 27 Jul 2023 10:20:54 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 16 Mar 2023 08:33:35 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [Community patch](https://github.com/prehonor/myJetBrainsRuntime) has been around for a long time, but no official fix has applied. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1653324898 From duke at openjdk.org Thu Jul 27 13:09:52 2023 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Thu, 27 Jul 2023 13:09:52 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 16 Mar 2023 08:33:35 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea All jdk versions have this issue. I really hope some to review this code. The code is easy and simple. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1653591264 From psadhukhan at openjdk.org Thu Jul 27 14:42:05 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Jul 2023 14:42:05 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge Message-ID: Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) ------------- Commit messages: - 4346610: Adding JSeparator to JToolBar pushes buttons added after separator to edge - 4346610: Adding JSeparator to JToolBar pushes buttons added after separator to edge - Merge branch 'master' of github.com:prsadhuk/jdk - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Revert "Fix" - Fix Changes: https://git.openjdk.org/jdk/pull/15054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4346610 Stats: 127 lines in 2 files changed: 126 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15054/head:pull/15054 PR: https://git.openjdk.org/jdk/pull/15054 From jiangli at openjdk.org Thu Jul 27 15:56:09 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 27 Jul 2023 15:56:09 GMT Subject: RFR: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code [v4] In-Reply-To: References: Message-ID: > Please review the simple fix that changes start|stop_timer to static. Jiangli Zhou 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: - Merge branch 'master' into JDK-8312626 - Merge branch 'master' into JDK-8312626 - Merge branch 'master' into JDK-8312626 - Change 'start|stop_timer' to be static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15006/files - new: https://git.openjdk.org/jdk/pull/15006/files/887760f0..363f2884 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15006&range=02-03 Stats: 1328 lines in 59 files changed: 850 ins; 208 del; 270 mod Patch: https://git.openjdk.org/jdk/pull/15006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15006/head:pull/15006 PR: https://git.openjdk.org/jdk/pull/15006 From aivanov at openjdk.org Thu Jul 27 16:15:46 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Jul 2023 16:15:46 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v5] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 03:46:23 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Observations : >> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry). >> 2. For Play back device always loading proper device GUID irrespective of com Initialization. >> >> Test: >> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem. >> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green. >> >> Please review the changes and let me know your comments if any. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Added COM init for DAUDIO_GetDirectAudioDeviceDescription I created a short native app, `SoundDevices.exe`, attached to the JBS with its source code in `SoundDevices.cpp`. By default, it calls `CoInitializeEx` but if you pass ?0? as the parameter, it does not initialise COM. I get the following output: C:\dev\audio>SoundDevices.exe 0 Sound Devices 000001A3168F1104 {1A29CAD2-72C7-40B4-A39B-94D71FC91E3F} Speakers (Realtek(R) Audio) {0.0.0.00000000}.{1a29cad2-72c7-40b4-a39b-94d71fc91e3f} Sound Capture Devices 000001A3168F0D24 {BDF35A00-B9AC-11D0-A619-00AA00A7C000} Microphone Array (Realtek(R) Au {0.0.1.00000000}.{473909c9-5435-4fb1-ab77-18838bdfa76c} C:\dev\audio>SoundDevices.exe 1 Sound Devices 000001A56FDB1104 {1A29CAD2-72C7-40B4-A39B-94D71FC91E3F} Speakers (Realtek(R) Audio) {0.0.0.00000000}.{1a29cad2-72c7-40b4-a39b-94d71fc91e3f} Sound Capture Devices 000001A56FDB0D24 {473909C9-5435-4FB1-AB77-18838BDFA76C} Microphone Array (Realtek(R) Audio) {0.0.1.00000000}.{473909c9-5435-4fb1-ab77-18838bdfa76c} (I removed Primary devices from the output above.) It confirms Renjith's observations: if COM isn't initialised, the description of the capture device, _Microphone Array_, gets truncated, and its GUID is different from the driver GUID. It get the same results on other systems where I ran the app. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1653929284 From aivanov at openjdk.org Thu Jul 27 16:25:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Jul 2023 16:25:57 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Wed, 26 Jul 2023 23:35:25 GMT, Sergey Bylokhov wrote: > is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later? It is not only possible, it is explicitly stated. If the threading mode is different, the function fails with `RPC_E_CHANGED_MODE`. > But if that code requare com my expectation would be that they call CoInitialize/CoUninitialize. Exactly! Microsoft docs don't state COM needs be initialised for enumerating devices but it looks like it needs to be. > This CoInitialize initially was added here [JDK-6950553](https://bugs.openjdk.org/browse/JDK-6950553) (check the stack trace) It somewhat confirms, you can't access COM without initialising it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1276530242 From aivanov at openjdk.org Thu Jul 27 16:32:52 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Jul 2023 16:32:52 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3] In-Reply-To: References: <5LKThfldekbsVmN8w04kdy6GriYiXsRxC8hkK_JHqBI=.fa485a88-4f4c-455b-a9ce-9a52e05145fe@github.com> <4oZHbsjz5m6PNM4V0-MBreFMOXVjtHWL6-1tyYKsp6s=.1f29c5ce-4a88-4716-b856-21841f6cd75a@github.com> Message-ID: On Thu, 27 Jul 2023 16:23:01 GMT, Alexey Ivanov wrote: >> is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later? > >> is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later? > > It is not only possible, it is explicitly stated. If the threading mode is different, the function fails with `RPC_E_CHANGED_MODE`. > >> But if that code requare com my expectation would be that they call CoInitialize/CoUninitialize. > > Exactly! Microsoft docs don't state COM needs be initialised for enumerating devices but it looks like it needs to be. > >> This CoInitialize initially was added here [JDK-6950553](https://bugs.openjdk.org/browse/JDK-6950553) (check the stack trace) > > It somewhat confirms, you can't access COM without initialising it. > We can try reuse the "Filechooser.invokeCom" machinery, but I do not think I like it. As things look now, I'm inclined to use a similar facility as `Filechooser.invokeCom` but separate and independent. I mean starting an executor service or a thread which initialises COM and handles enumeration requests. Or re-using that servicing thread that's already exists where COM initialisation was added by JDK-6950553. I couldn't find an explicit statement whether DirectSound objects require STA or support MTA. If everything works with MTA, I prefer switching to `::CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1276539431 From aivanov at openjdk.org Thu Jul 27 16:35:52 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Jul 2023 16:35:52 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> Message-ID: On Tue, 25 Jul 2023 07:01:35 GMT, Renjith Kannath Pariyangad wrote: > > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 > > It didn't, the test case still produces truncated names. > > Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. The latest code still produces truncated strings for the test case in JDK-8301846. Are there any other enumerations which need to be wrapped into COM initialisation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1653963395 From dnguyen at openjdk.org Thu Jul 27 16:55:51 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 27 Jul 2023 16:55:51 GMT Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update In-Reply-To: References: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com> Message-ID: On Thu, 27 Jul 2023 06:48:32 GMT, Justin Lu wrote: >> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185: >> >>> 183: jshell.console.no.javadoc = >>> 184: jshell.console.do.nothing = Do nothing >>> 185: jshell.console.choice = Choice:\u0020 >> >> I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode. > > Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change. Sure, I agree. Just checking to see if this was a product of the translation tool used, because if so, this might've been a mistake or issue with the tool. Looks fine here then ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1276566404 From naoto at openjdk.org Thu Jul 27 17:59:40 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 27 Jul 2023 17:59:40 GMT Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <_lkKzTNMcBXmMJ12xdYHuY7huc4G4sM7nPdN6ZtmrOk=.7b163449-bf71-4f74-a0aa-3881f0645dec@github.com> On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu wrote: > Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1. > > Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN. > > The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations). > > - src/java.base/share/classes/sun/launcher/resources/launcher.properties > - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties > - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties > > It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/. Haven't looked at each translation, but good to me overall. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15047#pullrequestreview-1550448645 From serb at openjdk.org Thu Jul 27 18:41:50 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Jul 2023 18:41:50 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) please merge from the latest master, it may fix the GA testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1654217719 From shade at openjdk.org Thu Jul 27 19:01:35 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 27 Jul 2023 19:01:35 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: Message-ID: > There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: > > > * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: > In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, > from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: > /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] > #elif __GNUC__ >= 7 || __clang_major__ >= 10 > ^~~~~~~~~~~~~~~ > > > There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. > > (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) > > Additional testing: > - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Disable the warnings instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14995/files - new: https://git.openjdk.org/jdk/pull/14995/files/3b521c69..30b6c36e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14995&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14995&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14995/head:pull/14995 PR: https://git.openjdk.org/jdk/pull/14995 From shade at openjdk.org Thu Jul 27 19:07:51 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 27 Jul 2023 19:07:51 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 19:01:35 GMT, Aleksey Shipilev wrote: >> There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: >> >> >> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: >> In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: >> /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] >> #elif __GNUC__ >= 7 || __clang_major__ >= 10 >> ^~~~~~~~~~~~~~~ >> >> >> There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. >> >> (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) >> >> Additional testing: >> - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Disable the warnings instead Yeah, we can just ignore the warnings. See new commit. I don't see a clean way to disable this only for specific GCC versions, and other warnings seem to be added without version checks too. I checked it still builds fine on GCC 6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14995#issuecomment-1654259008 From jiangli at openjdk.org Thu Jul 27 19:15:56 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 27 Jul 2023 19:15:56 GMT Subject: Integrated: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 00:13:12 GMT, Jiangli Zhou wrote: > Please review the simple fix that changes start|stop_timer to static. This pull request has now been integrated. Changeset: c55d29ff Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/c55d29ff119598a410e714ef36f47fb6626a1a7a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/15006 From prr at openjdk.org Thu Jul 27 19:40:53 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 27 Jul 2023 19:40:53 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: Message-ID: <8FFFmxkPSnwJcLBfmXJE2O1CdIi6Si3V7ooMi3AS1Q8=.9d9c6e53-9599-4c92-bbbf-613fa8c17586@github.com> On Thu, 27 Jul 2023 19:01:35 GMT, Aleksey Shipilev wrote: >> There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: >> >> >> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: >> In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: >> /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] >> #elif __GNUC__ >= 7 || __clang_major__ >= 10 >> ^~~~~~~~~~~~~~~ >> >> >> There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. >> >> (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) >> >> Additional testing: >> - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Disable the warnings instead Marked as reviewed by prr (Reviewer). make/modules/java.desktop/lib/Awt2dLibraries.gmk line 248: > 246: DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ > 247: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ > 248: DISABLED_WARNINGS_gcc_screencast_pipewire.c := undef, \ At least ignoring it just for the specific compilation units is not too bad. I'll approve but I'd like to see a comment here as to why its needed - ie just for gcc6 so people have an idea when we might be able to remove it and know not to remove it because it doesn't matter for the current compiler version. I've still asked upstream to consider applying your first version so that we'd not need this although perhaps it won't matter for long .. once no one cares about gcc6 because we need to move on for other reasons. ------------- PR Review: https://git.openjdk.org/jdk/pull/14995#pullrequestreview-1550625960 PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1276744373 From aivanov at openjdk.org Thu Jul 27 19:59:55 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Jul 2023 19:59:55 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 11:59:06 GMT, Matthias Baesken wrote: >> In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels we release some resources at the end of the function by calling DeleteObject/DeleteDC. This is recommended by the MS API docs. >> However this should be done as well in some early leaving with throw that can occur in this function. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust checks and calculation of numPixels src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp line 207: > 205: ::DeleteDC(hdcScreen); > 206: throw std::bad_alloc(); > 207: } I wonder if we can catch std::bad_alloc releases the resources and re-throw the exception. Since a C++ exception is thrown, using try-catch for clean-up seems reasonable, this would avoid duplicating the clean-up code in three places or so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15038#discussion_r1276761238 From jiefu at openjdk.org Thu Jul 27 23:38:51 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 27 Jul 2023 23:38:51 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 19:01:35 GMT, Aleksey Shipilev wrote: >> There is a simple build failure after [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982) with older GCCs: >> >> >> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o: >> In file included from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/buffer/buffer.h:12:0, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/pipewire/stream.h:171, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:36, >> from /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33: >> /home/buildbot/worker/build-jdkX-debian9/build/src/java.desktop/unix/native/libpipewire/include/spa/utils/defs.h:61:24: error: "__clang_major__" is not defined [-Werror=undef] >> #elif __GNUC__ >= 7 || __clang_major__ >= 10 >> ^~~~~~~~~~~~~~~ >> >> >> There is an obvious fix for this: we need to check for `defined(__GNUC__)` explicitly before touching `__clang_major__`. >> >> (Yes, GCC 6 is old; but we would like to make sure it builds until we run into hard to resolve build issues. This allows modern JDKs to be built in legacy enterprise environments for e.g. portable builds.) >> >> Additional testing: >> - [x] Linux GCC 6 fastdebug build (passes with HarfBuzz warnings, to be fixed separately) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Disable the warnings instead It seems better not touching the 3rd party source code. ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14995#pullrequestreview-1551001231 From psadhukhan at openjdk.org Fri Jul 28 02:24:49 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Jul 2023 02:24:49 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) Its not too old from latest master and I dont see any conflict being raised with the master and the commits will be quashed and right changes are being highlighted so I dont see any issue with the PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1654880192 From duke at openjdk.org Fri Jul 28 03:38:49 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 28 Jul 2023 03:38:49 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> Message-ID: On Thu, 27 Jul 2023 16:32:35 GMT, Alexey Ivanov wrote: >>> > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 >>> >>> It didn't, the test case still produces truncated names. >>> >>> Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. >> >> Partially fixing, with the fix this was the output on my machine : >> _mixer 0: >>Port Speakers (Realtek(R) Audio)<< >> mixer 1: >>Port Microphone Array (Realtek(R) Au<< >> mixer 2: >>Primary Sound Driver<< >> mixer 3: >>Speakers (Realtek(R) Audio)<< >> mixer 4: >>Primary Sound Capture Driver<< >> mixer 5: >>Microphone Array (Realtek(R) Audio)<<_ >> >> Without fix would be like this: _mixer 5: >>Microphone Array (Realtek(R) Au<<_ > >> > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 >> >> It didn't, the test case still produces truncated names. >> >> Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. > > The latest code still produces truncated strings for the test case in JDK-8301846. Are there any other enumerations which need to be wrapped into COM initialisation? @aivanov-jdk, thank you very much for your review, JDK-8301846 helps for fixing _Primary Sound Driver_ recording device name truncation issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1654939840 From serb at openjdk.org Fri Jul 28 04:06:00 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 28 Jul 2023 04:06:00 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) Your master is from Jun 12, 2023 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1654965643 From psadhukhan at openjdk.org Fri Jul 28 04:11:57 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Jul 2023 04:11:57 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) So? But the changed file is not being conflicted with any latest change in repo... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1654969621 From serb at openjdk.org Fri Jul 28 04:56:50 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 28 Jul 2023 04:56:50 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) but the testing in your GA shows builds failures on 3 platforms this is not present in any other PR right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1655002479 From psadhukhan at openjdk.org Fri Jul 28 06:45:51 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Jul 2023 06:45:51 GMT Subject: RFR: 4346610: Adding JSeparator to JToolBar "pushes" buttons added after separator to edge In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 14:30:23 GMT, Prasanta Sadhukhan wrote: > Adding buttons in a JToolBar after a JSeparator will push the button to the far right of the frame instead of just after the separator > > ![image](https://github.com/openjdk/jdk/assets/43534309/7fcad657-493f-4370-b046-b31c212a8aa7) > > This is because BasicSeparatorUI does not define a maximum size. This leads to the separator getting all the extra width. > Fix is made to limit the separator's maximum size to the preferred size of corresponding orientation (i.e. width for VERTICAL and height for HORIZONTAL) That can be safely ignored...As per my previous PRs, there also some tests fails but is not related to the change being done and does not hamper when integrated... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15054#issuecomment-1655118441 From shade at openjdk.org Fri Jul 28 07:46:51 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 28 Jul 2023 07:46:51 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: <8FFFmxkPSnwJcLBfmXJE2O1CdIi6Si3V7ooMi3AS1Q8=.9d9c6e53-9599-4c92-bbbf-613fa8c17586@github.com> References: <8FFFmxkPSnwJcLBfmXJE2O1CdIi6Si3V7ooMi3AS1Q8=.9d9c6e53-9599-4c92-bbbf-613fa8c17586@github.com> Message-ID: On Thu, 27 Jul 2023 19:37:33 GMT, Phil Race wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Disable the warnings instead > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 248: > >> 246: DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ >> 247: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ >> 248: DISABLED_WARNINGS_gcc_screencast_pipewire.c := undef, \ > > At least ignoring it just for the specific compilation units is not too bad. > > I'll approve but I'd like to see a comment here as to why its needed - ie just for gcc6 so people have an idea when we might be able to remove it and know not to remove it because it doesn't matter for the current compiler version. > > I've still asked upstream to consider applying your first version so that we'd not need this although perhaps it won't matter for long .. once no one cares about gcc6 because we need to move on for other reasons. There is no good way to put the comment straight into this block, AFAICS. Can we settle on repository history to tell future investigations why this was added? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1277221303 From mbaesken at openjdk.org Fri Jul 28 07:59:57 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 07:59:57 GMT Subject: RFR: JDK-8313252: Java_sun_awt_windows_ThemeReader_paintBackground release resources in early returns Message-ID: In file ThemeReader.cpp functionJava_sun_awt_windows_ThemeReader_paintBackground we create DCs and release them at the end, but seems we miss it in early returns. While looking at the code, I noticed that CreateCompatibleDC can return NULL in case of error/failure, but we ignore this case; see https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createcompatibledc . Should we better handle it or is it not really occurring in practise ? ------------- Commit messages: - JDK-8313252 Changes: https://git.openjdk.org/jdk/pull/15064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313252 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15064/head:pull/15064 PR: https://git.openjdk.org/jdk/pull/15064 From mbaesken at openjdk.org Fri Jul 28 08:04:57 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 08:04:57 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources [v2] In-Reply-To: References: Message-ID: <7vAAW4kRxX25CGtV0TplesVZZjr-HGLdTMT5KGuaOfo=.65ecb022-79cb-461b-bb26-c256b2ea50dd@github.com> On Thu, 27 Jul 2023 19:57:01 GMT, Alexey Ivanov wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust checks and calculation of numPixels > > src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp line 207: > >> 205: ::DeleteDC(hdcScreen); >> 206: throw std::bad_alloc(); >> 207: } > > I wonder if we can catch `std::bad_alloc` to release the resources and to re-throw the exception. > > Since a C++ exception is thrown, using try-catch for clean-up seems reasonable, this would avoid duplicating the clean-up code in three places or so. Hi Alexey, probably we could do this. Do you think it is worth the effort (we would have a big try catch block instead, but would centralize the ::Delete* calls) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15038#discussion_r1277239372 From clanger at openjdk.org Fri Jul 28 08:28:54 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 08:28:54 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values In-Reply-To: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: On Tue, 25 Jul 2023 11:17:23 GMT, Matthias Baesken wrote: > The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. > Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. > see > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte > especially > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value > > At most places in the coding the return values are already checked, but some are missing. Looks good, two minor suggestions. src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 3933: > 3931: JNU_ThrowByName(env, PRINTEREXCEPTION_STR, errStr); > 3932: } else { > 3933: JNU_ThrowByName(env, PRINTEREXCEPTION_STR, "Secondary error while OS message extraction"); better: secondary error during OS message extraction src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Charset_Util.cpp line 46: > 44: delete[] lpUTF8Str; > 45: } > 46: return NULL; better move `return NULL` into else block? ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15015#pullrequestreview-1551609451 PR Review Comment: https://git.openjdk.org/jdk/pull/15015#discussion_r1277259513 PR Review Comment: https://git.openjdk.org/jdk/pull/15015#discussion_r1277260378 From mbaesken at openjdk.org Fri Jul 28 09:45:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 09:45:53 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values In-Reply-To: References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: <_YT42xODAPXOFz55xNDuCnTbOIhLA2Q-N340FbfNk7M=.cab712bb-5dce-48f8-8479-7476f5aa9850@github.com> On Fri, 28 Jul 2023 08:23:35 GMT, Christoph Langer wrote: >> The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. >> Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. >> see >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte >> especially >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value >> >> At most places in the coding the return values are already checked, but some are missing. > > src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 3933: > >> 3931: JNU_ThrowByName(env, PRINTEREXCEPTION_STR, errStr); >> 3932: } else { >> 3933: JNU_ThrowByName(env, PRINTEREXCEPTION_STR, "Secondary error while OS message extraction"); > > better: secondary error during OS message extraction I borrowed it from here (other error handling of WideCharToMultiByte) jdk/src/java.base/windows/native/libjava/ProcessImpl_md.c 102 const char *errorMessage = "Secondary error while OS message extraction"; should I change both locations ? > src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Charset_Util.cpp line 46: > >> 44: delete[] lpUTF8Str; >> 45: } >> 46: return NULL; > > better move `return NULL` into else block? Better remove the else block :-) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15015#discussion_r1277339373 PR Review Comment: https://git.openjdk.org/jdk/pull/15015#discussion_r1277340457 From mbaesken at openjdk.org Fri Jul 28 09:58:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 09:58:01 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values [v2] In-Reply-To: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: > The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. > Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. > see > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte > especially > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value > > At most places in the coding the return values are already checked, but some are missing. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: small adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15015/files - new: https://git.openjdk.org/jdk/pull/15015/files/cf5e9a67..3cf91afb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15015&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15015/head:pull/15015 PR: https://git.openjdk.org/jdk/pull/15015 From alexsch at openjdk.org Fri Jul 28 10:28:55 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Fri, 28 Jul 2023 10:28:55 GMT Subject: Integrated: 8311033: [macos] PrinterJob does not take into account Sides attribute In-Reply-To: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> References: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@github.com> Message-ID: <8HF42SE_GljqHeiosFHJJnjqTafwtY9eyhw6nGJ02jo=.7b8a8e50-73df-42a5-a929-56047bb2af75@github.com> On Fri, 30 Jun 2023 10:00:46 GMT, Alexander Scherbatiy wrote: > To reproduce the issue run the [JavaSidesAttributePrinting](https://bugs.openjdk.org/secure/attachment/104448/JavaSidesAttributePrinting.java) java sample with ONE_SIDED and DUPLEX arguments on macOS: > > java JavaSidesAttributePrinting ONE_SIDED > java JavaSidesAttributePrinting DUPLEX > > > The sample calls PrinterJob print method with the given sides attribute. > The pages are printed according to the printer default settings not according to the provided Sides attributes. > > The fix propagates Sides attribute > - from `PrinterJob` to `NSPrintInfo` in `CPrinterJob.javaPrinterJobToNSPrintInfo` method > - from `NSPrintInfo` to `PrinterJob` in `CPrinterJob.nsPrintInfoToJavaPrinterJob` method This pull request has now been integrated. Changeset: a3d67231 Author: Alexander Scherbatiy URL: https://git.openjdk.org/jdk/commit/a3d67231a71fbe37c509fcedd54c679b4644c0d9 Stats: 335 lines in 4 files changed: 335 ins; 0 del; 0 mod 8311033: [macos] PrinterJob does not take into account Sides attribute Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/14727 From tr at openjdk.org Fri Jul 28 10:50:57 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 10:50:57 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v5] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 10:56:28 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix @azvegint @DamonGuy Please let me know if there are any more review suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14825#issuecomment-1655478664 From tr at openjdk.org Fri Jul 28 10:51:53 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 10:51:53 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v6] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com> Message-ID: <3DgVv3SQvtegPOvI7O5UcMzTA1kPJ3EfVifGHqxXd5k=.752fabec-54f2-4d40-9b26-42d70971861e@github.com> On Tue, 4 Jul 2023 14:30:35 GMT, Alexey Ivanov wrote: >> @prrace @aivanov-jdk I don't see much impact w.r.t to Label position/width for different scaling factors. >> The width is computed in [stringWidth(String)](https://github.com/openjdk/jdk/blob/48e61c1df53c11ed49603abd70a3dd62a25f7be5/src/java.desktop/share/classes/sun/font/FontDesignMetrics.java#L457) which is same for all scaling factors (though their are slight differences between scaling factor, its corrected due to 0.5 addition at the end). The position is computed in [layoutCompoundLabelImpl()](https://github.com/openjdk/jdk/blame/526dba1a2942e444bf11d03d8eaf014b5ef20ccf/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1073) which seems to be correct, since the calculation for XPos which is `dx = (viewR.x + viewR.width) - (labelR_x + labelR_width);` seems straight forward. >> Is there anything else which I should check or can we move ahead with current fix i.e., setting margin to 2pixels for RIGHT Aligned header text for Metal L&F? >> Parallelly I will raise a bug and PR for header border alignment. > > @TejeshR13 I agree it looks correct, I can't spot any differences. Does `JLabel` always position the text correctly? If you make `JLabel` right-aligned, do you see any pixels which aren't painted as expected? @aivanov-jdk @kumarabhi006 Please let me know if there are any more review suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1655480573 From tr at openjdk.org Fri Jul 28 10:52:55 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 10:52:55 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines In-Reply-To: References: Message-ID: <-zJe_f3vaQrBNuNJo4I2BXT4RP_IWlh6RmAurt5wUVA=.4f4b3070-6f8a-419f-b370-5ae50765c355@github.com> On Wed, 5 Jul 2023 12:46:26 GMT, Alexey Ivanov wrote: >>> > > That gap is caused because of alignment miss-match between vertical lines of header border and data grid lines. To be specific the header vertical line is slightly left (around a pixel) than data grid line. >>> > >>> > >>> > Is it require to address? >>> >>> I'd rather say ?yes?. Since you're trying to improve border rendering, it's better to fix this inconsistency too. >>> >>> But to get pixel-perfect rendering, you may need to remove the scale transform. >> >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > >> I'm not sure if it is a bug, the gap is because of white lines drawn for each header cell (bottom-left till top-left and then to to-right for each header cell). Kind of shade effect. > > I admit I am confused to which part it refers. > > I re-checked your after screenshot and it looks fine to me. The shadow is followed by white highlight. There was background colour seen between these two colours in the before-fix screenshot. > > There's still a 2-pixel background colour under the highlight. Yet it is present in the before-fix too, so it looks it is designed this way for a smoother 3D shading effect. @aivanov-jdk Please let me know if there are any more review suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14766#issuecomment-1655481438 From tr at openjdk.org Fri Jul 28 11:03:18 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 11:03:18 GMT Subject: RFR: 8312075: FileChooser.win32.newFolder is not updated when changing Locale Message-ID: <_XawiMouFRVn_letIBC3AceK-hMGomSenF5c-MjFCic=.a14a5114-0619-4456-8d89-29665d6623e5@github.com> On `NewFolderAction`, plain String is added `Action.ACTION_COMMAND_KEY`. Converting the `String `to `locale` before adding as command key fix the issue. I have verified the test in all other platforms and Look and Feel which has option to create New Folder, results were fine. No regressions found on CI system with the fix. Added manual test to verify the fix. ------------- Commit messages: - Whitespace removal - Fix + Manual Test Changes: https://git.openjdk.org/jdk/pull/15069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312075 Stats: 129 lines in 3 files changed: 128 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15069/head:pull/15069 PR: https://git.openjdk.org/jdk/pull/15069 From azvegint at openjdk.org Fri Jul 28 11:07:53 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jul 2023 11:07:53 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 10:51:03 GMT, Tejesh R wrote: >> test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 113: >> >>> 111: } >>> 112: } else if (windowList.get(windowList.size() - 1).getBounds(). >>> 113: intersects(screens[1].getDefaultConfiguration().getBounds())) { >> >> What if user has more than 2 screens? >> It looks like the 3rd and subsequent screens are not tested. > > I have made the validation as per number of screens now. I guess this is fine to check multiple screens. I don't see why we should be limited to only two when more may be available. What if it helps to find some issue? Anyway, the test place windows on all screens, but checking only on two of them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277412129 From azvegint at openjdk.org Fri Jul 28 11:19:53 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jul 2023 11:19:53 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: <8FFFmxkPSnwJcLBfmXJE2O1CdIi6Si3V7ooMi3AS1Q8=.9d9c6e53-9599-4c92-bbbf-613fa8c17586@github.com> Message-ID: On Fri, 28 Jul 2023 07:43:26 GMT, Aleksey Shipilev wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 248: >> >>> 246: DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ >>> 247: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ >>> 248: DISABLED_WARNINGS_gcc_screencast_pipewire.c := undef, \ >> >> At least ignoring it just for the specific compilation units is not too bad. >> >> I'll approve but I'd like to see a comment here as to why its needed - ie just for gcc6 so people have an idea when we might be able to remove it and know not to remove it because it doesn't matter for the current compiler version. >> >> I've still asked upstream to consider applying your first version so that we'd not need this although perhaps it won't matter for long .. once no one cares about gcc6 because we need to move on for other reasons. > > There is no good way to put the comment straight into this block, AFAICS. Can we settle on repository history to tell future investigations why this was added? How about using a variable with a useful name? e.g.: `DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK := undef` ... DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ DISABLED_WARNINGS_gcc_screencast_pipewire.c := $(DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK), \ DISABLED_WARNINGS_gcc_screencast_portal.c := $(DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK), \ DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1277421170 From tr at openjdk.org Fri Jul 28 11:20:53 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 11:20:53 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: References: Message-ID: <_tOOr09nLSNk_DxWhKJREDeSpbdM1WY3wGUFcL-T8WM=.e0382c2f-6ead-4cea-901f-273c0d7a0c1a@github.com> On Fri, 28 Jul 2023 11:04:33 GMT, Alexander Zvegintsev wrote: >> I have made the validation as per number of screens now. I guess this is fine to check multiple screens. > > I don't see why we should be limited to only two when more may be available. > What if it helps to find some issue? > Anyway, the test place windows on all screens, but checking only on two of them. I have updated the test to available screens (Though not able to test since I can extend to two screens now), I guess it should work, it's generic now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277422068 From clanger at openjdk.org Fri Jul 28 11:35:50 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 11:35:50 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values [v2] In-Reply-To: References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: On Fri, 28 Jul 2023 09:58:01 GMT, Matthias Baesken wrote: >> The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. >> Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. >> see >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte >> especially >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value >> >> At most places in the coding the return values are already checked, but some are missing. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > small adjustments Even better. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15015#pullrequestreview-1551930333 From mbaesken at openjdk.org Fri Jul 28 11:35:50 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 11:35:50 GMT Subject: RFR: JDK-8312612: handle WideCharToMultiByte return values [v2] In-Reply-To: References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: On Fri, 28 Jul 2023 09:58:01 GMT, Matthias Baesken wrote: >> The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. >> Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. >> see >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte >> especially >> https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value >> >> At most places in the coding the return values are already checked, but some are missing. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > small adjustments Hi Christoph, thanks for the review. The Windows aarch64 build errors seems to be unrelated (but should maybe still be addressed, but other issue). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15015#issuecomment-1655530976 From azvegint at openjdk.org Fri Jul 28 11:53:55 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jul 2023 11:53:55 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v5] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 10:56:28 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by azvegint (Reviewer). test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 102: > 100: robot.delay(50); > 101: robot.waitForIdle(); > 102: if (windowList.get(windowList.size() - 1).getBounds().intersects Maybe it's better to make `createWindow(r)` return a window and cache it instead of several querying of windowList? test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 103: > 101: robot.waitForIdle(); > 102: if (windowList.get(windowList.size() - 1).getBounds().intersects > 103: (screen.getDefaultConfiguration().getBounds())) { Looks like you can reuse `screenBounds` variable for lines 103 and 106. test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 130: > 128: public void mouseClicked(MouseEvent e) { > 129: ((Window) e.getSource()).dispose(); > 130: } New line missing. ------------- PR Review: https://git.openjdk.org/jdk/pull/14825#pullrequestreview-1551942043 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277439644 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277435451 PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277439874 From aivanov at openjdk.org Fri Jul 28 12:14:03 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 12:14:03 GMT Subject: RFR: JDK-8313164: src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels adjust releasing of resources [v2] In-Reply-To: <7vAAW4kRxX25CGtV0TplesVZZjr-HGLdTMT5KGuaOfo=.65ecb022-79cb-461b-bb26-c256b2ea50dd@github.com> References: <7vAAW4kRxX25CGtV0TplesVZZjr-HGLdTMT5KGuaOfo=.65ecb022-79cb-461b-bb26-c256b2ea50dd@github.com> Message-ID: On Fri, 28 Jul 2023 08:02:22 GMT, Matthias Baesken wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp line 207: >> >>> 205: ::DeleteDC(hdcScreen); >>> 206: throw std::bad_alloc(); >>> 207: } >> >> I wonder if we can catch `std::bad_alloc` to release the resources and to re-throw the exception. >> >> Since a C++ exception is thrown, using try-catch for clean-up seems reasonable, this would avoid duplicating the clean-up code in three places or so. > > Hi Alexey, probably we could do this. Do you think it is worth the effort (we would have a big try catch block instead, but would centralize the ::Delete* calls) ? Since you've already integrated, it's not worth redoing in my opinion. Error handling in C and C++ code is always prone to repetitive sequence of calls; in this particular case exceptions are already used, and it looks that handling that exception could have had a benefit of reducing code duplication. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15038#discussion_r1277472496 From aivanov at openjdk.org Fri Jul 28 12:32:55 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 12:32:55 GMT Subject: RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v2] In-Reply-To: References: <2ypYZPzMT_eGwk4Awqfuf0HTlyQ2_FlqlZzzX_dCquc=.e9b2f4eb-19b6-4802-b278-78a223d10486@github.com> Message-ID: On Thu, 27 Jul 2023 16:32:35 GMT, Alexey Ivanov wrote: >>> > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 >>> >>> It didn't, the test case still produces truncated names. >>> >>> Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. >> >> Partially fixing, with the fix this was the output on my machine : >> _mixer 0: >>Port Speakers (Realtek(R) Audio)<< >> mixer 1: >>Port Microphone Array (Realtek(R) Au<< >> mixer 2: >>Primary Sound Driver<< >> mixer 3: >>Speakers (Realtek(R) Audio)<< >> mixer 4: >>Primary Sound Capture Driver<< >> mixer 5: >>Microphone Array (Realtek(R) Audio)<<_ >> >> Without fix would be like this: _mixer 5: >>Microphone Array (Realtek(R) Au<<_ > >> > I think this patch would also address https://bugs.openjdk.org/browse/JDK-7116070 >> >> It didn't, the test case still produces truncated names. >> >> Although, the mixer name used for recording in the stand-alone test attached to [JDK-8301846](https://bugs.openjdk.org/browse/JDK-8301846) is not truncated any more. > > The latest code still produces truncated strings for the test case in ~~JDK-8301846~~ JDK-7116070. Are there any other enumerations which need to be wrapped into COM initialisation? > @aivanov-jdk, thank you very much for your review, JDK-8301846 helps for fixing _Primary Sound Driver_ recording device name truncation issue. I referred to JDK-7116070. The root cause of that problem seems to be same as this one. While you and the reviewers have all the context, I suggest looking into JDK-7116070 in more details to understand why there are still devices, or rather *ports*, with truncated descriptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1655609298 From shade at openjdk.org Fri Jul 28 13:41:50 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 28 Jul 2023 13:41:50 GMT Subject: RFR: 8312591: GCC 6 build failure after JDK-8280982 [v2] In-Reply-To: References: <8FFFmxkPSnwJcLBfmXJE2O1CdIi6Si3V7ooMi3AS1Q8=.9d9c6e53-9599-4c92-bbbf-613fa8c17586@github.com> Message-ID: On Fri, 28 Jul 2023 11:16:41 GMT, Alexander Zvegintsev wrote: >> There is no good way to put the comment straight into this block, AFAICS. Can we settle on repository history to tell future investigations why this was added? > > How about using a variable with a useful name? e.g.: > > `DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK := undef` > ... > > > DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ > DISABLED_WARNINGS_gcc_screencast_pipewire.c := $(DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK), \ > DISABLED_WARNINGS_gcc_screencast_portal.c := $(DISABLED_FOR_NOT_COMPLETE_COMPILER_CHECK), \ > DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ Let's not over-complicate this? Most (all?) warning exclusions I saw were are added without checking for toolchain version. Limiting blast radius to just a toolchain and compilation unit seems good already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14995#discussion_r1277558524 From mbaesken at openjdk.org Fri Jul 28 13:48:58 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Jul 2023 13:48:58 GMT Subject: Integrated: JDK-8312612: handle WideCharToMultiByte return values In-Reply-To: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> References: <-qlCjtVbK-Y8R3kQCHMuMd6_SDs-pijQDOkyxg6ZA9w=.0253f5b4-e31f-405e-a593-e5b77350bf6a@github.com> Message-ID: On Tue, 25 Jul 2023 11:17:23 GMT, Matthias Baesken wrote: > The function WideCharToMultiByte is used at a number of places of the JDK codebase for conversion purposes. > Unfortunately, the function might fail because of various reasons, so the return value must be checked to avoid undefined behavior or even crashes. > see > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte > especially > https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#return-value > > At most places in the coding the return values are already checked, but some are missing. This pull request has now been integrated. Changeset: d9559f9b Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d9559f9b24ee76c074cefcaf256d11ef5a7cc5b7 Stats: 32 lines in 3 files changed: 19 ins; 0 del; 13 mod 8312612: handle WideCharToMultiByte return values Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jdk/pull/15015 From aivanov at openjdk.org Fri Jul 28 14:30:49 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 14:30:49 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v6] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: On Thu, 27 Jul 2023 04:53:28 GMT, Tejesh R wrote: >> "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). >> CI testing shows green. >> After the fix at 225% scaling: >> ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Looks good to me. test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 84: > 82: > 83: int x = (int)(table.getTableHeader(). > 84: getColumnModel().getColumn(0).getWidth() * SCALE); Suggestion: int x = (int)(table.getTableHeader() .getColumnModel().getColumn(0).getWidth() * SCALE); It's a matter of (my) preference, and it's stated in Java Coding Style that wrapping the operator to the next line makes it clearer it's a continuation line. I'd wrap on each method call: int x = (int)(table.getTableHeader() .getColumnModel() .getColumn(0) .getWidth() * SCALE); test/jdk/javax/swing/JTableHeader/JTableHeaderLabelRightAlignTest.java line 96: > 94: } > 95: throw new RuntimeException("Test Failed at <" + > 96: x + ", " + y + ">"); Suggestion: throw new RuntimeException("Test Failed at <" + x + ", " + y + ">"); It doesn't fit 80-column limit, but I think it is okay to keep it on one line without wrapping. It doesn't affect the readability of the code, and it's only 5 chars above the limit. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14464#pullrequestreview-1552214586 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1277608914 PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1277600275 From tr at openjdk.org Fri Jul 28 15:23:24 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 15:23:24 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v6] In-Reply-To: References: Message-ID: <002hY75seVjpqpOjCNeavMiSXH7HgLdjll8u_X-Kyz0=.dbad3731-0e83-4f96-be95-412e53ce52e4@github.com> > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/4e47192a..c21052a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=04-05 Stats: 13 lines in 1 file changed: 4 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From azvegint at openjdk.org Fri Jul 28 15:23:26 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jul 2023 15:23:26 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v3] In-Reply-To: <_tOOr09nLSNk_DxWhKJREDeSpbdM1WY3wGUFcL-T8WM=.e0382c2f-6ead-4cea-901f-273c0d7a0c1a@github.com> References: <_tOOr09nLSNk_DxWhKJREDeSpbdM1WY3wGUFcL-T8WM=.e0382c2f-6ead-4cea-901f-273c0d7a0c1a@github.com> Message-ID: On Fri, 28 Jul 2023 11:17:42 GMT, Tejesh R wrote: >> I don't see why we should be limited to only two when more may be available. >> What if it helps to find some issue? >> Anyway, the test place windows on all screens, but checking only on two of them. > > I have updated the test to available screens (Though not able to test since I can extend to two screens now), I guess it should work, it's generic now. FYI, you can arrange up to 8 screens using Virtual Box(but I don't think it's necessary in this case) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277456027 From tr at openjdk.org Fri Jul 28 15:26:11 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 15:26:11 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v7] In-Reply-To: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: > "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). > CI testing shows green. > After the fix at 225% scaling: > ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14464/files - new: https://git.openjdk.org/jdk/pull/14464/files/65b27b92..97e5822a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=05-06 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14464/head:pull/14464 PR: https://git.openjdk.org/jdk/pull/14464 From aivanov at openjdk.org Fri Jul 28 15:40:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 15:40:56 GMT Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel [v7] In-Reply-To: References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com> Message-ID: <8NygNhBODhONgiQmGa8D42USK750P3vjfELM93p_rW8=.e7727698-b3dd-461e-97ca-cd20ab743cd6@github.com> On Fri, 28 Jul 2023 15:26:11 GMT, Tejesh R wrote: >> "size" label which is _RIGHT_ aligned is cut off on header cell. The issue is not only w.r.t to `JFileChooser` rather it is part of `JTable`. The root caused is found to be that in metal L&F the border insets is set to `(2,2,2,0)` meaning the right most inset value is 0. Hence when UIScaling increases the issue will be visible clearly. The fix addresses the issue by setting the right `inset` to 2 similar to other `inset` values. (Though the reason for setting it to 0 is unclear since it was initial load). >> CI testing shows green. >> After the fix at 225% scaling: >> ![image](https://github.com/openjdk/jdk/assets/94159358/f3e5a88a-1710-4ee0-84aa-338bc93010b2) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14464#pullrequestreview-1552383300 From azvegint at openjdk.org Fri Jul 28 16:06:01 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jul 2023 16:06:01 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v6] In-Reply-To: <002hY75seVjpqpOjCNeavMiSXH7HgLdjll8u_X-Kyz0=.dbad3731-0e83-4f96-be95-412e53ce52e4@github.com> References: <002hY75seVjpqpOjCNeavMiSXH7HgLdjll8u_X-Kyz0=.dbad3731-0e83-4f96-be95-412e53ce52e4@github.com> Message-ID: On Fri, 28 Jul 2023 15:23:24 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/java/awt/Multiscreen/MultiScreenCheckScreenIDTest.java line 111: > 109: } > 110: } > 111: windowList.add(window); This window will not be disposed in case if the exception is thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14825#discussion_r1277734451 From tr at openjdk.org Fri Jul 28 16:57:31 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 28 Jul 2023 16:57:31 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v7] In-Reply-To: References: Message-ID: > The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neithe r didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). > > The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14825/files - new: https://git.openjdk.org/jdk/pull/14825/files/c21052a0..ff5abac4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14825&range=05-06 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14825/head:pull/14825 PR: https://git.openjdk.org/jdk/pull/14825 From aivanov at openjdk.org Fri Jul 28 19:43:54 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 19:43:54 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() [v2] In-Reply-To: References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: On Wed, 26 Jul 2023 03:27:41 GMT, Prasanta Sadhukhan wrote: >> When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. >> Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself. >> Fix is made to treat setText as in edit mode and commit the changes made to it. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > setDocument and test fix I wonder what happens if `setText` is called with a value that cannot be interpreted by the current formatter and how it plays with different policies on focus lost as outlined in [the javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html). src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 746: > 744: //do nothing, we assume this will never happen. > 745: } > 746: } Since the same piece of code is needed in two different methods, it should be moved into a new helper method. It avoids duplication and therefore possible inconsistency because only one place is updated. test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 36: > 34: import java.awt.event.KeyEvent; > 35: import java.beans.PropertyChangeEvent; > 36: import java.beans.PropertyChangeListener; Could you sort the imports and remove the unused ones? test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 51: > 49: import java.text.SimpleDateFormat; > 50: > 51: public class JFormattedTextProblem { Should we use a more descriptive name for the test class? test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 101: > 99: > 100: DateFormat displayTime = DateFormat.getTimeInstance(DateFormat.MEDIUM); > 101: SimpleDateFormat editTime = new SimpleDateFormat("HH:mm"); These two variables are unused, should we remove them? ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14993#pullrequestreview-1552508827 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1277786500 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1278001641 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1278016892 PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1278000797 From aivanov at openjdk.org Fri Jul 28 19:49:50 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Jul 2023 19:49:50 GMT Subject: RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() [v2] In-Reply-To: References: <64MVbsD5Vhchb-v0-e-vg9VZ7MraOHAZHsh9Dw4h-KY=.5ef8e86e-1473-47c4-b7dd-8bcb74266406@github.com> Message-ID: On Wed, 26 Jul 2023 03:26:02 GMT, Prasanta Sadhukhan wrote: > > The bug report mentions using `setDocument()` to change the value of the formatted text field. Also, it's possible to call `getDocument().setText()`, which may still have the original bug. > > Fixed setDocument but I couldn't find Document.setText that can be called... Sorry about it, `Document` uses `insertString` method. Perhaps, we shouldn't care about it, if you modify the text using the `Document` interface directly, you could lose the invariants that `JFormattedTextField` provides. The [javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html) also mentions, that you should not install your own `DocumentFilter` and `NavigationFilter`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14993#issuecomment-1656235954 From abhiscxk at openjdk.org Mon Jul 31 03:26:50 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 31 Jul 2023 03:26:50 GMT Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox [v7] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 11:59:20 GMT, Abhishek Kumar wrote: >> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked. >> >> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. >> >> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list. >> >> CI link is posted in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Revert BasicComboBoxUI fix and update review comment @aivanov-jdk Updated the suggested changes. Do you have any other suggestions? @mrserb Checked with JAWS on windows and updated accordingly. Please have a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1657442360 PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1657443556 From aivanov at openjdk.org Mon Jul 31 05:02:00 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 05:02:00 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v9] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 04:58:33 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 45: > 43: */ > 44: > 45: public class TableHeaderBorderPositionTest { Suggestion: */ public class TableHeaderBorderPositionTest { test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 91: > 89: } finally { > 90: g2d.dispose(); > 91: } I wonder if it's possible to make the table paint its header into the same image, this would simplify the test. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 94: > 92: > 93: int verticalLineCol = (int)(table.getTableHeader(). > 94: getColumnModel().getColumn(0).getWidth() * SCALE) - 2; Is it reasonable to use the same formatting as in #14464, in `JTableHeaderLabelRightAlignTest.java`? test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 108: > 106: > 107: int maxVerticalLine = (int) Math.ceil( > 108: table.getRowCount() * table.getRowHeight() * SCALE); Suggestion: int maxVerticalLine = (int)Math.ceil( table.getRowCount() * table.getRowHeight() * SCALE); In all the other cases, you didn't add a space after the cast operator. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 112: > 110: for (int x = verticalLineCol; x < verticalLineCol + 3; x++) { > 111: if (expectedRGB != imgData.getRGB(x, y)) { > 112: saveImage(imgData,"FailureImageData.png"); Suggestion: saveImage(imgData, "FailureImageData.png"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1277704878 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1277707604 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1277710561 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1277706469 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1277652177 From tr at openjdk.org Mon Jul 31 05:02:02 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 31 Jul 2023 05:02:02 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v9] In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 15:36:27 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 91: > >> 89: } finally { >> 90: g2d.dispose(); >> 91: } > > I wonder if it's possible to make the table paint its header into the same image, this would simplify the test. I too had this thought initially, but wasn't comfortable in combining the images. Will try now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1278793552 From clanger at openjdk.org Mon Jul 31 07:24:45 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 31 Jul 2023 07:24:45 GMT Subject: RFR: JDK-8313252: Java_sun_awt_windows_ThemeReader_paintBackground release resources in early returns In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 07:52:14 GMT, Matthias Baesken wrote: > In file ThemeReader.cpp functionJava_sun_awt_windows_ThemeReader_paintBackground > we create DCs and release them at the end, but seems we miss it in early returns. > > While looking at the code, I noticed that CreateCompatibleDC can return NULL in case of error/failure, but we ignore this case; see > https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createcompatibledc . > Should we better handle it or is it not really occurring in practise ? Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15064#pullrequestreview-1554108843 From aivanov at openjdk.org Mon Jul 31 09:55:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 09:55:53 GMT Subject: RFR: 4893524: Swing drop targets should call close() on transferred readers and streams In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 07:15:56 GMT, Prasanta Sadhukhan wrote: > The issue here is a Reader(stream) is requested to handle a drop, via DataFlavor.getReaderForText(), and then the reader is completely read, but it isn't closed. It should be closed as soon as possible to release some native resources. > Fix is made to close the stream after it is being used Shall we also update the copyright year in `BasicTextUI`? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 2613: > 2611: > 2612: handleReaderImport(r, c, useRead); > 2613: r.close(); Should we use try-with-resources for Reader? This will ensure the stream is closed even if `handleReaderImport` throws an exception. ------------- PR Review: https://git.openjdk.org/jdk/pull/15033#pullrequestreview-1554394185 PR Review Comment: https://git.openjdk.org/jdk/pull/15033#discussion_r1279064741 From aivanov at openjdk.org Mon Jul 31 10:21:07 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 10:21:07 GMT Subject: RFR: 8313348: Fix typo in JFormattedTextField: 'it self' Message-ID: A trivial change: ?it self? ? ?itself?. In addition to it, I added a comma after ?Similarly? where it starts a sentence. ------------- Commit messages: - 8313348: Fix typo in JFormattedTextField: 'it self' Changes: https://git.openjdk.org/jdk/pull/15087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313348 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15087/head:pull/15087 PR: https://git.openjdk.org/jdk/pull/15087 From aivanov at openjdk.org Mon Jul 31 10:34:13 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 10:34:13 GMT Subject: RFR: 8313403: Remove unused 'mask' field from JFormattedTextField Message-ID: <4fl_xrqZnBAxg014rvHQuI_7K-YP2QouKSzr76fcOX4=.2823965d-9be5-4b9d-ab02-038658b3469c@github.com> The private field `mask` is never used in `JFormattedTextField`. I couldn't find any usages of the field, including JNI. Therefore, it is safe to remove. ------------- Commit messages: - 8313403: Remove unused 'mask' field from JFormattedTextField Changes: https://git.openjdk.org/jdk/pull/15088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313403 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15088/head:pull/15088 PR: https://git.openjdk.org/jdk/pull/15088 From mbaesken at openjdk.org Mon Jul 31 15:00:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 31 Jul 2023 15:00:59 GMT Subject: Integrated: JDK-8313252: Java_sun_awt_windows_ThemeReader_paintBackground release resources in early returns In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 07:52:14 GMT, Matthias Baesken wrote: > In file ThemeReader.cpp functionJava_sun_awt_windows_ThemeReader_paintBackground > we create DCs and release them at the end, but seems we miss it in early returns. > > While looking at the code, I noticed that CreateCompatibleDC can return NULL in case of error/failure, but we ignore this case; see > https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createcompatibledc . > Should we better handle it or is it not really occurring in practise ? This pull request has now been integrated. Changeset: 3671d83c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/3671d83c87302ead09d4ebce9cb85bdd803a0c20 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8313252: Java_sun_awt_windows_ThemeReader_paintBackground release resources in early returns Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jdk/pull/15064 From philip.race at oracle.com Mon Jul 31 15:50:45 2023 From: philip.race at oracle.com (Philip Race) Date: Mon, 31 Jul 2023 08:50:45 -0700 Subject: IMPORTANT REMINDER: 2 Reviews (ie approvals) are required for most client-libs changes In-Reply-To: References: Message-ID: <90fde90a-63e5-81f4-e82c-71a50e099dbf@oracle.com> Regarding : https://git.openjdk.org/jdk/pull/15064 please note the policy we have and have had for as long as OpenJDK has been around. And in this case there isn't even a client reviewer which makes two problems ! -phil. On 7/13/23 8:27 AM, Philip Race wrote: > Please see "Code Reviews" on the Group page > https://openjdk.org/groups/client-libs/ where it says > > The Java Client Library Group has always standardized on two approvals > - where at least one must have the Reviewer role. > Historically this was addressed entirely by social conventions but > today the tooling plays a role - and the JDK project is set up to mark > a PR as ready for integration after a single approval by a person with > the Reviewer role - which is not consistent with the Client Libraries > policy. > The tooling cannot automatically enforce this on a per-module basis > and it is not reasonable to expect others to add "/reviewers 2" to > every PR. > The fixer therefore needs to understand the policies and wait for a > second approval. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > As an example of a PR about which there was zero urgency and should > have had a 2nd approval see > > https://github.com/openjdk/jdk/pull/14795 > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tr at openjdk.org Mon Jul 31 16:31:21 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 31 Jul 2023 16:31:21 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v10] In-Reply-To: References: Message-ID: > The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. > CI testing shows green. > > ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14766/files - new: https://git.openjdk.org/jdk/pull/14766/files/c11e059a..0fa44f08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14766&range=08-09 Stats: 51 lines in 1 file changed: 6 ins; 31 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/14766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14766/head:pull/14766 PR: https://git.openjdk.org/jdk/pull/14766 From tr at openjdk.org Mon Jul 31 16:32:46 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 31 Jul 2023 16:32:46 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v9] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 04:58:43 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 91: >> >>> 89: } finally { >>> 90: g2d.dispose(); >>> 91: } >> >> I wonder if it's possible to make the table paint its header into the same image, this would simplify the test. > > I too had this thought initially, but wasn't comfortable in combining the images. Will try now. I have updated the test with single buffered image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279580765 From dnguyen at openjdk.org Mon Jul 31 16:41:47 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 31 Jul 2023 16:41:47 GMT Subject: RFR: 8280482: Window transparency bug on Linux [v7] In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 16:57:31 GMT, Tejesh R wrote: >> The bug mentions about transparency issue on Linux which actually got resolved with [JDK-8006421](https://bugs.openjdk.org/browse/JDK-8006421) fix. Now there is another problem related to the bug, which is screen selection going wrong during checking for new screen when the test is run. The problem is that (As seen in the pictures attached in bug) the transparency is lost for windows which are in screen 0 (default screen) too, which is not supposed to happen where windows on screen 1 should have lost there transparency. The main reason being the call to `toGlobal()` when window bounds are passed to `checkIfOnNewScreen` method. I didn't get the actual reason for `toGlobal` being used here (actually not required to check monitor number), but it actually doubled the X position of the window [here]( https://github.com/openjdk/jdk/blob/4b1403d06b99b91ddd89ad6e54669b0595f1f8e5/src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java#L776). Removing `toGlobal` solve the issue and neith er didn't cause any regression (existing test + the reason `toGlobal()` was added [JDK-8143295](https://bugs.openjdk.org/browse/JDK-8143295)). >> >> The automated test fails if GC is changed for windows within screen 0 (default screen). CI testing is green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix LGTM after the changes on my VM ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/14825#pullrequestreview-1555319975 From honkar at openjdk.org Mon Jul 31 18:54:52 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 31 Jul 2023 18:54:52 GMT Subject: RFR: 8313348: Fix typo in JFormattedTextField: 'it self' In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 10:14:45 GMT, Alexey Ivanov wrote: > A trivial change: ?it self? ? ?itself?. > > In addition to it, I added a comma after ?Similarly? where it starts a sentence. Marked as reviewed by honkar (Committer). @aivanov-jdk LGTM and since the Javadocs changes are trivial, I believe it doesn't require a CSR ? ------------- PR Review: https://git.openjdk.org/jdk/pull/15087#pullrequestreview-1555544738 PR Comment: https://git.openjdk.org/jdk/pull/15087#issuecomment-1658956522 From aivanov at openjdk.org Mon Jul 31 19:15:51 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 19:15:51 GMT Subject: RFR: 8313348: Fix typo in JFormattedTextField: 'it self' In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 18:48:02 GMT, Harshitha Onkar wrote: > LGTM and since the Javadocs changes are trivial, I believe it doesn't require a CSR ? @honkar-jdk No, it doesn't require a CSR because it doesn't change the meaning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15087#issuecomment-1658985916 From aivanov at openjdk.org Mon Jul 31 20:43:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 20:43:58 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v10] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 16:31:21 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 68: > 66: > 67: BufferedImage bufferedImage = new BufferedImage(WIDTH, HEIGHT, > 68: BufferedImage.TYPE_INT_RGB); Hm, you have to create the image large enough to contain the table after scaling it by `SCALE`, so you still need `w` and `h` or you could inline `WIDTH * SCALE` and `HEIGHT * SCALE` correspondingly. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 76: > 74: g2d.translate(0, header.getHeight()); > 75: table.paint(g2d); > 76: } finally { Awesome! I didn't think about it. If it works, it makes verification easier. When you read the code, you clearly see the borders of the header and grid align. I expected the table would paint both its header and its contents, but it may require validation which can't happen until the table is added to a heavyweight container such as a frame. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 83: > 81: .getColumnModel() > 82: .getColumn(0) > 83: .getWidth() * SCALE) - 2; Suggestion: int verticalLineCol = (int)(table.getTableHeader() .getColumnModel() .getColumn(0) .getWidth() * SCALE) - 2; If you add a space after the cast operator, add it everywhere; if you don't, add it nowhere. I could've given you a suggestion based on my formatting, and I have the space after the cast operator because Java Coding Style recommends adding it. Yet there's no consensus about it in client-libs. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 85: > 83: .getWidth() * SCALE) - 2; > 84: int expectedRGB = bufferedImage.getRGB(verticalLineCol, 0); > 85: int maxHeight = (int)(((double)table.getTableHeader().getHeight() * SCALE ) Suggestion: int maxHeight = (int)(((double)table.getTableHeader().getHeight() * SCALE) ------------- PR Review: https://git.openjdk.org/jdk/pull/14766#pullrequestreview-1555731207 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279855301 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279853146 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279858473 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279850115 From aivanov at openjdk.org Mon Jul 31 20:43:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 20:43:59 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v9] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 04:58:33 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 127: > 125: e.printStackTrace(); > 126: } > 127: } In fact, it looks better with `saveImage` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279849664 From aivanov at openjdk.org Mon Jul 31 21:13:00 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 31 Jul 2023 21:13:00 GMT Subject: RFR: 8311031: JTable header border vertical lines are not aligned with data grid lines [v10] In-Reply-To: References: Message-ID: <6lGmsyusT2v4Q1gJj7d1X0cH3R8GLZIXhIv-eHdpFDw=.90ae0f8c-ed8e-4200-9574-bf913cf206cd@github.com> On Mon, 31 Jul 2023 16:31:21 GMT, Tejesh R wrote: >> The header border uses `g.drawLine` whereas the JTable data grid lines uses `SwingUtilities2.drawVLine` and `SwingUtilities2.drawHLine` to draw horizontal and vertical lines. The SwingUtilities2 uses `Graphics.fillRect` which contributes to the difference between the position of these two lines which happens/visible at higher ui scaling (difference in alignment between vertical lines of these two). The fix propose to use the same methods for metal L&F of JTable header border paint. >> CI testing shows green. >> >> ![image](https://github.com/openjdk/jdk/assets/94159358/f6d1d822-55ba-4ad3-9914-d3f68b67a6c5) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 60: > 58: > 59: String[] columnNames = {"Size", "Size"}; > 60: JTable table = new JTable(data, columnNames); Suggestion: String[][] data = { {"1", "1"} }; String[] columnNames = {"Size", "Size"}; JTable table = new JTable(data, columnNames); Let's separate the data ? `data` and `columnNames` from the table. test/jdk/javax/swing/JTableHeader/TableHeaderBorderPositionTest.java line 68: > 66: > 67: BufferedImage bufferedImage = new BufferedImage(WIDTH, HEIGHT, > 68: BufferedImage.TYPE_INT_RGB); Suggestion: JTable table = new JTable(data, columnNames); Dimension tableSize = table.getPreferredSize(); table.setSize(tableSize); final JTableHeader header = table.getTableHeader(); Dimension headerSize = header.getPreferredSize(); header.setSize(headerSize); Dimension size = new Dimension(Math.max(headerSize.width, tableSize.width), headerSize.height + tableSize.height); BufferedImage bufferedImage = new BufferedImage((int)Math.ceil(size.width * SCALE), (int)Math.ceil(size.height * SCALE), BufferedImage.TYPE_INT_RGB); This takes into account both the header size and table size and sets the size of the image appropriately. The constants `WIDTH` and `HEIGHT` have become redundant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279879383 PR Review Comment: https://git.openjdk.org/jdk/pull/14766#discussion_r1279880928