From psadhukhan at openjdk.org  Thu Jun  1 03:00:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2023 03:00:59 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v13]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <QecMeQIHl8HuGWzvymkfM74dUzQQvr0LsyuCups8iYY=.c85a22d7-d1e5-40f0-b508-81bab70dea2f@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Fix optimization w.r.t null check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/a7214bac..4a3a8978

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=11-12

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

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


From psadhukhan at openjdk.org  Thu Jun  1 03:03:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2023 03:03:18 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v12]
In-Reply-To: <Y-512D4vWT9iDGsEkGqIxJrpN_9Wdn7RpJbTf0tJsgU=.98f7d857-48a7-4a67-a70f-9b847bf449b1@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <Y-512D4vWT9iDGsEkGqIxJrpN_9Wdn7RpJbTf0tJsgU=.98f7d857-48a7-4a67-a70f-9b847bf449b1@github.com>
Message-ID: <en4qNHDaewtfd6BREQH8zVnLPLxo9r2nBTz2uhrd0tM=.19a62dd6-781d-42b0-84dc-f8ca6a2182fb@github.com>

On Wed, 31 May 2023 12:55:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use local objects for FontSize as per review comment

@prrace @aivanov-jdk Any further comments on this PR? I would like to get it in by RDP1 if it is possible and I guess contentious issues are sorted

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

PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1571254937


From tr at openjdk.org  Thu Jun  1 04:23:33 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 1 Jun 2023 04:23:33 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
Message-ID: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>

When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
The fix is verified in CI for regression check, which is Green.

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

Commit messages:
 - Removed white-spaces
 - Fix + Manual Test

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

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


From jwaters at openjdk.org  Thu Jun  1 07:12:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 07:12:39 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v2]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <KZNH7W5dZuLWeURNi4omOTtCebAICagc05O3rcAf28s=.2d554cd1-914b-4963-aaa6-107614c155db@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Revert changes to jaccesswalker and add proper cast to offending callsite

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/b925f5ee..628be6b2

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

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

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


From jwaters at openjdk.org  Thu Jun  1 07:14:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 07:14:55 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v3]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <EyfFFtrGk1Z4sJ2tcWSrDTTCiF7GN4s-4pmFnCVEwuc=.2659172b-f087-43a0-9ed3-799a2c5da2e8@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Nevermind

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/628be6b2..29b93688

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

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

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


From aturbanov at openjdk.org  Thu Jun  1 07:29:11 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Jun 2023 07:29:11 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v9]
In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com>
Message-ID: <RbYbuIJDe6YQfBGmFuCxNYkWcBlqL_X8kuNb3cG4Ug0=.e6d75638-0675-44e8-a565-34e8a02f3424@github.com>

On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - improve retVal processing
>  - address token storage comments
>  - removing non-ascii
>  - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 56:

> 54: import static sun.awt.screencast.ScreencastHelper.SCREENCAST_DEBUG;
> 55: 
> 56: final class TokenStorage {

Would be nice to have a few words about purpose of this class in the javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212708124


From psadhukhan at openjdk.org  Thu Jun  1 08:26:45 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2023 08:26:45 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v14]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <e6WzkAOeXkJUPcJB6VFsfz-r9Pbo2S4uLpqZM55qm00=.5c63c114-6b0d-4ac6-90b8-04a3d756e4f9@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Use relative variable in equals/hashcode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/4a3a8978..833ff8fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=12-13

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

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


From psadhukhan at openjdk.org  Thu Jun  1 08:26:45 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2023 08:26:45 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v10]
In-Reply-To: <QnSGExLpuvq1lzlpMeJRF-LoYOxgNqud108UsLEL3qE=.e5fb5449-1dbf-4d97-9a1d-eeb37f226b98@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <VGa7JZk4SazDGrTk_UX_0KuGr0Xawb47ypb6zWxm3GY=.5f490cfb-6757-4eb3-abf8-793025df1542@github.com>
 <lVfXdFN0exuIyuIW3HmISuwFeKJXor5hCh7xJtahdTA=.e0fabe25-f34a-4c00-a4d2-7fbf737746b5@github.com>
 <QnSGExLpuvq1lzlpMeJRF-LoYOxgNqud108UsLEL3qE=.e5fb5449-1dbf-4d97-9a1d-eeb37f226b98@github.com>
Message-ID: <SKF-KNHmBH6cAdxcY0G8Rr3USraaPZJWVoocGW9CKSA=.737eb921-a102-46dd-9e6d-b46c9e319464@github.com>

On Tue, 30 May 2023 17:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2920:
>> 
>>> 2918:         @Override
>>> 2919:         public boolean equals(Object val) {
>>> 2920:             return val instanceof CSS.BackgroundPosition bp
>> 
>> why isn't "relative" part of equals and hashCode()?
>
> it is said "relative" is 
> 
> bit 0, horizontal relative, bit 1 horizontal relative to
>         // font size, 2 vertical relative to size, 3 vertical relative to
>         // font size
> 
> I was not sure if it is need to be considered in the equals/hashcode contract..

I have added "relative" to equals/hashCode

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1212778703


From aturbanov at openjdk.org  Thu Jun  1 08:51:17 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Jun 2023 08:51:17 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v9]
In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com>
Message-ID: <5xeJM2zg1qgr7LrpzniPxwhdqCSTRiKuYtkxWHohaj0=.ebddbb3c-96f8-4896-85c7-4d7d4b2cb540@github.com>

On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - improve retVal processing
>  - address token storage comments
>  - removing non-ascii
>  - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE

src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 38:

> 36: import static sun.awt.screencast.ScreencastHelper.SCREENCAST_DEBUG;
> 37: 
> 38: final class TokenItem {

add couple of words to the javadoc

src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 40:

> 38: final class TokenItem {
> 39:     String token;
> 40:     List<Rectangle> allowedScreensBounds;

make fields final
Suggestion:

    final String token;
    final List<Rectangle> allowedScreensBounds;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212812286
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212813586


From jwaters at openjdk.org  Thu Jun  1 11:49:24 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 11:49:24 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Fix the code that is actually warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/29b93688..5fa2d3eb

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

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

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


From jwaters at openjdk.org  Thu Jun  1 11:59:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 11:59:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <lmRgb7YaWTkPFfePutzoq4R07kB7DYa7MC--MFfdU5w=.311b471a-bd8f-48c3-8792-beba087c2cc2@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

While looking through the code for this I've come to realize that a staggering amount of code in the accessibility binaries specify longs where unsigned longs would be much more appropriate (see the one example in this PR for instance), wonder if this should also be fixed in the long term too

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1571912910


From azvegint at openjdk.org  Thu Jun  1 12:40:55 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 12:40:55 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v10]
In-Reply-To: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
Message-ID: <2S3ejSIrUrE8kGjOXkCrT6LuUBcT8kXMtLYenGJJphE=.4bf31044-5c2a-4e1b-bbc8-89302521712f@github.com>

> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
> 
> But this functionality is a very important part of automated testing.
> 
> 
> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
> 
> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
> It has several drawbacks though:
> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
> + There is no way to disable the visual "screen flash" after screenshot
> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
> But we still can consider this option as a fallback.
> 
> 
> 
> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
> 
> + implementation is more complicated comparing to Screenshot API
> + no intermediate file, screenshot data can be obtained from memory
> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
> 
> 
> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
> 
> This change also introduces some new behavior for the robot:
> A system window now appears asking for confirmation from the user to capture the screen.
> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
> + The user can allow a screen capture for all screens o...

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

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13803/files
  - new: https://git.openjdk.org/jdk/pull/13803/files/389cfd73..63b34b9d

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

  Stats: 64 lines in 4 files changed: 39 ins; 19 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803

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


From azvegint at openjdk.org  Thu Jun  1 12:41:05 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 12:41:05 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v9]
In-Reply-To: <qiImZsFXNtST6BpoQfyuEhQskV5iIV99AwskR5dG6Fs=.31981e03-f68b-428e-9191-b4a66ab3be99@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com>
 <qiImZsFXNtST6BpoQfyuEhQskV5iIV99AwskR5dG6Fs=.31981e03-f68b-428e-9191-b4a66ab3be99@github.com>
Message-ID: <SFwFJrofDGZMHdzEvwRvqfErOE3-CXIZ7VK0cpoTPec=.37630a16-4a0b-47cf-9412-768b6891c5d2@github.com>

On Wed, 31 May 2023 20:53:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - improve retVal processing
>>  - address token storage comments
>>  - removing non-ascii
>>  - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 195:
> 
>> 193: 
>> 194:     LIBPIPEWIRE_HEADER_DIRS := \
>> 195:     	$(TOPDIR)/src/$(MODULE)/unix/native/libpipewire/include
> 
> Are you sure Tab should be used here?
> in all other places of this file spaces are used for indentation.

Fixed

> src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 38:
> 
>> 36: import static sun.awt.screencast.ScreencastHelper.SCREENCAST_DEBUG;
>> 37: 
>> 38: final class TokenItem {
> 
> add couple of words to the javadoc

Sure, updated

> src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 111:
> 
>> 109: 
>> 110:     public static TokenItem parse(String token, Object input) {
>> 111:         if (token == null || input == null) return null;
> 
> Do we need this `null` checks?
> Currently only non-null values are passed to this method

It won't hurt.

> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 303:
> 
>> 301: 
>> 302:         Set<Map.Entry<Object, Object>> entries;
>> 303:         synchronized (PROPS) {
> 
> I'm not sure I understand purpose of this `synchronized` block.
> `entrySet()` returns _view_ of Properties entries, not a copy. It means concurrent thread could modify content of `PROPS` when we do `stream()` below.
> 
> From my opinion either we need to perform all work inside `synchronized` to be sure that no concurrent modification are possible. Or just remove `synchronized` (`Properties` is a thread safe class) and _be ready_ of possible concurrent updates

Thanks for catching this, updated.

> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 307:
> 
>> 305:         }
>> 306: 
>> 307:         Set<String> malformed = new LinkedHashSet<>();
> 
> Can we use plain HashSet here? Seems there is not much reason to save original order of tokens.

Updated.

> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 320:
> 
>> 318:                     return tokenItem;
>> 319:                 })
>> 320:                 .filter(obj -> !Objects.isNull(obj))
> 
> `Objects.isNull` wasn't supposed to be used like this. Let's either inline it and use `!= null` or use method reference `.filter(Objects::nonNull)`

Updated.

> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 346:
> 
>> 344:                         rectangle.height
>> 345:                 ))
>> 346:                 .collect(Collectors.toCollection(ArrayList::new));
> 
> why not plain toList() collector?

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213080352
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213081541
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213082454
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213082814
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213083695
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213083915
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1213084108


From duke at openjdk.org  Thu Jun  1 13:11:24 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:24 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <tp1fasJhXNuAzfgL4wGOA33z2aejI2mT1hGsOASoDKQ=.37145f46-e3d2-48b7-b6c3-3a673f81c34a@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues  into extra JBS issues. 
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@mbaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc 
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.  

Thanks for your help so far!

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues into extra JBS issues.
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@MBaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.

Thanks for your help so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572023812
PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572024628


From duke at openjdk.org  Thu Jun  1 13:11:26 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:26 GMT
Subject: Withdrawn: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <kc61yDMer50HrFEk55-xDCN85ZeKj3D0p4IeXJk89cM=.9d90fcb8-28a8-42b2-8078-f84cfc94d14a@github.com>

On Thu, 25 May 2023 09:14:14 GMT, JoKern65 <duke at openjdk.org> wrote:

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

This pull request has been closed without being integrated.

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

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


From asemenov at openjdk.org  Thu Jun  1 15:01:37 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:01:37 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

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

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/d5b70cb2..b423bd4c

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

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

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


From asemenov at openjdk.org  Thu Jun  1 15:07:11 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:07:11 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
Message-ID: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>

On Wed, 31 May 2023 13:52:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
> 
>> 45: 
>> 46: // Condition was copied from
>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 
> In the current version of the file above, it's written as
> 
> #if defined(__APPLE__) && (defined(__ppc__) ||...
> 
> Is it better?

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213297788


From weijun at openjdk.org  Thu Jun  1 15:07:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Jun 2023 15:07:12 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
Message-ID: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>

On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
>> 
>>> 45: 
>>> 46: // Condition was copied from
>>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 
>> In the current version of the file above, it's written as
>> 
>> #if defined(__APPLE__) && (defined(__ppc__) ||...
>> 
>> Is it better?
>
> done

I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213300305


From azvegint at openjdk.org  Thu Jun  1 15:26:39 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 15:26:39 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction
Message-ID: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>

This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.

Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
So now we make an exclusion for this case.

After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
Other tests are also passed.

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

Commit messages:
 - typo
 - initial

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

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


From avu at openjdk.org  Thu Jun  1 16:07:05 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 1 Jun 2023 16:07:05 GMT
Subject: RFR: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
Message-ID: <ZdUy4OcHXUfr-dlTEzC77oHqH2HBwARm7u5FdTPcrPc=.18a0f692-57a8-4205-867e-e7047fd885fb@github.com>

On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573).
> 
> This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file.

Looks good for me

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14170#pullrequestreview-1455831815


From serb at openjdk.org  Thu Jun  1 16:11:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jun 2023 16:11:04 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <wKHBYi03rVebvf3XQgPLedbnG9R0SsQdmjgkg-L2kvk=.4a036a77-e334-4388-a34f-4bfe6bd57457@github.com>

On Wed, 31 May 2023 11:34:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

Isn't the patch for JDK-6804747 tried to solve the same bug, especially this code:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java#L56 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1572338418


From azvegint at openjdk.org  Thu Jun  1 16:20:05 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 16:20:05 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <_WDWpM6O5sVouG4giMpKF4h-a2PdooMEeGsqsQlBq34=.bd663d3a-7820-4159-9d7b-aba1b071f865@github.com>

On Wed, 31 May 2023 11:34:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 698:

> 696:                         newGC = gds[i].getDefaultConfiguration();
> 697:                         if (target != null
> 698:                                 && target.getBackground() != SystemColor.window

This doesn't seem right, it'll change to a translucent gc even for opaque windows that has some non standard color as a background.

Probably it is better to check if previous gc was translucent capable 
`&& target.getGraphicsConfiguration().isTranslucencyCapable()`

src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 707:

> 705:                                 }
> 706:                             }
> 707:                         }

Looks like this code is also repeated on lines 714-724 and can be extracted to a function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1213392322
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1213394373


From erikj at openjdk.org  Thu Jun  1 16:21:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Jun 2023 16:21:06 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
Message-ID: <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>

On Fri, 26 May 2023 20:26:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.
> 
> I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17).
> 
> @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light.
> 

There are no extra options. I suspect it's an issue with the older GCC version. Here is one failing command line:


$ ( cd /home/erik/git/jdk/build/linux-arm32 ; /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -r --sysroot=/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/arm-linux-gnueabihf/sysroot -o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/GC.o )
/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libgcc_s.so.1


> The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.

This seems to be Clang specific, so maybe only apply this to Clang and not GCC? Have you measured the difference in link time and concluded that this workaround is needed? If so, how big were the differences? Given that it prints a lot of warnings on mac, I would suggest leaving the partial linking out of this patch to get something in that is actually working. It was included in this patch because of the side effect it had with handling long path names. However, since looking closer at that issue, we were using a different workaround for Clang already and that same workaround should work fine for AR on mac as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1572352386


From tr at openjdk.org  Thu Jun  1 16:46:05 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 1 Jun 2023 16:46:05 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <wKHBYi03rVebvf3XQgPLedbnG9R0SsQdmjgkg-L2kvk=.4a036a77-e334-4388-a34f-4bfe6bd57457@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <wKHBYi03rVebvf3XQgPLedbnG9R0SsQdmjgkg-L2kvk=.4a036a77-e334-4388-a34f-4bfe6bd57457@github.com>
Message-ID: <79AhY638-ag2Bh0rl8DYnapHO1f64S6liWsWrcbqFAY=.06c62db8-a433-48fa-a9ef-3afb1187fa84@github.com>

On Thu, 1 Jun 2023 16:08:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 



> Isn't the patch for JDK-6804747 tried to solve the same bug, especially this code: https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java#L56 ?

More or less, yet the transparency issue exist and that is what this fix tries to resolve (which is been discussed in the JBS). Then should the bug be closed as duplicate and a new JBS should be file for transparency issue alone? Or Should the fix be for this one - [JDK-8280482](https://bugs.openjdk.org/browse/JDK-8280482)

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1572394884


From prr at openjdk.org  Thu Jun  1 16:50:16 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 16:50:16 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v10]
In-Reply-To: <2S3ejSIrUrE8kGjOXkCrT6LuUBcT8kXMtLYenGJJphE=.4bf31044-5c2a-4e1b-bbc8-89302521712f@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <2S3ejSIrUrE8kGjOXkCrT6LuUBcT8kXMtLYenGJJphE=.4bf31044-5c2a-4e1b-bbc8-89302521712f@github.com>
Message-ID: <aFgBKpoD6KGg2BwCbuH-t0O87xGvcXA1IO3eS2eSDzY=.67bcebf0-8b64-46da-99b9-da93dcc501f1@github.com>

On Thu, 1 Jun 2023 12:40:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Regarding the failed capture
> cropTo:163 Unexpected stride / 4: 0 srcW: 1920

I've confirmed that on my system we DO enter FSEM using Xrandr
If I just comment out the call to XSendEvent(..) in X11GD_SetFullscreenMode(..)
then the capture works fine.

So something about this code, or pipewire or XWayland isn't handling this properly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1572403630


From duke at openjdk.org  Thu Jun  1 17:09:33 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 17:09:33 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop
Message-ID: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>

This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
It handles the part in java.desktop.
prrace had already reviewed this part in the original pr.

Here are the handled errors for which we use the same warning disabling as gcc.

src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
extern int XShmQueryExtension();
^
/usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
Bool XShmQueryExtension(
^
solved by adding line (generic, because several source files are involved)
DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \

src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \

src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
^~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \

src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
^~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
~~~~~~~~~~~~^
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:903:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (init_result = (NULL == gtk3_widgets[_GTK_BUTTON_TYPE]))
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk3_interface.c := parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c:87:26: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (pendingException = (*env)->ExceptionOccurred(env)) {
~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \

src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c:1969:32: error: comparison of integers of different signs: 'Window' (aka 'unsigned long') and 'jlong' (aka 'long') [-Werror,-Wsign-compare]
if (currentFocusWindow != w) {
~~~~~~~~~~~~~~~~~~ ^ ~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \

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

Commit messages:
 - JDK-8309224

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

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


From prr at openjdk.org  Thu Jun  1 17:17:08 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 17:17:08 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop
In-Reply-To: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
Message-ID: <TmiGWYyo27UPgXSh-tD312B4wYSa9YtsoD47XYM8KIM=.10961445-00ee-40b8-8c5b-2231da9ba06a@github.com>

On Thu, 1 Jun 2023 13:16:49 GMT, JoKern65 <duke at openjdk.org> wrote:

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.desktop.
> prrace had already reviewed this part in the original pr.
> 
> Here are the handled errors for which we use the same warning disabling as gcc.
> 
> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
> extern int XShmQueryExtension();
> ^
> /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
> Bool XShmQueryExtension(
> ^
> solved by adding line (generic, because several source files are involved)
> DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \
> 
> src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
> ^~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
> ^~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
> ~~~~~~~~~~~~^
> solved by adding line
> DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \
> 
> src/java.desktop/unix/native/libawt_xawt/a...

Marked as reviewed by prr (Reviewer).

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 708:

> 706:   # The external libpng submitted in the jdk is an old version
> 707:   # which does not contain .png_init_filter_functions_vsx.
> 708:   # Therefore we need to disable PNG_POWERPC_VSX_OPT explicitely by setting

explicitely -> explicitly

And it isn't an old version. It is very current.
I think we just chose not to import functionality we weren't using.

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

PR Review: https://git.openjdk.org/jdk/pull/14263#pullrequestreview-1455951072
PR Review Comment: https://git.openjdk.org/jdk/pull/14263#discussion_r1213453608


From serb at openjdk.org  Thu Jun  1 17:25:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jun 2023 17:25:07 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>

On Wed, 31 May 2023 11:34:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

We should check why that code does not work, note the code in that patch also support both Window and Canvas.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1572483459


From prr at openjdk.org  Thu Jun  1 17:27:12 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 17:27:12 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction
In-Reply-To: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
Message-ID: <V1QK3FxD6znqCoTJgTTxfvMA_-b9W46MArgZ_sQeVVg=.e72959f4-c6da-4d2a-821d-baf6b9cfa7c2@github.com>

On Thu, 1 Jun 2023 15:18:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
> 
> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
> So now we make an exclusion for this case.
> 
> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
> Other tests are also passed.

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 408:

> 406:      */
> 407:     private static boolean isXWaylandDndAwareWindow(long window) {
> 408:         if (Toolkit.getDefaultToolkit() instanceof SunToolkit sunToolkit

So if it is NOT an instance of sunToolkit .. then you carry on to the code that gets the property.
Is that what you meant to happen ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1213464984


From duke at openjdk.org  Thu Jun  1 17:31:28 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 17:31:28 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop [v2]
In-Reply-To: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
Message-ID: <TJ4ZuiUOzNgmeTalNRta01Lq-7xWVdR5QFU39Dl9lGs=.a7b5e0f1-c78e-4616-a820-88bb9d886811@github.com>

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.desktop.
> prrace had already reviewed this part in the original pr.
> 
> Here are the handled errors for which we use the same warning disabling as gcc.
> 
> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
> extern int XShmQueryExtension();
> ^
> /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
> Bool XShmQueryExtension(
> ^
> solved by adding line (generic, because several source files are involved)
> DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \
> 
> src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
> ^~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
> ^~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
> ~~~~~~~~~~~~^
> solved by adding line
> DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \
> 
> src/java.desktop/unix/native/libawt_xawt/a...

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

  Update Awt2dLibraries.gmk
  
  followed prrace annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14263/files
  - new: https://git.openjdk.org/jdk/pull/14263/files/1403e242..f9d99dc7

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

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

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


From prr at openjdk.org  Thu Jun  1 17:46:06 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 17:46:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

I'm not sure I understand the logic here.
I would not want to move to using Java typedefs in places where the windows APIs specify the types they are expecting.
If something comes in from a JNI down-call we should convert it to the type expected by Windows using the name expected by Windows.

Also "compilation" isn't nearly good enough. How is this being tested ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1572518377


From prr at openjdk.org  Thu Jun  1 18:36:14 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 18:36:14 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v14]
In-Reply-To: <e6WzkAOeXkJUPcJB6VFsfz-r9Pbo2S4uLpqZM55qm00=.5c63c114-6b0d-4ac6-90b8-04a3d756e4f9@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <e6WzkAOeXkJUPcJB6VFsfz-r9Pbo2S4uLpqZM55qm00=.5c63c114-6b0d-4ac6-90b8-04a3d756e4f9@github.com>
Message-ID: <-OV3Vd-01D7mIQaBE94Um1XHcKnEbtNLrYXLpEJ5EPw=.f8fc5ca5-d2bf-49c6-bdb8-faa209028f78@github.com>

On Thu, 1 Jun 2023 08:26:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use relative variable in equals/hashcode

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:

> 2682:             return val instanceof CSS.LengthValue lu
> 2683:                    && Objects.equals(svalue, lu.svalue);
> 2684:         }

Why is this case still using the string and not 'span' ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1213533619


From azvegint at openjdk.org  Thu Jun  1 18:38:29 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 18:38:29 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
Message-ID: <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>

> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
> 
> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
> So now we make an exclusion for this case.
> 
> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
> Other tests are also passed.

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

  fix toolkit if condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14266/files
  - new: https://git.openjdk.org/jdk/pull/14266/files/b9079d41..ec4493f5

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

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

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


From azvegint at openjdk.org  Thu Jun  1 18:38:29 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Jun 2023 18:38:29 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <V1QK3FxD6znqCoTJgTTxfvMA_-b9W46MArgZ_sQeVVg=.e72959f4-c6da-4d2a-821d-baf6b9cfa7c2@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <V1QK3FxD6znqCoTJgTTxfvMA_-b9W46MArgZ_sQeVVg=.e72959f4-c6da-4d2a-821d-baf6b9cfa7c2@github.com>
Message-ID: <VfSn_v3ftr3lc-rihDuYuc5Dmllvxvb-fE0unj5emZM=.24fd7d6b-d656-4448-8347-0afb2a90c858@github.com>

On Thu, 1 Jun 2023 17:24:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix toolkit if condition
>
> src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 408:
> 
>> 406:      */
>> 407:     private static boolean isXWaylandDndAwareWindow(long window) {
>> 408:         if (Toolkit.getDefaultToolkit() instanceof SunToolkit sunToolkit
> 
> So if it is NOT an instance of sunToolkit .. then you carry on to the code that gets the property.
> Is that what you meant to happen ?

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1213533156


From prr at openjdk.org  Thu Jun  1 18:44:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 18:44:04 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
Message-ID: <GH8YRe6Vg7mGMNTZp8qB2HLQ9C72zRKkRZ6LEkleSWU=.c94103ea-0868-44a4-abbe-9bdadeed64b3@github.com>

On Thu, 1 Jun 2023 18:38:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
>> 
>> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
>> So now we make an exclusion for this case.
>> 
>> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
>> Other tests are also passed.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix toolkit if condition

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14266#pullrequestreview-1456088580


From rmahajan at openjdk.org  Thu Jun  1 19:56:28 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 1 Jun 2023 19:56:28 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v9]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  code changes as per code review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/67db341d..7a2a2a40

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

  Stats: 55 lines in 1 file changed: 19 ins; 28 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

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


From achung at openjdk.org  Thu Jun  1 20:27:13 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 1 Jun 2023 20:27:13 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <YNzhYANzlLfIXNx6d2h5m6cq5N_urtxnua8aJP6LoRk=.ad89b7c9-812e-4225-b641-5afd66621c1b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <YNzhYANzlLfIXNx6d2h5m6cq5N_urtxnua8aJP6LoRk=.ad89b7c9-812e-4225-b641-5afd66621c1b@github.com>
Message-ID: <huU20v7u0O7qtjkJcgaJvgUEnwWst7Tj57mmRTHakaU=.3cd55244-c2f6-4ad4-9460-a064d2313805@github.com>

On Tue, 30 May 2023 20:31:55 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize
>> All client tests passed after change
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 997:
> 
>> 995:                     // let's return into the normal states first
>> 996:                     execute(CWrapper.NSWindow::deminiaturize);
>> 997:                     peer.displayChanged();
> 
> Same as above. What happens if we move from `NORMAL` to `MAXIMIZED_BOTH`?
>  
> Shall we call `peer.displayChanged()` when a frame is moved to `NORMAL` state? I know that cases are not covered by the test but it seems the issue takes place there. Can you investigate, please?

I believe the main issue is that there is a native event that changes the window state, but when two state changes are done back to back sometimes that native event isn't delivered quickly enough before the second state change occurs, which causes this test to fail. When a frame is moved to a normal state, there are no back to back state changes, since all we do is change the state back to normal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1213643426


From achung at openjdk.org  Thu Jun  1 20:27:15 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 1 Jun 2023 20:27:15 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <huU20v7u0O7qtjkJcgaJvgUEnwWst7Tj57mmRTHakaU=.3cd55244-c2f6-4ad4-9460-a064d2313805@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <YNzhYANzlLfIXNx6d2h5m6cq5N_urtxnua8aJP6LoRk=.ad89b7c9-812e-4225-b641-5afd66621c1b@github.com>
 <huU20v7u0O7qtjkJcgaJvgUEnwWst7Tj57mmRTHakaU=.3cd55244-c2f6-4ad4-9460-a064d2313805@github.com>
Message-ID: <ajAV8ZfnT8bzYVSSdIWRdY7LbLwljwJEVFzIhf2k3QI=.b3027d5e-24ea-4c87-8590-c2d638b272d0@github.com>

On Thu, 1 Jun 2023 20:24:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 997:
>> 
>>> 995:                     // let's return into the normal states first
>>> 996:                     execute(CWrapper.NSWindow::deminiaturize);
>>> 997:                     peer.displayChanged();
>> 
>> Same as above. What happens if we move from `NORMAL` to `MAXIMIZED_BOTH`?
>>  
>> Shall we call `peer.displayChanged()` when a frame is moved to `NORMAL` state? I know that cases are not covered by the test but it seems the issue takes place there. Can you investigate, please?
>
> I believe the main issue is that there is a native event that changes the window state, but when two state changes are done back to back sometimes that native event isn't delivered quickly enough before the second state change occurs, which causes this test to fail. When a frame is moved to a normal state, there are no back to back state changes, since all we do is change the state back to normal.

If I set a delay between the state changes, the problem will also disappear and the test passes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1213644016


From achung at openjdk.org  Thu Jun  1 20:59:05 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 1 Jun 2023 20:59:05 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <vP3UNhVk-3JE3kslnLHXVjBa4GkIZWbsRTV1-XH05OM=.fb4671ab-4c92-4749-aad4-54091d1d143a@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <vP3UNhVk-3JE3kslnLHXVjBa4GkIZWbsRTV1-XH05OM=.fb4671ab-4c92-4749-aad4-54091d1d143a@github.com>
Message-ID: <LUVWHhmsJ0GETK18ZCShK_bQ6bN0pBYFMNk7rY44kj8=.379de6b7-4f56-4697-b123-5849c049ce3e@github.com>

On Tue, 30 May 2023 21:25:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> BTW it is unclear what the call to "displayChanged" will fix. Will it set the correct "graphicsDevice", if yes then what gD was used before the call, if not then what property is updated by the "displayChanged"?

I think the problem is that the first state change (uniconify) causes a native event that changes the frame's state, but that event isn't delivered until after the second state change (maximize) occurs, which is causing problems on the final state of the frame. The displayChanged call between these state changes was intended to flush the native event queue and cause the event to be delivered between the state changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1572767473


From achung at openjdk.org  Thu Jun  1 21:13:16 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 1 Jun 2023 21:13:16 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v9]
In-Reply-To: <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>
Message-ID: <G92zxe3G10RLeB0WqUX61gsNiDHtrY3d4WLO6YwjdTY=.228d8304-8e25-4796-aad0-a50e054063e2@github.com>

On Thu, 1 Jun 2023 19:56:28 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling values of  up-to 350%.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code changes as per code review

src/java.desktop/share/classes/sun/swing/CachedPainter.java line 318:

> 316:         public Image getResolutionVariant(double destWidth, double destHeight) {
> 317:             int w = (int) Math.floor(destWidth + 0.5);
> 318:             int h = (int) Math.floor(destHeight + 0.5);

Does this problem only affect windows? Will this change in shared code affect the painting of other platforms?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1213684481


From achung at openjdk.org  Thu Jun  1 21:32:05 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 1 Jun 2023 21:32:05 GMT
Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS
In-Reply-To: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
References: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
Message-ID: <JELA8fTmqsRTAdvuVWAAvQFMVwiiJVHsJ85aSpKS96Y=.22bd4a03-a915-4113-862c-a56a70add7ea@github.com>

On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation.
> Fix is made to set the printable with correct PageFormat
> 
> It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed..

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13950#pullrequestreview-1456342173


From rmahajan at openjdk.org  Thu Jun  1 21:40:13 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 1 Jun 2023 21:40:13 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v9]
In-Reply-To: <G92zxe3G10RLeB0WqUX61gsNiDHtrY3d4WLO6YwjdTY=.228d8304-8e25-4796-aad0-a50e054063e2@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>
 <G92zxe3G10RLeB0WqUX61gsNiDHtrY3d4WLO6YwjdTY=.228d8304-8e25-4796-aad0-a50e054063e2@github.com>
Message-ID: <kXEu1YcnHnllZvsVMGMj3uNvItFaNLPD7QtaETokxCw=.78f83889-309e-472a-826d-006b4614fb58@github.com>

On Thu, 1 Jun 2023 21:10:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code changes as per code review
>
> src/java.desktop/share/classes/sun/swing/CachedPainter.java line 318:
> 
>> 316:         public Image getResolutionVariant(double destWidth, double destHeight) {
>> 317:             int w = (int) Math.floor(destWidth + 0.5);
>> 318:             int h = (int) Math.floor(destHeight + 0.5);
> 
> Does this problem only affect windows? Will this change in shared code affect the painting of other platforms?

I think this function was added by the fix for [JDK-8143064](https://bugs.openjdk.org/browse/JDK-8143064) : Icons are not properly rendered with Windows L&F on HiDPI display

which was for Windows.
I tested my change on other platforms as well , didn't see any regression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1213707976


From jiangli at openjdk.org  Thu Jun  1 23:41:08 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 1 Jun 2023 23:41:08 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
Message-ID: <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>

On Thu, 1 Jun 2023 16:18:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.
> > 
> > 
> > I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17).
> > @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light.
> 
> There are no extra options. I suspect it's an issue with the older GCC version. Here is one failing command line:
> 
> ```
> $ ( cd /home/erik/git/jdk/build/linux-arm32 ; /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -r --sysroot=/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/arm-linux-gnueabihf/sysroot -o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/GC.o )
> /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libgcc_s.so.1
> ```
> 

Thanks a lot for looking into the issue.

> > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.
> 
> This seems to be Clang specific, so maybe only apply this to Clang and not GCC? Have you measured the difference in link time and concluded that this workaround is needed? If so, how big were the differences? 

It was noticeably slower (which prompted me looked into it at that time) when linking the executable using the static libraries created without partial linking workaround. In my experiments, it took >2m when linking final executable. With the mitigation the final linking took a few seconds.

> Given that it prints a lot of warnings on mac, I would suggest leaving the partial linking out of this patch to get something in that is actually working. It was included in this patch because of the side effect it had with handling long path names. However, since looking closer at that issue, we were using a different workaround for Clang already and that same workaround should work fine for AR on mac as well.

Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1572922666


From tr at openjdk.org  Fri Jun  2 04:33:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 2 Jun 2023 04:33:23 GMT
Subject: Integrated: 8307105: JFileChooser InvalidPathException when selecting
 some system folders on Windows
In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com>
References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com>
Message-ID: <1XNYxZRheairfwmcHX7lvirBvDXztfYyWrtFoq6sMqQ=.bb416358-1514-4d3a-a440-f8a9103dc654@github.com>

On Tue, 16 May 2023 06:40:20 GMT, Tejesh R <tr at openjdk.org> wrote:

> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me.
> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine.

This pull request has now been integrated.

Changeset: 325940b0
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/325940b0919e649e84358db35a55b3ac5dfe0acf
Stats:     103 lines in 3 files changed: 93 ins; 6 del; 4 mod

8307105: JFileChooser InvalidPathException when selecting some system folders on Windows

Reviewed-by: aivanov, abhiscxk, dnguyen

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

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


From psadhukhan at openjdk.org  Fri Jun  2 05:04:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2023 05:04:14 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v14]
In-Reply-To: <-OV3Vd-01D7mIQaBE94Um1XHcKnEbtNLrYXLpEJ5EPw=.f8fc5ca5-d2bf-49c6-bdb8-faa209028f78@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <e6WzkAOeXkJUPcJB6VFsfz-r9Pbo2S4uLpqZM55qm00=.5c63c114-6b0d-4ac6-90b8-04a3d756e4f9@github.com>
 <-OV3Vd-01D7mIQaBE94Um1XHcKnEbtNLrYXLpEJ5EPw=.f8fc5ca5-d2bf-49c6-bdb8-faa209028f78@github.com>
Message-ID: <f59dd_WTgB3I18Dp2erxXBBuD2U8SIvA-QGK-KD1dEY=.971d423c-a0a3-414b-9bd6-bc409da01217@github.com>

On Thu, 1 Jun 2023 18:33:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use relative variable in equals/hashcode
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:
> 
>> 2682:             return val instanceof CSS.LengthValue lu
>> 2683:                    && Objects.equals(svalue, lu.svalue);
>> 2684:         }
> 
> Why is this case still using the string and not 'span' ?

This is because it can cater to both units like px,pt and %
For example, for attributes
`{"margin-top: 42px", "margin-top: 22px"}`

`span `22.0, 42.0
`percentage `false
`units `px

where we can use `span == lu.span && units == lu.units` check
but for attributes like
`{"margin-top: 100%", "margin-top: 200%"}`

`span `1.0 for both
`percentage `true
`units `null 
(where the above equality check will not work and we need to use the string so for optimization I have used the same check for both)
I guess span is 1.0 is because of this code 
https://github.com/openjdk/jdk/blob/325940b0919e649e84358db35a55b3ac5dfe0acf/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2557-L2561

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1213916093


From duke at openjdk.org  Fri Jun  2 07:30:10 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 2 Jun 2023 07:30:10 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop [v2]
In-Reply-To: <TJ4ZuiUOzNgmeTalNRta01Lq-7xWVdR5QFU39Dl9lGs=.a7b5e0f1-c78e-4616-a820-88bb9d886811@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
 <TJ4ZuiUOzNgmeTalNRta01Lq-7xWVdR5QFU39Dl9lGs=.a7b5e0f1-c78e-4616-a820-88bb9d886811@github.com>
Message-ID: <kgFX13WwZFNGX0Q0Wt51SW3H_rlk4KOW0y3L42Qw_dU=.6b376a0a-4207-41d5-8cb0-9887ade9eba9@github.com>

On Thu, 1 Jun 2023 17:31:28 GMT, JoKern65 <duke at openjdk.org> wrote:

>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.desktop.
>> prrace had already reviewed this part in the original pr.
>> 
>> Here are the handled errors for which we use the same warning disabling as gcc.
>> 
>> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
>> extern int XShmQueryExtension();
>> ^
>> /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
>> Bool XShmQueryExtension(
>> ^
>> solved by adding line (generic, because several source files are involved)
>> DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \
>> 
>> src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>> if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
>> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \
>> 
>> src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
>> ^~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \
>> 
>> src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
>> ^~~~~~~~~~~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \
>> 
>> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>> if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
>> 
>> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>> if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
>> ~~~~~~~~~~~~^
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \
>> 
> ...
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Awt2dLibraries.gmk
>   
>   followed prrace annotation

Pre-submit failure is unrelated. Win testing passed in SAP nightlies.

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

PR Comment: https://git.openjdk.org/jdk/pull/14263#issuecomment-1573281973


From goetz at openjdk.org  Fri Jun  2 07:39:15 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Fri, 2 Jun 2023 07:39:15 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop [v2]
In-Reply-To: <TJ4ZuiUOzNgmeTalNRta01Lq-7xWVdR5QFU39Dl9lGs=.a7b5e0f1-c78e-4616-a820-88bb9d886811@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
 <TJ4ZuiUOzNgmeTalNRta01Lq-7xWVdR5QFU39Dl9lGs=.a7b5e0f1-c78e-4616-a820-88bb9d886811@github.com>
Message-ID: <LbrXowt-PmyKdKHnqKwT2j8991kytKy89a9PJv8LXlg=.766f4ff9-2bed-415e-9dc1-6ed9179a29e6@github.com>

On Thu, 1 Jun 2023 17:31:28 GMT, JoKern65 <duke at openjdk.org> wrote:

>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.desktop.
>> prrace had already reviewed this part in the original pr.
>> 
>> Here are the handled errors for which we use the same warning disabling as gcc.
>> 
>> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
>> extern int XShmQueryExtension();
>> ^
>> /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
>> Bool XShmQueryExtension(
>> ^
>> solved by adding line (generic, because several source files are involved)
>> DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \
>> 
>> src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>> if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
>> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \
>> 
>> src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
>> ^~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \
>> 
>> src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
>> ^~~~~~~~~~~~~~~~~~~~
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \
>> 
>> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>> if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
>> 
>> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>> if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
>> ~~~~~~~~~~~~^
>> solved by adding line
>> DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \
>> 
> ...
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Awt2dLibraries.gmk
>   
>   followed prrace annotation

LGTM

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

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14263#pullrequestreview-1456810978


From goetz at openjdk.org  Fri Jun  2 07:39:17 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Fri, 2 Jun 2023 07:39:17 GMT
Subject: RFR: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop [v2]
In-Reply-To: <TmiGWYyo27UPgXSh-tD312B4wYSa9YtsoD47XYM8KIM=.10961445-00ee-40b8-8c5b-2231da9ba06a@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
 <TmiGWYyo27UPgXSh-tD312B4wYSa9YtsoD47XYM8KIM=.10961445-00ee-40b8-8c5b-2231da9ba06a@github.com>
Message-ID: <03FQ2Sq_t1uArmrfNcH1xg2Lugvgtu9uB4Ll7Iu-YuQ=.06b04ec4-d6b8-4fcb-9e3a-91fa9d65ff4a@github.com>

On Thu, 1 Jun 2023 17:13:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Awt2dLibraries.gmk
>>   
>>   followed prrace annotation
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 708:
> 
>> 706:   # The external libpng submitted in the jdk is an old version
>> 707:   # which does not contain .png_init_filter_functions_vsx.
>> 708:   # Therefore we need to disable PNG_POWERPC_VSX_OPT explicitely by setting
> 
> explicitely -> explicitly
> 
> And it isn't an old version. It is very current.
> I think we just chose not to import functionality we weren't using.

Was fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14263#discussion_r1214029889


From duke at openjdk.org  Fri Jun  2 07:39:19 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 2 Jun 2023 07:39:19 GMT
Subject: Integrated: JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop
In-Reply-To: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
References: <XQjb5_e8Y2GsgupU_YwzqOB-DeTDbPOFW3nTsIdQEI4=.7ccbdd63-5068-4ea0-835d-bf39bbc55353@github.com>
Message-ID: <QwftmeB-LUYYqOk6REqQRcZNCW4TM1S-Mzj3nEbc-o4=.9df2241e-8702-4bd1-afee-2a3778b20c7c@github.com>

On Thu, 1 Jun 2023 13:16:49 GMT, JoKern65 <duke at openjdk.org> wrote:

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.desktop.
> prrace had already reviewed this part in the original pr.
> 
> Here are the handled errors for which we use the same warning disabling as gcc.
> 
> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
> extern int XShmQueryExtension();
> ^
> /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
> Bool XShmQueryExtension(
> ^
> solved by adding line (generic, because several source files are involved)
> DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \
> 
> src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
> ^~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \
> 
> src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
> ^~~~~~~~~~~~~~~~~~~~
> solved by adding line
> DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
> 
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
> if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
> ~~~~~~~~~~~~^
> solved by adding line
> DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \
> 
> src/java.desktop/unix/native/libawt_xawt/a...

This pull request has now been integrated.

Changeset: dcd9590f
Author:    JoKern65 <128386669+JoKern65 at users.noreply.github.com>
Committer: Goetz Lindenmaier <goetz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dcd9590feda8da844b93d3142dab5a7699cc502f
Stats:     25 lines in 2 files changed: 24 ins; 0 del; 1 mod

8309224: Fix xlc17 clang 15 warnings in java.desktop

Reviewed-by: prr, goetz

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

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


From psadhukhan at openjdk.org  Fri Jun  2 08:12:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2023 08:12:55 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Optimization removed to use local variables for non-percentage units

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/833ff8fd..4683844d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=13-14

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

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


From psadhukhan at openjdk.org  Fri Jun  2 08:12:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2023 08:12:57 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v14]
In-Reply-To: <f59dd_WTgB3I18Dp2erxXBBuD2U8SIvA-QGK-KD1dEY=.971d423c-a0a3-414b-9bd6-bc409da01217@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <e6WzkAOeXkJUPcJB6VFsfz-r9Pbo2S4uLpqZM55qm00=.5c63c114-6b0d-4ac6-90b8-04a3d756e4f9@github.com>
 <-OV3Vd-01D7mIQaBE94Um1XHcKnEbtNLrYXLpEJ5EPw=.f8fc5ca5-d2bf-49c6-bdb8-faa209028f78@github.com>
 <f59dd_WTgB3I18Dp2erxXBBuD2U8SIvA-QGK-KD1dEY=.971d423c-a0a3-414b-9bd6-bc409da01217@github.com>
Message-ID: <0cVO0a9ZD0CWz_jasouQzZerDbSh1Gz-oc-OYzhUp1c=.92333202-43e5-44f5-86c5-3cb3d98c10dd@github.com>

On Fri, 2 Jun 2023 04:57:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:
>> 
>>> 2682:             return val instanceof CSS.LengthValue lu
>>> 2683:                    && Objects.equals(svalue, lu.svalue);
>>> 2684:         }
>> 
>> Why is this case still using the string and not 'span' ?
>
> This is because it can cater to both units like px,pt and %
> For example, for attributes
> `{"margin-top: 42px", "margin-top: 22px"}`
> 
> `span `22.0, 42.0
> `percentage `false
> `units `px
> 
> where we can use `span == lu.span && units == lu.units` check
> but for attributes like
> `{"margin-top: 100%", "margin-top: 200%"}`
> 
> `span `1.0 for both
> `percentage `true
> `units `null 
> (where the above equality check will not work and we need to use the string so for optimization I have used the same check for both)
> I guess span is 1.0 is because of this code 
> https://github.com/openjdk/jdk/blob/325940b0919e649e84358db35a55b3ac5dfe0acf/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2557-L2561

Removed optimization for non-percentage units which I guess will be more used and it will also do away with `{"margin-top: 42px", "margin-top: 42 px"}` space issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1214059460


From tr at openjdk.org  Fri Jun  2 08:30:07 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 2 Jun 2023 08:30:07 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
Message-ID: <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>

On Thu, 1 Jun 2023 17:22:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We should check why that code does not work, note the code in that patch also support both Window and Canvas.

We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1573355016


From itakiguchi at openjdk.org  Fri Jun  2 10:09:10 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 2 Jun 2023 10:09:10 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
In-Reply-To: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
Message-ID: <QbVEy063LG6KeW4ezWZi5IbVu98EPIelbJnFodHYxuU=.263eb4ec-cd9b-40be-884f-9ea77595a031@github.com>

On Thu, 11 May 2023 18:23:45 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX, lib/fontconfig.bfc file is used to find font setting.
> I ran SwingSet2 List demo program with AIX C locale.
> JDK21's line spacing is larger then JDK17.
> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
> 
> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
> `native.encoding` system property has platform's encoding/charset name.
> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
> 
> Additionally, following parts are changed:
> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
> For Java for AIX:
> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
> 
> In my understanding, this fix affects just for AIX platform.
> 
> Note:
> macos-x64 tier1 test was failed, but I think it's not related this PR.

Gentle reminder.
I would appreciate your input when you have a moment.
If possible, I'd like to put this change into AIX's JDK 21 GA build.
Thanks in advance.

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

PR Comment: https://git.openjdk.org/jdk/pull/13937#issuecomment-1573482779


From jwaters at openjdk.org  Fri Jun  2 11:55:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Jun 2023 11:55:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>
Message-ID: <BsmdPW642IrO-SFPRr1_O9B2UJmgXhQg-7tl90IwXK0=.5384f33d-ae2d-4bb3-b684-df10b219e937@github.com>

On Thu, 1 Jun 2023 17:43:02 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm not sure I understand the logic here. I would not want to move to using Java typedefs in places where the windows APIs specify the types they are expecting. If something comes in from a JNI down-call we should convert it to the type expected by Windows using the name expected by Windows.

I can change the jints in this PR to regular ints if required. As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints, so our existing declarations of passing longs to them are also wrong regardless, even without the Java typedefs

Actually, now that I revisit this issue (shown in the list above), the only actual calls in this change that _don't_ take Java typedefs are the calls to ::Arc and ::Pie, so this is less of a problem than initially expected

> Also "compilation" isn't nearly good enough. How is this being tested?

`-permissive-`

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1573611091


From psadhukhan at openjdk.org  Fri Jun  2 12:10:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2023 12:10:14 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
Message-ID: <YCUY3-B-TXopa98TTlnvRtVTX84irVqRHcB-aAPBKMs=.98858b2a-98ac-4723-a1b6-aae2a9882c67@github.com>

On Thu, 1 Jun 2023 18:38:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
>> 
>> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
>> So now we make an exclusion for this case.
>> 
>> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
>> Other tests are also passed.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix toolkit if condition

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 410:

> 408:         Toolkit toolkit = Toolkit.getDefaultToolkit();
> 409:         if (!(toolkit instanceof SunToolkit)
> 410:                 || !((SunToolkit) toolkit).isRunningOnWayland()) {

Although it's not related to this fix, but `SunToolkit.isRunningOnWayland` does not have javadoc/comment, maybe we can think of adding one there since we added a javadoc-style comment for this private method in non-spec class

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 418:

> 416:                         XDnDConstants.XA_XdndAware,
> 417:                         0, 1, false,
> 418:                         XConstants.AnyPropertyType);

I guess formatting can follow this style as the newlines are starting abruptly it seems
https://github.com/openjdk/jdk/blob/73e7af9e28805dda25f91fd509e3860d8586ad9f/src/java.desktop/unix/classes/sun/awt/X11/XDnDDragSourceProtocol.java#L196-L197

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 422:

> 420:         try {
> 421:             int status = wpg.execute(XErrorHandler
> 422:                     .IgnoreBadWindowHandler.getInstance());

I guess better will be to format so that `IgnoreBadWindowHandler` is placed below `XErrorHandler` as it belongs to that class

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 426:

> 424:             return status == XConstants.Success
> 425:                     && wpg.getData() != 0
> 426:                     && wpg.getActualType() == XAtom.XA_ATOM;

Better to align just below s of `status`

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 448:

> 446:         }
> 447: 
> 448:         if (isXWaylandDndAwareWindow(window)) {

https://github.com/openjdk/jdk/blob/ec4493f5273746fdbc2a9c9451c15050d04730d2/src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java#L441-L444

Is it not required to do `win != 0 && isXWaylandDndAwareWindow()`  since we are returning value from here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214096897
PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214105030
PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214124414
PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214126806
PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214122682


From dmarkov at openjdk.org  Fri Jun  2 12:53:07 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Fri, 2 Jun 2023 12:53:07 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <W0NSn4cNs3FjTHG2D-QFaMBKEZFmbn8AB0He5kgEzKQ=.98ed00e1-0769-4f23-8753-b66b746c5339@github.com>

On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung <achung at openjdk.org> wrote:

> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize
> All client tests passed after change

If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation.
When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. 
In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1573685311


From erikj at openjdk.org  Fri Jun  2 14:07:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Jun 2023 14:07:09 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
 <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
Message-ID: <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>

On Thu, 1 Jun 2023 23:38:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?

I have no concerns regarding clang on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1573796012


From azvegint at openjdk.org  Fri Jun  2 14:11:18 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 2 Jun 2023 14:11:18 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v3]
In-Reply-To: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
Message-ID: <oWfTjLsB-cVmuj0xO907BIxUka7c5uJShQ0sqzZnY9A=.72dfedae-c060-4c99-90eb-9e4db25d08d3@github.com>

> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
> 
> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
> So now we make an exclusion for this case.
> 
> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
> Other tests are also passed.

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

  review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14266/files
  - new: https://git.openjdk.org/jdk/pull/14266/files/ec4493f5..c0b43f19

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

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

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


From azvegint at openjdk.org  Fri Jun  2 14:11:20 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 2 Jun 2023 14:11:20 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <YCUY3-B-TXopa98TTlnvRtVTX84irVqRHcB-aAPBKMs=.98858b2a-98ac-4723-a1b6-aae2a9882c67@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
 <YCUY3-B-TXopa98TTlnvRtVTX84irVqRHcB-aAPBKMs=.98858b2a-98ac-4723-a1b6-aae2a9882c67@github.com>
Message-ID: <QQjfs8_noiDFdPPilBkkZSsrmk22zcrRG1aV4yde8RM=.633eaffd-a624-4dba-8197-17bfc15a3278@github.com>

On Fri, 2 Jun 2023 08:42:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix toolkit if condition
>
> src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 410:
> 
>> 408:         Toolkit toolkit = Toolkit.getDefaultToolkit();
>> 409:         if (!(toolkit instanceof SunToolkit)
>> 410:                 || !((SunToolkit) toolkit).isRunningOnWayland()) {
> 
> Although it's not related to this fix, but `SunToolkit.isRunningOnWayland` does not have javadoc/comment, maybe we can think of adding one there since we added a javadoc-style comment for this private method in non-spec class

Sure, added.

> src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 448:
> 
>> 446:         }
>> 447: 
>> 448:         if (isXWaylandDndAwareWindow(window)) {
> 
> https://github.com/openjdk/jdk/blob/ec4493f5273746fdbc2a9c9451c15050d04730d2/src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java#L441-L444
> 
> Is it not required to do `win != 0 && isXWaylandDndAwareWindow()`  since we are returning value from here too?

Not sure what is the purpose of `win != 0 && isXWaylandDndAwareWindow()`, it'll change the behavior for the  X11 session(isXWaylandDndAwareWindow is always false in this case).

`findClientWindow` is a recursive function, and the `isXWaylandDndAwareWindow` check is already performed within the call from line 442.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214379664
PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1214412965


From duke at openjdk.org  Fri Jun  2 14:15:24 2023
From: duke at openjdk.org (duke)
Date: Fri, 2 Jun 2023 14:15:24 GMT
Subject: Withdrawn: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
References: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
Message-ID: <TPY_0jycjk7MB5aXmruNzwKVVVVAZEvWSoyvT8DCVCs=.fb222985-b525-4f7b-83e9-2aeb7ce5c6e0@github.com>

On Wed, 22 Mar 2023 19:12:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `'java.awt.MenuBar#shortcuts` creates a 'Vector<MenuShortcut>', fills it and then returns its 'Enumeration elements()' as return value.
> Instead of usage of legacy synchronized Vector here we can use ArrayList instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result type.

This pull request has been closed without being integrated.

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

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


From ngubarkov at openjdk.org  Fri Jun  2 15:58:26 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Fri, 2 Jun 2023 15:58:26 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v20]
In-Reply-To: <r2342xyr5gxyL71JaSgboy4UlWRzrDLg68QD4La_g44=.0ce24218-a6de-4464-a536-6535949fbe51@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <r2342xyr5gxyL71JaSgboy4UlWRzrDLg68QD4La_g44=.0ce24218-a6de-4464-a536-6535949fbe51@github.com>
Message-ID: <mDRfnwzu69rVfy4O5ggZX017CrSzPsT-MP2tExD4ee4=.1acaf292-2bb7-42b4-8a8e-37e8d60e8efd@github.com>

On Wed, 5 Apr 2023 14:31:34 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> 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

?

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

PR Comment: https://git.openjdk.org/jdk/pull/4798#issuecomment-1573960024


From dnguyen at openjdk.org  Fri Jun  2 16:29:09 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 2 Jun 2023 16:29:09 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <_WDWpM6O5sVouG4giMpKF4h-a2PdooMEeGsqsQlBq34=.bd663d3a-7820-4159-9d7b-aba1b071f865@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <_WDWpM6O5sVouG4giMpKF4h-a2PdooMEeGsqsQlBq34=.bd663d3a-7820-4159-9d7b-aba1b071f865@github.com>
Message-ID: <eLdMPkg6b7UplYoMJhd6vnIgNXMLDn0dZbBxgmbZJM0=.11aa48df-a476-4f54-bbff-94213d375750@github.com>

On Thu, 1 Jun 2023 16:15:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 698:
> 
>> 696:                         newGC = gds[i].getDefaultConfiguration();
>> 697:                         if (target != null
>> 698:                                 && target.getBackground() != SystemColor.window
> 
> This doesn't seem right, it'll change to a translucent gc even for opaque windows that has some non standard color as a background.
> 
> Probably it is better to check if previous gc was translucent capable 
> `&& target.getGraphicsConfiguration().isTranslucencyCapable()`

I agree. I recently worked on a bug involving window backgrounds and translucency is only one aspect of it. The color itself may be different and this conditional looks like it would definitely trigger in the case where the window changes color between screens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1214578709


From dnguyen at openjdk.org  Fri Jun  2 16:29:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 2 Jun 2023 16:29:13 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>

On Wed, 31 May 2023 11:34:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 43:

> 41:  * @bug 8006421
> 42:  * @key headful
> 43:  * @requires (os.family == "linux")

Does this have to be linux only? Can't this be a generic test?

test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 62:

> 60: 
> 61:         if (gds.length != 2)
> 62:         {

Move curly brace to the same line as if.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1214581893
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1214580368


From honkar at openjdk.org  Fri Jun  2 18:04:15 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Jun 2023 18:04:15 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently on
 Win10 & Win11
Message-ID: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>

ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 

Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times, a defensive fix has been applied. The fix is made to the base class -OverlappingTestBase.java, which holds the common Standard Test Machinery for AWT_Mixing tests.

 `Toolkit.getDefaultToolkit().sync()` is added `OverlappingTestBase.testComponent()`. I believe Thread.sleep(500) alone, might not be sufficient to flush all the graphics events of this test on slower systems which might be causing this test to fail intermittently during CI runs.

Screenshot capture has been added to ViewportOverlapping.java to aid debugging this intermittent issue, in case it should occur again. 

PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

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

Commit messages:
 - exapnded imports
 - initial test fix

Changes: https://git.openjdk.org/jdk/pull/14289/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14289&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299052
  Stats: 112 lines in 3 files changed: 54 ins; 13 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/14289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14289/head:pull/14289

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


From aivanov at openjdk.org  Fri Jun  2 18:15:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 2 Jun 2023 18:15:07 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <k2KhX4RO23V2Zv3-subo4xKloejmbGvUjGUdjZ24BXY=.7877f56b-dfbe-4ddc-b5d8-10efabce4638@github.com>

On Fri, 2 Jun 2023 17:56:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times, a defensive fix has been applied. The fix is made to the base class -OverlappingTestBase.java, which holds the common Standard Test Machinery for AWT_Mixing tests.
> 
>  `Toolkit.getDefaultToolkit().sync()` is added `OverlappingTestBase.testComponent()`. I believe Thread.sleep(500) alone, might not be sufficient to flush all the graphics events of this test on slower systems which might be causing this test to fail intermittently during CI runs.
> 
> Screenshot capture has been added to ViewportOverlapping.java to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

This is a continuation of #11747, why not in the old review?

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

PR Comment: https://git.openjdk.org/jdk/pull/14289#issuecomment-1574128197


From honkar at openjdk.org  Fri Jun  2 18:18:05 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Jun 2023 18:18:05 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11
In-Reply-To: <k2KhX4RO23V2Zv3-subo4xKloejmbGvUjGUdjZ24BXY=.7877f56b-dfbe-4ddc-b5d8-10efabce4638@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <k2KhX4RO23V2Zv3-subo4xKloejmbGvUjGUdjZ24BXY=.7877f56b-dfbe-4ddc-b5d8-10efabce4638@github.com>
Message-ID: <0LVL2TbyhTRGe7lvIIeNa7oFStQQ372aGA1FAcIo1Xo=.50d76a0a-3470-472a-93f9-927a448c15f3@github.com>

On Fri, 2 Jun 2023 18:12:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is a continuation of #11747, why not in the old review?

I had withdrawn the previous PR and deleted the local branch corresponding to the old changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14289#issuecomment-1574131393


From aivanov at openjdk.org  Fri Jun  2 18:22:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 2 Jun 2023 18:22:05 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <OjVP6FrRJqtIml9tm-ff732Nrs_9aH9Kls_aph20yfI=.71d82c31-9c71-4551-b031-484ec28e876b@github.com>

On Fri, 2 Jun 2023 17:56:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times, a defensive fix has been applied. The fix is made to the base class -OverlappingTestBase.java, which holds the common Standard Test Machinery for AWT_Mixing tests.
> 
>  `Toolkit.getDefaultToolkit().sync()` is added `OverlappingTestBase.testComponent()`. I believe Thread.sleep(500) alone, might not be sufficient to flush all the graphics events of this test on slower systems which might be causing this test to fail intermittently during CI runs.
> 
> Screenshot capture has been added to ViewportOverlapping.java to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 496:

> 494: 
> 495:         // wait for graphic effects on systems like Win7
> 496:         Toolkit.getDefaultToolkit().sync();

The recommended way now is to use `Robot.waitForIdle` which calls `Toolkit.sync()` in a loop. This is what `Util.waitForIdle` does, I believe.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 501:

> 499:         } catch (InterruptedException e) {
> 500:             e.printStackTrace();
> 501:         }

You have `robot`, so you can use `robot.delay(500)` to avoid catching the exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1214677014
PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1214677560


From honkar at openjdk.org  Fri Jun  2 19:35:23 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Jun 2023 19:35:23 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times, a defensive fix has been applied. The fix is made to the base class -OverlappingTestBase.java, which holds the common Standard Test Machinery for AWT_Mixing tests.
> 
>  `Toolkit.getDefaultToolkit().sync()` is added `OverlappingTestBase.testComponent()`. I believe Thread.sleep(500) alone, might not be sufficient to flush all the graphics events of this test on slower systems which might be causing this test to fail intermittently during CI runs.
> 
> Screenshot capture has been added to ViewportOverlapping.java to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

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

  review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14289/files
  - new: https://git.openjdk.org/jdk/pull/14289/files/9ebbecc3..b3bff669

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

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

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


From honkar at openjdk.org  Fri Jun  2 19:35:25 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Jun 2023 19:35:25 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <OjVP6FrRJqtIml9tm-ff732Nrs_9aH9Kls_aph20yfI=.71d82c31-9c71-4551-b031-484ec28e876b@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjVP6FrRJqtIml9tm-ff732Nrs_9aH9Kls_aph20yfI=.71d82c31-9c71-4551-b031-484ec28e876b@github.com>
Message-ID: <lmRxiWsq8TuK39rRKuMxFQGX0DdRmKIBMNN5vQaW-DM=.f5570302-6379-4936-8f40-cc5471771f9b@github.com>

On Fri, 2 Jun 2023 18:17:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review fix
>
> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 496:
> 
>> 494: 
>> 495:         // wait for graphic effects on systems like Win7
>> 496:         Toolkit.getDefaultToolkit().sync();
> 
> The recommended way now is to use `Robot.waitForIdle` which calls `Toolkit.sync()` in a loop. This is what `Util.waitForIdle` does, I believe.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1214748020


From honkar at openjdk.org  Sat Jun  3 00:12:07 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 3 Jun 2023 00:12:07 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <nWhDQIBBoZ1_JIO2YRwdFV-nV50xUwQILPV5Ozb2nT4=.9564a709-3407-4e8b-829d-2f9074612e5a@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <nWhDQIBBoZ1_JIO2YRwdFV-nV50xUwQILPV5Ozb2nT4=.9564a709-3407-4e8b-829d-2f9074612e5a@github.com>
Message-ID: <rIxOqjIyk584D8eH8GAvq47KJhiBx3yL3Opu2PrzTy4=.82038a86-9096-4cf1-a555-02a6d14908df@github.com>

On Tue, 30 May 2023 21:21:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why this method is not called automatically by our native code? what events are changed since macOS 13.0?

@mrserb There might be a new window state in macOS 13 due to a the new [Stage Manager](https://support.apple.com/en-us/HT213315) feature but I believe this shouldn't affect any existing states.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1574461356


From aturbanov at openjdk.org  Sun Jun  4 21:26:07 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 4 Jun 2023 21:26:07 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
Message-ID: <WqH5qYxnJTIV_ubkLvYNKIKz1gBCjshvVf7KhZqGq5w=.74fa416a-39a2-4a49-bf08-4a848fded880@github.com>

On Fri, 2 Jun 2023 19:35:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 425:

> 423:         try{
> 424:             Thread.sleep(500);
> 425:         } catch(Exception exx) {

Suggestion:

        } catch (Exception exx) {

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 483:

> 481:         try {
> 482:             robot = new Robot();
> 483:         } catch(Exception ignored) {

Suggestion:

        } catch (Exception ignored) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1217156635
PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1217156826


From tr at openjdk.org  Mon Jun  5 03:16:05 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Jun 2023 03:16:05 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
Message-ID: <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>

On Fri, 2 Jun 2023 16:26:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 43:
> 
>> 41:  * @bug 8006421
>> 42:  * @key headful
>> 43:  * @requires (os.family == "linux")
> 
> Does this have to be linux only? Can't this be a generic test?

The fix is specifically for linux ( XWindowPeer).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1217402478


From psadhukhan at openjdk.org  Mon Jun  5 06:53:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2023 06:53:20 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v3]
In-Reply-To: <oWfTjLsB-cVmuj0xO907BIxUka7c5uJShQ0sqzZnY9A=.72dfedae-c060-4c99-90eb-9e4db25d08d3@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <oWfTjLsB-cVmuj0xO907BIxUka7c5uJShQ0sqzZnY9A=.72dfedae-c060-4c99-90eb-9e4db25d08d3@github.com>
Message-ID: <DOR-TW6_s37RYbo7J6YDNBBYVZKb6HMB-KlOG3I57nk=.f1ec4a38-0925-4a6c-8863-5c734c9bc7dc@github.com>

On Fri, 2 Jun 2023 14:11:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
>> 
>> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
>> So now we make an exclusion for this case.
>> 
>> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
>> Other tests are also passed.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments.

src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 416:

> 414:         WindowPropertyGetter wpg =
> 415:             new WindowPropertyGetter(window, XDnDConstants.XA_XdndAware, 0, 1,
> 416:                     false, XConstants.AnyPropertyType);

Minor nit: I guess "false" should be aligned below "window"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1217601367


From psadhukhan at openjdk.org  Mon Jun  5 06:53:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2023 06:53:22 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <QQjfs8_noiDFdPPilBkkZSsrmk22zcrRG1aV4yde8RM=.633eaffd-a624-4dba-8197-17bfc15a3278@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
 <YCUY3-B-TXopa98TTlnvRtVTX84irVqRHcB-aAPBKMs=.98858b2a-98ac-4723-a1b6-aae2a9882c67@github.com>
 <QQjfs8_noiDFdPPilBkkZSsrmk22zcrRG1aV4yde8RM=.633eaffd-a624-4dba-8197-17bfc15a3278@github.com>
Message-ID: <3AslFyrFZ0DGB7kK5qKTCEck7s0Zn3PXDEjoBINto8o=.10c6efa8-47eb-41ae-839c-348cbbc05f44@github.com>

On Fri, 2 Jun 2023 13:53:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java line 448:
>> 
>>> 446:         }
>>> 447: 
>>> 448:         if (isXWaylandDndAwareWindow(window)) {
>> 
>> https://github.com/openjdk/jdk/blob/ec4493f5273746fdbc2a9c9451c15050d04730d2/src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java#L441-L444
>> 
>> Is it not required to do `win != 0 && isXWaylandDndAwareWindow()`  since we are returning value from here too?
>
> Not sure what is the purpose of `win != 0 && isXWaylandDndAwareWindow()`, it'll change the behavior for the  X11 session(isXWaylandDndAwareWindow is always false in this case).
> 
> `findClientWindow` is a recursive function, and the `isXWaylandDndAwareWindow` check is already performed within the call from line 442.

Yes, since it's a recursive function, I was just trying to understand if `isXWaylandDndAwareWindow `is called at right place
I tried a simple recursive program similar to `findClientWindow `which gives StackOverflowError so I was thinking if `findClientWindow  `can also give SOF and whether we should call `isXWaylandDndAwareWindow ` at l446 or l439


public class Recursion {
    public static void main(String[] args) {
        long value = 22;
        System.out.println(test(value));
    }

    private static long test(long value) {
        long arr[] = {1L,2L,3L};
        for (long i : arr) {
            long val = test(i);
            if (val != 0) {
                System.out.println("val " + val);
                return val;
            }
        }
        if (getValue(value) == 22) {
            return value;
        }
        return 0;
    }
    private static long getValue(long value) {
        return value;
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1217601483


From jdv at openjdk.org  Mon Jun  5 09:08:08 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 5 Jun 2023 09:08:08 GMT
Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS
In-Reply-To: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
References: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
Message-ID: <n-vcPblWi7jwC66utliFkAwruofM8sP8KY_OhYCfilI=.8f57d368-6d14-4ab1-9c1e-c8c23c060cbb@github.com>

On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation.
> Fix is made to set the printable with correct PageFormat
> 
> It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed..

Please add latest copyright year before pushing.

Was able to reproduce the issue and its fix.
I can see why we need to pass our PageFormat to setPrintable().

Strange that, we have this "landscape" variable and it is not used to pass appropriate page format. Test update seems fine.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13950#pullrequestreview-1462073152


From psadhukhan at openjdk.org  Mon Jun  5 09:21:13 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2023 09:21:13 GMT
Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS
 [v2]
In-Reply-To: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
References: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
Message-ID: <tOjVZZnD-4DZ097bTJywe1uaoys8HAuDRRNqV2djZhQ=.0970dfcb-d165-4b60-8ad4-e52a85168dbe@github.com>

> Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation.
> Fix is made to set the printable with correct PageFormat
> 
> It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed..

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13950/files
  - new: https://git.openjdk.org/jdk/pull/13950/files/7b366c30..fa25a257

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

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

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


From psadhukhan at openjdk.org  Mon Jun  5 09:21:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2023 09:21:15 GMT
Subject: Integrated: 8296920: Regression Test DialogOrient.java fails on MacOS
In-Reply-To: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
References: <XBKaw9IGm1fzHlESL4fhxryvB8tguOBfEOx_sQUd4gQ=.4e442dea-1f32-4a33-9e69-bbd1dc6a4ccd@github.com>
Message-ID: <pagZS_I3owX5HSAYcjPHyw8EI3N6ErovDuISNzSU3JA=.de693513-b328-4e07-81a2-3ddd2d29acf5@github.com>

On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation.
> Fix is made to set the printable with correct PageFormat
> 
> It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed..

This pull request has now been integrated.

Changeset: 8c9d21e5
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c9d21e5193cd20585eae0636337a78bc9d89f60
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8296920: Regression Test DialogOrient.java fails on MacOS

Reviewed-by: honkar, dnguyen, achung, jdv

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

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


From azvegint at openjdk.org  Mon Jun  5 12:08:05 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 5 Jun 2023 12:08:05 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v4]
In-Reply-To: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
Message-ID: <7GZCFROIGqzDhQRbg_XEL00u71SrHS8kYMZVPks1rJI=.53dee111-60c9-46bf-9bc7-04a57294e09a@github.com>

> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
> 
> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
> So now we make an exclusion for this case.
> 
> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
> Other tests are also passed.

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

  possible SOF fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14266/files
  - new: https://git.openjdk.org/jdk/pull/14266/files/c0b43f19..5c890574

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

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

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


From azvegint at openjdk.org  Mon Jun  5 12:08:06 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 5 Jun 2023 12:08:06 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v2]
In-Reply-To: <3AslFyrFZ0DGB7kK5qKTCEck7s0Zn3PXDEjoBINto8o=.10c6efa8-47eb-41ae-839c-348cbbc05f44@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <KM6mG_WS_GxUFVevfp5QGTCu9kI9xA4XNsgS6HtMSNU=.47263844-d5b3-4415-846f-394b529f2a62@github.com>
 <YCUY3-B-TXopa98TTlnvRtVTX84irVqRHcB-aAPBKMs=.98858b2a-98ac-4723-a1b6-aae2a9882c67@github.com>
 <QQjfs8_noiDFdPPilBkkZSsrmk22zcrRG1aV4yde8RM=.633eaffd-a624-4dba-8197-17bfc15a3278@github.com>
 <3AslFyrFZ0DGB7kK5qKTCEck7s0Zn3PXDEjoBINto8o=.10c6efa8-47eb-41ae-839c-348cbbc05f44@github.com>
Message-ID: <Ehq0cqXasxc9uhrNNfxe6iFer5zaUb0N8-gYIwAgkCk=.f4ed0963-dbcd-41d8-9329-d7881c479b65@github.com>

On Mon, 5 Jun 2023 06:50:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Not sure what is the purpose of `win != 0 && isXWaylandDndAwareWindow()`, it'll change the behavior for the  X11 session(isXWaylandDndAwareWindow is always false in this case).
>> 
>> `findClientWindow` is a recursive function, and the `isXWaylandDndAwareWindow` check is already performed within the call from line 442.
>
> Yes, since it's a recursive function, I was just trying to understand if `isXWaylandDndAwareWindow `is called at right place
> I tried a simple recursive program similar to `findClientWindow `which gives StackOverflowError so I was thinking if `findClientWindow  `can also give SOF and whether we should call `isXWaylandDndAwareWindow ` at l446 or l439
> 
> 
> public class Recursion {
>     public static void main(String[] args) {
>         long value = 22;
>         System.out.println(test(value));
>     }
> 
>     private static long test(long value) {
>         long arr[] = {1L,2L,3L};
>         for (long i : arr) {
>             long val = test(i);
>             if (val != 0) {
>                 System.out.println("val " + val);
>                 return val;
>             }
>         }
>         if (getValue(value) == 22) {
>             return value;
>         }
>         return 0;
>     }
>     private static long getValue(long value) {
>         return value;
>     }
> }

Yes, this could happen if the implementation changes, currently the dummy window has no children.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14266#discussion_r1217973252


From psadhukhan at openjdk.org  Mon Jun  5 12:21:06 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2023 12:21:06 GMT
Subject: RFR: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction [v4]
In-Reply-To: <7GZCFROIGqzDhQRbg_XEL00u71SrHS8kYMZVPks1rJI=.53dee111-60c9-46bf-9bc7-04a57294e09a@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
 <7GZCFROIGqzDhQRbg_XEL00u71SrHS8kYMZVPks1rJI=.53dee111-60c9-46bf-9bc7-04a57294e09a@github.com>
Message-ID: <bZHg3qcvifAa5-G77PN8OsdmFRlCnTj_4oaVh43zIjY=.64f208e7-0c07-4c04-8ab6-cda853e15ffe@github.com>

On Mon, 5 Jun 2023 12:08:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
>> 
>> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
>> So now we make an exclusion for this case.
>> 
>> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
>> Other tests are also passed.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   possible SOF fix

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14266#pullrequestreview-1462403398


From duke at openjdk.org  Mon Jun  5 14:05:07 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Mon, 5 Jun 2023 14:05:07 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <zUZky5XTEn4sEVvXC1cay09bt3PhDoE_zKRhpKX1TGY=.66ca17c1-d615-41d1-96e8-8007681a29db@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> 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

Is there anyone to check this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1576866687


From dnguyen at openjdk.org  Mon Jun  5 14:55:07 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 5 Jun 2023 14:55:07 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
Message-ID: <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>

On Mon, 5 Jun 2023 03:13:01 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 43:
>> 
>>> 41:  * @bug 8006421
>>> 42:  * @key headful
>>> 43:  * @requires (os.family == "linux")
>> 
>> Does this have to be linux only? Can't this be a generic test?
>
> The fix is specifically for linux ( XWindowPeer).

Although the fix is only for linux, the test can be made generic I believe. I think it's preferred to have a test be generic if possible, but I'm OK with the test being linux only too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1218190132


From chen.j.patrick at gmail.com  Mon Jun  5 14:56:42 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 5 Jun 2023 16:56:42 +0200
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when
 the frame is moved to another screen
In-Reply-To: <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
Message-ID: <CANmuJ8vKncsekXO3ZncEDBg-+dgduk0rdwexAzzi_PU+aM4W1A@mail.gmail.com>

no

Le lun. 5 juin 2023 ? 16:56, Damon Nguyen <dnguyen at openjdk.org> a ?crit :

> On Mon, 5 Jun 2023 03:13:01 GMT, Tejesh R <tr at openjdk.org> wrote:
>
> >> test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 43:
> >>
> >>> 41:  * @bug 8006421
> >>> 42:  * @key headful
> >>> 43:  * @requires (os.family == "linux")
> >>
> >> Does this have to be linux only? Can't this be a generic test?
> >
> > The fix is specifically for linux ( XWindowPeer).
>
> Although the fix is only for linux, the test can be made generic I
> believe. I think it's preferred to have a test be generic if possible, but
> I'm OK with the test being linux only too.
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/14246#discussion_r1218190132
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230605/eccc9f4c/attachment.htm>

From tr at openjdk.org  Mon Jun  5 15:09:05 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Jun 2023 15:09:05 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
Message-ID: <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>

On Mon, 5 Jun 2023 14:52:01 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The fix is specifically for linux ( XWindowPeer).
>
> Although the fix is only for linux, the test can be made generic I believe. I think it's preferred to have a test be generic if possible, but I'm OK with the test being linux only too.

Not sure if it can be made generic, because as explained it causes a regression for test - [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1218211051


From dnguyen at openjdk.org  Mon Jun  5 15:31:06 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 5 Jun 2023 15:31:06 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
 <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
Message-ID: <jXWQ5ZrOCcI54cMEXMknqZefCKre0iuUxYr3WnRZ6SU=.d87231f4-4052-47b4-9a24-2eadb70aa5af@github.com>

On Mon, 5 Jun 2023 15:06:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Although the fix is only for linux, the test can be made generic I believe. I think it's preferred to have a test be generic if possible, but I'm OK with the test being linux only too.
>
> Not sure if it can be made generic, because as explained it causes a regression for test - [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java).

I see the difference. Also, I looked back on other fixes that I recall were expanded to be generic, and I see my source of confusion. LAF's were expanded, not tested OS's.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1218245193


From chen.j.patrick at gmail.com  Mon Jun  5 15:31:51 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 5 Jun 2023 17:31:51 +0200
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when
 the frame is moved to another screen
In-Reply-To: <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
 <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
Message-ID: <CANmuJ8uyAhs8Zqo2M0kCocCDnLHEdiN3NeC6tTo1MGXmYc51mw@mail.gmail.com>

https://www.youtube.com/watch?v=umDr0mPuyQc

Le lun. 5 juin 2023 ? 17:10, Tejesh R <tr at openjdk.org> a ?crit :

> On Mon, 5 Jun 2023 14:52:01 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:
>
> >> The fix is specifically for linux ( XWindowPeer).
> >
> > Although the fix is only for linux, the test can be made generic I
> believe. I think it's preferred to have a test be generic if possible, but
> I'm OK with the test being linux only too.
>
> Not sure if it can be made generic, because as explained it causes a
> regression for test - [WindowGCChangeTest.java](
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java
> ).
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/14246#discussion_r1218211051
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230605/fe364eba/attachment.htm>

From tr at openjdk.org  Mon Jun  5 15:37:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Jun 2023 15:37:10 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <jXWQ5ZrOCcI54cMEXMknqZefCKre0iuUxYr3WnRZ6SU=.d87231f4-4052-47b4-9a24-2eadb70aa5af@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
 <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
 <jXWQ5ZrOCcI54cMEXMknqZefCKre0iuUxYr3WnRZ6SU=.d87231f4-4052-47b4-9a24-2eadb70aa5af@github.com>
Message-ID: <NXx9NLRvYxnLsR4ztpFkvHvCVMfk1ym4abkhtYaMJqU=.c2d74763-ee49-44b1-8d89-1fa93c481796@github.com>

On Mon, 5 Jun 2023 15:28:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Not sure if it can be made generic, because as explained it causes a regression for test - [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java).
>
> I see the difference. Also, I looked back on other fixes that I recall were expanded to be generic, and I see my source of confusion. LAF's were expanded, not tested OS's.

Yeah, so as @azvegint suggested I will update the fix. And also I will update the regression test to windows alone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1218253494


From tr at openjdk.org  Mon Jun  5 16:36:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Jun 2023 16:36:42 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v2]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <nkYs6F_gg8mRxvov3m54wot7sBPQAksRg-qrARudu3Y=.77da6e1e-aaca-4112-8b70-cd14de8259b5@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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

  Updated fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/318b0f60..47912757

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

  Stats: 28 lines in 3 files changed: 1 ins; 24 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14246/head:pull/14246

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


From azvegint at openjdk.org  Mon Jun  5 16:38:21 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 5 Jun 2023 16:38:21 GMT
Subject: Integrated: 8280994: [XWayland] Drag and Drop does not work in java ->
 wayland app direction
In-Reply-To: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
References: <rul2Hx7XoZOeD7KtFchNq6lpTlbNlHjbFqXlwPYd4Xg=.9f01f308-c952-474c-a79b-7acb3b94cd2b@github.com>
Message-ID: <f5w1QeM7M80dTwxBk57RSPStBn7Tb4TkiUoX0hUBKNs=.77b9e398-7a72-48e1-8c99-c475165c4bd7@github.com>

On Thu, 1 Jun 2023 15:18:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This change resolves the issue that drag and drop from a Java application to a native Wayland application (such as gedit) is not possible on Linux.
> 
> Our code it quite picky for the drop target, and requires it to be a top level window with the WM_STATE property set, whereas the XWayland server provides dummy windows without this property.
> So now we make an exclusion for this case.
> 
> After the fix it successfully passes previously failed related manual jtreg/conformance tests on Wayland.
> Other tests are also passed.

This pull request has now been integrated.

Changeset: 73352b68
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73352b68c4e19929305ce430cb74ca850b752d22
Stats:     45 lines in 2 files changed: 44 ins; 0 del; 1 mod

8280994: [XWayland] Drag and Drop does not work in java -> wayland app direction

Reviewed-by: prr, psadhukhan

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

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


From prr at openjdk.org  Mon Jun  5 17:50:14 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Jun 2023 17:50:14 GMT
Subject: RFR: JDK-8305593: Add @spec tags in java.desktop [v2]
In-Reply-To: <1pzy8_QMxIKFj-P-BCPMxiKcs-kME72cWvBnYJHgdZQ=.cc7dbbab-d2e9-4dd1-8282-7fe32fe18fc0@github.com>
References: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
 <1pzy8_QMxIKFj-P-BCPMxiKcs-kME72cWvBnYJHgdZQ=.cc7dbbab-d2e9-4dd1-8282-7fe32fe18fc0@github.com>
Message-ID: <1IBlkh8qiI5S4-2wcG0adqEuJoDxDrDWaF36Hh-18L0=.c4e7ab72-a4b5-43f9-ac1d-03b8141f912c@github.com>

On Wed, 31 May 2023 20:35:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files
>
> Jonathan Gibbons 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:
> 
>  - Update narrative references to use `rfc-editor.org` instead of (variants of) `ietf.org`
>  - Merge remote-tracking branch 'upstream/master' into 8305593.at-spec-java.desktop
>  - JDK-8305593: Add @spec tags in java.desktop

All LGTM.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13360#pullrequestreview-1463079092


From prr at openjdk.org  Mon Jun  5 17:54:09 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Jun 2023 17:54:09 GMT
Subject: RFR: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
Message-ID: <4KHBZohzquVZ8NQINYdbwjZMzsG1dEI_zHhPyK5gplM=.725be181-1642-4302-9da8-c41ea863491c@github.com>

On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573).
> 
> This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file.

I note that the previous fix "undid" similar code on windows and mac as well.
Any explanation why it only causes a problem for Linux ?

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14170#pullrequestreview-1463087542


From prr at openjdk.org  Mon Jun  5 19:47:53 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Jun 2023 19:47:53 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
In-Reply-To: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
Message-ID: <t3-gVcnHiTtdJ3ego92XCuKjEGPUmeVmHaortpwI0pM=.779da3d9-2f15-44ec-80e4-63ed276455cc@github.com>

On Thu, 11 May 2023 18:23:45 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX, lib/fontconfig.bfc file is used to find font setting.
> I ran SwingSet2 List demo program with AIX C locale.
> JDK21's line spacing is larger then JDK17.
> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
> 
> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
> `native.encoding` system property has platform's encoding/charset name.
> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
> 
> Additionally, following parts are changed:
> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
> For Java for AIX:
> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
> 
> In my understanding, this fix affects just for AIX platform.
> 
> Note:
> macos-x64 tier1 test was failed, but I think it's not related this PR.

src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 142:

> 140:     private void setEncoding() {
> 141:         encoding = Charset.forName(System.getProperty("native.encoding"),
> 142:                                    UTF_8).name();

It is extremely misleading that this hugely impactful and wrong change is slipped into a bug about AIX.
I don't much care what you do with AIX, but revert this.

The  native.encoding is not something we want to use here.
We had not over-looked that JEP 400 changed this and it is fine.
You are effectively undoing JEP 400 and making fontconfig files be found and use the old encoding when we really want it to match the default encoding as per the fontconfig spec
https://docs.oracle.com/en/java/javase/20/intl/font-configuration-files.html
    Encoding - the canonical name of the default encoding, as provided by java.nio.charset.Charset.defaultCharset().name().

Any env. on which line-spacing changes is because that is what is set up to be in that locale+encoding  and if you want to change it, update the fontconfig file for that locale+encoding.

@naotoj - please comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13937#discussion_r1218518939


From naoto at openjdk.org  Mon Jun  5 19:56:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Jun 2023 19:56:55 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
In-Reply-To: <t3-gVcnHiTtdJ3ego92XCuKjEGPUmeVmHaortpwI0pM=.779da3d9-2f15-44ec-80e4-63ed276455cc@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
 <t3-gVcnHiTtdJ3ego92XCuKjEGPUmeVmHaortpwI0pM=.779da3d9-2f15-44ec-80e4-63ed276455cc@github.com>
Message-ID: <bjHVTuZKYLoOyY1z2mwHIh17egEeJOEkK_C56Kj2KfI=.24bb1289-70f8-4d53-849c-53082e87b5c3@github.com>

On Mon, 5 Jun 2023 19:45:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> On AIX, lib/fontconfig.bfc file is used to find font setting.
>> I ran SwingSet2 List demo program with AIX C locale.
>> JDK21's line spacing is larger then JDK17.
>> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
>> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
>> 
>> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
>> `native.encoding` system property has platform's encoding/charset name.
>> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
>> 
>> Additionally, following parts are changed:
>> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
>> For Java for AIX:
>> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
>> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
>> 
>> In my understanding, this fix affects just for AIX platform.
>> 
>> Note:
>> macos-x64 tier1 test was failed, but I think it's not related this PR.
>
> src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 142:
> 
>> 140:     private void setEncoding() {
>> 141:         encoding = Charset.forName(System.getProperty("native.encoding"),
>> 142:                                    UTF_8).name();
> 
> It is extremely misleading that this hugely impactful and wrong change is slipped into a bug about AIX.
> I don't much care what you do with AIX, but revert this.
> 
> The  native.encoding is not something we want to use here.
> We had not over-looked that JEP 400 changed this and it is fine.
> You are effectively undoing JEP 400 and making fontconfig files be found and use the old encoding when we really want it to match the default encoding as per the fontconfig spec
> https://docs.oracle.com/en/java/javase/20/intl/font-configuration-files.html
>     Encoding - the canonical name of the default encoding, as provided by java.nio.charset.Charset.defaultCharset().name().
> 
> Any env. on which line-spacing changes is because that is what is set up to be in that locale+encoding  and if you want to change it, update the fontconfig file for that locale+encoding.
> 
> @naotoj - please comment.

I agree with Phil here. The proposed fix would violate what's defined in the fontconfig spec. I would expect AIX's font config to correctly choose an appropriate font file for the UTF-8 environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13937#discussion_r1218526887


From kizune at openjdk.org  Mon Jun  5 20:57:59 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 Jun 2023 20:57:59 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v10]
In-Reply-To: <2S3ejSIrUrE8kGjOXkCrT6LuUBcT8kXMtLYenGJJphE=.4bf31044-5c2a-4e1b-bbc8-89302521712f@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <2S3ejSIrUrE8kGjOXkCrT6LuUBcT8kXMtLYenGJJphE=.4bf31044-5c2a-4e1b-bbc8-89302521712f@github.com>
Message-ID: <p1WyKPZ7JWZu8k0yU5YwA_c585Eu_bjW8Lyq9c2FGXM=.1c152038-9697-4949-9da0-0497c52ead1f@github.com>

On Thu, 1 Jun 2023 12:40:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Looks good, seems to be working reasonably well on Ubuntu 20 and 22.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1463418724


From duke at openjdk.org  Mon Jun  5 21:11:08 2023
From: duke at openjdk.org (duke)
Date: Mon, 5 Jun 2023 21:11:08 GMT
Subject: Withdrawn: 8305321: Remove unused exports in java.desktop
In-Reply-To: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>
Message-ID: <tQt56ZEoTdDe5Fg2pK2gceJTh7ZH20wdxdmuaSUwkrU=.4a8afe71-f8a0-4b08-abc4-72e6b2aa84ac@github.com>

On Fri, 31 Mar 2023 07:34:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes a number of unused exports from java.desktop native libraries.
> 
> In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
> - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
> - removed `colorValueID` in X11Color; that field was not used.
> - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.
> 
> The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.
> 
> The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.
> 
> Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.

This pull request has been closed without being integrated.

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

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


From mkartashev at openjdk.org  Tue Jun  6 06:11:54 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 6 Jun 2023 06:11:54 GMT
Subject: RFR: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <4KHBZohzquVZ8NQINYdbwjZMzsG1dEI_zHhPyK5gplM=.725be181-1642-4302-9da8-c41ea863491c@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
 <4KHBZohzquVZ8NQINYdbwjZMzsG1dEI_zHhPyK5gplM=.725be181-1642-4302-9da8-c41ea863491c@github.com>
Message-ID: <N_uCf_ikfHvwaQONPlfCt-O3zBULdzW6JEepIqq60G8=.a8dec4de-1c73-4424-8cfd-b569ac3e543e@github.com>

On Mon, 5 Jun 2023 17:51:27 GMT, Phil Race <prr at openjdk.org> wrote:

> I note that the previous fix "undid" similar code on windows and mac as well.
> Any explanation why it only causes a problem for Linux ?

I will only be able to research that in about 2 weeks from now, sorry.

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

PR Comment: https://git.openjdk.org/jdk/pull/14170#issuecomment-1577972720


From mkartashev at openjdk.org  Tue Jun  6 08:28:59 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 6 Jun 2023 08:28:59 GMT
Subject: Integrated: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
Message-ID: <g9VwB5HCqS42WkeDXHEXeaJobnVSxG8MXkYCD-8km8Y=.bb7e1bca-33e9-4e08-80ff-d1b9a3172b86@github.com>

On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573).
> 
> This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file.

This pull request has now been integrated.

Changeset: 41bf2ad1
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41bf2ad159d274574285a0f55c4a0f582cd93648
Stats:     15 lines in 2 files changed: 5 ins; 2 del; 8 mod

8308875: java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device" is null'

Reviewed-by: avu, prr

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

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


From duke at openjdk.org  Tue Jun  6 09:17:08 2023
From: duke at openjdk.org (duke)
Date: Tue, 6 Jun 2023 09:17:08 GMT
Subject: Withdrawn: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering
In-Reply-To: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
Message-ID: <GTimmj8IAsyhsxZSBJwtD1drlFYkyZp7lpiXU-9_aj4=.b6b781a2-eb36-45c7-82d5-573bbc5e0583@github.com>

On Mon, 27 Mar 2023 21:45:08 GMT, Jeremy <duke at openjdk.org> wrote:

> The original write-up contains two complaints:
> 1. The window is opaque, so pixels that should be transparent are black.
> 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).
> 
> I recommend splitting this up into separate tickets.
> 
> This PR addresses the first (probably most offensive) issue: the window is now transparent.
> 
> I experimented with a change that resolves the second issue (image resolution) here:
> https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002
> 
> ... that works, but IMO that looks riskier and should be part of a separate discussion.
> 
> I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.org  Tue Jun  6 09:30:08 2023
From: duke at openjdk.org (duke)
Date: Tue, 6 Jun 2023 09:30:08 GMT
Subject: Withdrawn: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <esUDEGSeTgTtGyidBOzgqkRZc3DIB0Yt0UqscIBynCI=.eb4b44e7-1fc0-4e78-9db3-f3cb02f1abdf@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

This pull request has been closed without being integrated.

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

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


From itakiguchi at openjdk.org  Tue Jun  6 15:27:31 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 6 Jun 2023 15:27:31 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
 [v2]
In-Reply-To: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
Message-ID: <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>

> On AIX, lib/fontconfig.bfc file is used to find font setting.
> I ran SwingSet2 List demo program with AIX C locale.
> JDK21's line spacing is larger then JDK17.
> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
> 
> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
> `native.encoding` system property has platform's encoding/charset name.
> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
> 
> Additionally, following parts are changed:
> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
> For Java for AIX:
> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
> 
> In my understanding, this fix affects just for AIX platform.
> 
> Note:
> macos-x64 tier1 test was failed, but I think it's not related this PR.

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

  8307953: [AIX] C locale's font setting was changed by JEP 400

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13937/files
  - new: https://git.openjdk.org/jdk/pull/13937/files/11b7a5b5..a0b93d2c

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

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

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


From jwaters at openjdk.org  Tue Jun  6 15:35:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:35:54 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <Tr4bbWlv0NVEHELiiSTIIsa1crkOHGJYnpTDC241c2w=.a9cdf84d-6b7b-46b8-afd7-9bec16aee50d@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1578993777


From jwaters at openjdk.org  Tue Jun  6 15:36:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:36:57 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <fSmXqAalXkTcaUM-z0su0bQU-GtFIdKjPWplUQaWfXk=.8ae45ca6-6d0f-40c0-b27a-63034f4289c3@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1578995624


From itakiguchi at openjdk.org  Tue Jun  6 15:42:53 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 6 Jun 2023 15:42:53 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
 [v2]
In-Reply-To: <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
 <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
Message-ID: <r74b_L-pn_wc6oL0b0b0BW8OztXPfjGMTRLcdf61ro8=.c34c4dba-1617-4951-aee9-b012042d7a08@github.com>

On Tue, 6 Jun 2023 15:27:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On AIX, lib/fontconfig.bfc file is used to find font setting.
>> I ran SwingSet2 List demo program with AIX C locale.
>> JDK21's line spacing is larger then JDK17.
>> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
>> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
>> 
>> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
>> `native.encoding` system property has platform's encoding/charset name.
>> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
>> 
>> Additionally, following parts are changed:
>> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
>> For Java for AIX:
>> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
>> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
>> 
>> In my understanding, this fix affects just for AIX platform.
>> 
>> Note:
>> macos-x64 tier1 test was failed, but I think it's not related this PR.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307953: [AIX] C locale's font setting was changed by JEP 400

Thanks @prrace and @naotoj .
I appreciate your suggestions.
Now I only touched `src/java.desktop/aix/data/fontconfig/fontconfig.properties`
Could you review new change ?
Thanks in advance.

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

PR Comment: https://git.openjdk.org/jdk/pull/13937#issuecomment-1579005703


From aivanov at openjdk.org  Tue Jun  6 16:16:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 16:16:06 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll up/down
Message-ID: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>

**Problem description**

If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.

**Root cause**

AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.

When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.

**Fix**

To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.

An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

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

Commit messages:
 - 8297923: Automatic test for leaked GDI objects in ScrollPane
 - 8297923: Invoke SetScrollInfo and GetScrollInfo on toolkit thread

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

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


From aivanov at openjdk.org  Tue Jun  6 16:16:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 16:16:07 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <MapP6RG02Kkmow9FzeK40lwRhsgxDaFB1oXI_MO3Hwk=.e3b4709a-0f26-4470-9e88-ba5547a3c8b4@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

The screenshot of the test case after the problem is reproduced:

![ScrollPaneTest](https://github.com/openjdk/jdk/assets/70774172/acdaa2e3-b123-448b-8145-47335c7f4d39)

If you scroll up or down, the left side of the frame gets filled with the light-green color of the canvas which is the child component inside the scroll pane.

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1579061086


From jiangli at openjdk.org  Tue Jun  6 16:28:59 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 Jun 2023 16:28:59 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v5]
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <4U4zG-gKBcankqMtYc3p1EEuHrQ-_AvyS6J_P4Gww50=.88fd8d13-3f4f-46d6-9049-4371a3755bb1@github.com>

On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make/common/NativeCompilation.gmk
>>   
>>   Thanks you!
>>   
>>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.
> 
> 
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
> [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
> [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1

Thanks for running tests!!

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1555291522


From asemenov at openjdk.org  Tue Jun  6 17:35:34 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 6 Jun 2023 17:35:34 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
Message-ID: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>

On Thu, 1 Jun 2023 15:04:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> done
>
> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

This is rarely used in the code and is not the essence of the current changes.
If you introduce such changes, then throughout the code.
Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220056527


From weijun at openjdk.org  Tue Jun  6 17:50:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jun 2023 17:50:00 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
Message-ID: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>

On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.
>
> This is rarely used in the code and is not the essence of the current changes.
> If you introduce such changes, then throughout the code.
> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220071779


From prr at openjdk.org  Tue Jun  6 18:22:02 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 18:22:02 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 704:

> 702:     gos->orient = orient;
> 703: 
> 704:     return static_cast<jint>(reinterpret_cast<INT_PTR>(AwtToolkit::GetInstance().InvokeFunction(

So this needs to block until the toolkit thread can process this and return, but since its
directly called from Java (ie we are in a JNI method) I think this is likely fine.

src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 745:

> 743:     ssps->y = y;
> 744: 
> 745:     AwtToolkit::GetInstance().InvokeFunctionLater(AwtScrollPane::_SetScrollPos, ssps);

Whereas in the _GetOffset case above, you clearly need to wait until the result is returned - I guess
you didn't see a need to block here ? Or the case below ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220105799
PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220107433


From aivanov at openjdk.org  Tue Jun  6 18:24:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 18:24:54 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
Message-ID: <lXEOqOmdDPkgTcGEDkqhGcnog0uBl8dCKuVmchiy1sQ=.4da80c81-b096-42ab-8082-7b84d965e317@github.com>

On Tue, 6 Jun 2023 18:17:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> **Problem description**
>> 
>> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
>> 
>> **Root cause**
>> 
>> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
>> 
>> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
>> 
>> **Fix**
>> 
>> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
>> 
>> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.
>
> src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 704:
> 
>> 702:     gos->orient = orient;
>> 703: 
>> 704:     return static_cast<jint>(reinterpret_cast<INT_PTR>(AwtToolkit::GetInstance().InvokeFunction(
> 
> So this needs to block until the toolkit thread can process this and return, but since its
> directly called from Java (ie we are in a JNI method) I think this is likely fine.

That's right.

In addition to that, `WScrollPanePeer.getScrollOffset` is unused, so it's never called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220111236


From aivanov at openjdk.org  Tue Jun  6 18:48:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 18:48:00 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <uOz4MfweMNLeby6YGlTCsdVtWWlDE1MIPgp-6UefQHA=.69f1e0aa-cfce-489a-b410-cddae8dfc3ad@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
 <uOz4MfweMNLeby6YGlTCsdVtWWlDE1MIPgp-6UefQHA=.69f1e0aa-cfce-489a-b410-cddae8dfc3ad@github.com>
Message-ID: <e3EqCUJcvKAKf0Xz8_fyP-2mExnrM_vidNv66QdRuuY=.e348c4c7-bf5c-4ae3-a34f-2017e51fa7e6@github.com>

On Tue, 6 Jun 2023 18:38:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 745:
>> 
>>> 743:     ssps->y = y;
>>> 744: 
>>> 745:     AwtToolkit::GetInstance().InvokeFunctionLater(AwtScrollPane::_SetScrollPos, ssps);
>> 
>> Whereas in the _GetOffset case above, you clearly need to wait until the result is returned - I guess
>> you didn't see a need to block here ? Or the case below ?
>
> I had a similar clarification as to why it was `InvokeFunction` for `_getOffset` and `InvokeFunctionLater` for `_SetScrollPos` and `_SetSpans`. The above discussion makes it clear.

No, there's no need to wait, and no result is returned.

Java has updated the position of the child component based on the new position of the scroll bar. Now the position of the non-client scroll bars of the scroll pane window need to be updated.

The `_SetSpans` recalculates the position and range of the scroll bars if the size of the scroll pane or its child component changes. The changes are already handled on the Java side, these changes need to be reflected in the scroll bars.

I have found no scenario where we need to block EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220141017


From honkar at openjdk.org  Tue Jun  6 18:47:59 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 18:47:59 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
Message-ID: <uOz4MfweMNLeby6YGlTCsdVtWWlDE1MIPgp-6UefQHA=.69f1e0aa-cfce-489a-b410-cddae8dfc3ad@github.com>

On Tue, 6 Jun 2023 18:19:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> **Problem description**
>> 
>> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
>> 
>> **Root cause**
>> 
>> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
>> 
>> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
>> 
>> **Fix**
>> 
>> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
>> 
>> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.
>
> src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 745:
> 
>> 743:     ssps->y = y;
>> 744: 
>> 745:     AwtToolkit::GetInstance().InvokeFunctionLater(AwtScrollPane::_SetScrollPos, ssps);
> 
> Whereas in the _GetOffset case above, you clearly need to wait until the result is returned - I guess
> you didn't see a need to block here ? Or the case below ?

I had a similar clarification as to why it was `InvokeFunction` for `_getOffset` and `InvokeFunctionLater` for `_SetScrollPos` and `_SetSpans`. The above discussion makes it clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220134013


From honkar at openjdk.org  Tue Jun  6 18:47:55 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 18:47:55 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <wcSmJNQ19MFPTgXQQL7cTTs5eVRjJWK9RCXqVHBulNQ=.c87d8ca8-0e56-431a-b40b-6492ebb926a1@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

> The screenshot of the test case after the problem is reproduced:
> 
> ![ScrollPaneTest](https://user-images.githubusercontent.com/70774172/243736214-acdaa2e3-b123-448b-8145-47335c7f4d39.png)
> 
> If you scroll up or down, the left side of the frame gets filled with the light-green color of the canvas which is the child component inside the scroll pane.

Test works as expected with the fix. 
Without the fix, OutOfMemory exception is thrown as described.
When running the test without the fix, I had to introduce a small delay after the frame is maximized again to see the light-green block outside the canvas.

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

PR Review: https://git.openjdk.org/jdk/pull/14338#pullrequestreview-1465843842


From aivanov at openjdk.org  Tue Jun  6 18:52:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 18:52:55 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <wcSmJNQ19MFPTgXQQL7cTTs5eVRjJWK9RCXqVHBulNQ=.c87d8ca8-0e56-431a-b40b-6492ebb926a1@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <wcSmJNQ19MFPTgXQQL7cTTs5eVRjJWK9RCXqVHBulNQ=.c87d8ca8-0e56-431a-b40b-6492ebb926a1@github.com>
Message-ID: <R2VKqHCUhX-nzmAXJbc8RT1sTbrvgjCGlk0Ai5uGt3Q=.75083265-dff0-4627-9a47-e50a62b78294@github.com>

On Tue, 6 Jun 2023 18:38:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> When running the test without the fix, I had to introduce a small delay after the frame is maximized again to see the light-green block outside the canvas.

You can use the test case attached to [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `ScrollPaneTest.java`, to play around. Alternatively, you can comment out disposing of the frame in the automatic test.

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1579284557


From naoto at openjdk.org  Tue Jun  6 19:56:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Jun 2023 19:56:55 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
 [v2]
In-Reply-To: <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
 <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
Message-ID: <1XRixnEped1sYBd7uPqqltgOPfDVT-T3UUxNlSJBKNg=.5d43ef0f-a298-49f5-a94e-d95e34ef7d30@github.com>

On Tue, 6 Jun 2023 15:27:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On AIX, lib/fontconfig.bfc file is used to find font setting.
>> I ran SwingSet2 List demo program with AIX C locale.
>> JDK21's line spacing is larger then JDK17.
>> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
>> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
>> 
>> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
>> `native.encoding` system property has platform's encoding/charset name.
>> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
>> 
>> Additionally, following parts are changed:
>> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
>> For Java for AIX:
>> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
>> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
>> 
>> In my understanding, this fix affects just for AIX platform.
>> 
>> Note:
>> macos-x64 tier1 test was failed, but I think it's not related this PR.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307953: [AIX] C locale's font setting was changed by JEP 400

The part reverting the encoding looks good to me. I defer the other part review for client team.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13937#pullrequestreview-1465968534


From prr at openjdk.org  Tue Jun  6 20:06:59 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 20:06:59 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
 [v2]
In-Reply-To: <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
 <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
Message-ID: <gIU38RjTwI27QOhXnnOrPXmkNceuaODsafgPtQWP5-o=.a033dbbc-efa8-4333-bbb6-bd874e642785@github.com>

On Tue, 6 Jun 2023 15:27:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On AIX, lib/fontconfig.bfc file is used to find font setting.
>> I ran SwingSet2 List demo program with AIX C locale.
>> JDK21's line spacing is larger then JDK17.
>> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
>> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
>> 
>> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
>> `native.encoding` system property has platform's encoding/charset name.
>> If platform's charset name is not supported by Java, charset name should be `UTF-8`.
>> 
>> Additionally, following parts are changed:
>> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
>> For Java for AIX:
>> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
>> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
>> 
>> In my understanding, this fix affects just for AIX platform.
>> 
>> Note:
>> macos-x64 tier1 test was failed, but I think it's not related this PR.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307953: [AIX] C locale's font setting was changed by JEP 400

I'm  happy to approve the remaining change but quite honestly I'm ignorant of IBM encodings on AIX so all I can say is that its fine by me if its fine by the AIX port maintainers

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13937#pullrequestreview-1465987358


From aivanov at openjdk.org  Tue Jun  6 20:14:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 20:14:16 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v9]
In-Reply-To: <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <7FGZUgiUvyNJLB5By94ht_R80sE_qd-i1ZGIBn96-18=.f2e60641-194e-4728-99e9-8bc95b23095a@github.com>
Message-ID: <-U51f0nQ-C5zB27t5eLwJu_6QpC035VYp2q00naJ3xE=.35f35607-9960-4bc8-baef-9325b1d64189@github.com>

On Thu, 1 Jun 2023 19:56:28 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling values of  up-to 350%.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code changes as per code review

Overall, it looks good to me except for minor (stylistic) comments.

Please update the copyright year in the modified files.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 84:

> 82: import sun.swing.CachedPainter;
> 83: 
> 84: import java.awt.geom.AffineTransform;

The import for `AffineTransform` is out of place, it should be above with other `java.awt.*` classes. Its place is between `Toolkit` and `BufferedImage`.


import java.awt.Toolkit;
import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 48:

> 46:     private static final int defaultDPI = 96;
> 47:     private static final Map<Integer, Map<String, Long>> dpiAwareWidgetToTheme
> 48:             = new HashMap<Integer, Map<String, Long>>();

Suggestion:

    private static final Map<Integer, Map<String, Long>> dpiAwareWidgetToTheme
            = new HashMap<>();

You can use the diamond operator, that is drop the type parameters when invoking the constructor.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 131:

> 129:         }
> 130: 
> 131:         // mostly copied from the javadoc for ReentrantReadWriteLock

This comment belongs before  `if (theme == null)`, it explains how it switches between read- and write-locks.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 136:

> 134:         Map<String, Long> dpiWidgetToTheme = dpiAwareWidgetToTheme.get(dpi);
> 135: 
> 136:         if (dpiWidgetToTheme != null) {

Is `widgetToTheme` a better name? You already resolved the dpi-aware part.

I'd remove the blank line between the initialiser and null-check, they're tightly related.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 155:

> 153:     private static native void paintBackground(int[] buffer, long theme,
> 154:                                                int part, int state, int rectRight,
> 155:                                                int rectBottom, int w, int h, int stride);

Mostly stylistic change, yet it could make parsing the list of parameters easier:
Suggestion:

                                               int part, int state,
                                               int rectRight, int rectBottom,
                                               int w, int h, int stride);

Perhaps, wrap `stride` to the next line too.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 165:

> 163:             Dimension d = getPartSize(getTheme(widget, dpi), part, state);
> 164:             paintBackground(buffer, getTheme(widget, dpi), part, state,
> 165:                             d.width, d.height , w, h, stride);

Drop the extra space:
Suggestion:

                            d.width, d.height, w, h, stride);

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 321:

> 319:             return getThemeBackgroundContentMargins(getTheme(widget, defaultDPI),
> 320:                                                     part, state, boundingWidth,
> 321:                                                     boundingHeight);

I suggest keeping both `boundingWidth` and `boundingHeight` on the same line.
Suggestion:

            return getThemeBackgroundContentMargins(getTheme(widget, defaultDPI),
                                                    part, state,
                                                    boundingWidth, boundingHeight);

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 43:

> 41: #define GREEN_SHIFT 8
> 42: 
> 43: 

Perhaps, keep this blank line?

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 178:

> 176:               HTHEME hTheme = OpenThemeDataFuncForDpi (
> 177:                               AwtToolkit::GetInstance().GetHWnd(),
> 178:                               L"Button", dpi);

Suggestion:

              // We need to make sure we can load the Theme.
              // Use the default DPI value of 96 on windows.
              unsigned int dpi = 96;
              HTHEME hTheme = OpenThemeDataFuncForDpi(
                              AwtToolkit::GetInstance().GetHWnd(),
                              L"Button", dpi);

Does it make sense to rename `dpi` to `defaultDPI` like it's done on the Java side.

Can we mark the `dpi` variable with [`constexpr`](https://en.cppreference.com/w/cpp/language/constexpr) specifier? It's available since C++11, I believe Java currently uses C++17, so this specifier can be used.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 433:

> 431:     rect.bottom = rectBottom;
> 432:     rect.right = rectRight;
> 433: 

Perhaps, the newly added blank is redundant here.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1465903474
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220183481
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220194871
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220206910
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220201870
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220214137
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220214805
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220220319
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220229355
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220239818
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220247503


From aivanov at openjdk.org  Tue Jun  6 20:14:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Jun 2023 20:14:16 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v9]
In-Reply-To: <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
Message-ID: <8TqooRFR2DX9q8iw2wgfrXa5XfWcB_2ZIRACYMY9WXY=.31f365b4-e739-4ade-bf86-c0ebec4c886f@github.com>

On Tue, 2 May 2023 15:27:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code changes as per code review
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 243:
> 
>> 241: (JNIEnv* env, jclass klass, jstring widget, jint dpi) {
>> 242: 
>> 243:     LPCTSTR str = (LPCTSTR)JNU_GetStringPlatformChars(env, widget, NULL);
> 
> I'd rather keep the original formatting for casts as well as for `JNIEnv *env` in the declaration.

This isn't fully resolved: the space between the type and the expression should be preserved on lines 243 and 254 (in the updated version).


LPCTSTR str = (LPCTSTR) JNU_GetStringPlatformChars(env, widget, NULL);
return (jlong) htheme;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1220245608


From prr at openjdk.org  Tue Jun  6 21:02:54 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 21:02:54 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <lexLKC1Z4dMqtUEGJ1L3RdwHl9_0LjzYt3rfiajD6q4=.b9063efa-8a42-490c-8152-43d7a33911e1@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

Marked as reviewed by prr (Reviewer).

I wonder if we have any other leaks due to similar thread mis-usage ?
Seems possible since this one went un-detected for a long time and its
probably one of the easier ones to get to run out of GDI objects.

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

PR Review: https://git.openjdk.org/jdk/pull/14338#pullrequestreview-1466104586
PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1579444927


From rmahajan at openjdk.org  Tue Jun  6 22:07:20 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 6 Jun 2023 22:07:20 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v10]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <lpJzWuqZK2ISbClbKR4MB0ZRF1PHhqGqqQ9aObRD7Po=.a178df0f-bbe7-4faf-9cc7-997d3449e384@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/7a2a2a40..7058250e

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

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

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


From itakiguchi at openjdk.org  Tue Jun  6 22:23:06 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 6 Jun 2023 22:23:06 GMT
Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400
 [v2]
In-Reply-To: <gIU38RjTwI27QOhXnnOrPXmkNceuaODsafgPtQWP5-o=.a033dbbc-efa8-4333-bbb6-bd874e642785@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
 <PPWVZUimbGcEDZiDhvB2ZMBT9BZEOVC0Z_fr6m6-1A0=.f04e3323-d0f2-4b8e-b538-a16b673e9286@github.com>
 <gIU38RjTwI27QOhXnnOrPXmkNceuaODsafgPtQWP5-o=.a033dbbc-efa8-4333-bbb6-bd874e642785@github.com>
Message-ID: <YAg-6750CVfA_i5U9orCRL8Toh0o-zUvEuVf7wh4C0I=.d686a915-4b88-4dd5-82df-a76aee82e1f4@github.com>

On Tue, 6 Jun 2023 20:03:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8307953: [AIX] C locale's font setting was changed by JEP 400
>
> I'm  happy to approve the remaining change but quite honestly I'm ignorant of IBM encodings on AIX so all I can say is that its fine by me if its fine by the AIX port maintainers

Thanks @prrace and @naotoj .
The description was updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/13937#issuecomment-1579530848


From itakiguchi at openjdk.org  Tue Jun  6 22:23:07 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 6 Jun 2023 22:23:07 GMT
Subject: Integrated: 8307953: [AIX] C locale's font setting was changed by JEP
 400
In-Reply-To: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
References: <mHS2Ek-PjcNhHtooIRgBry4XQsumQydc2J71tVRfDQg=.f68b3925-b42a-4db8-877d-39e15b8b0247@github.com>
Message-ID: <bL90aWDESNSHIaIqSSt06qoFCk0GzxUj8UdhDcSJrXA=.553ccf53-5481-484f-a1de-e209e0ba1105@github.com>

On Thu, 11 May 2023 18:23:45 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX, lib/fontconfig.bfc file is used to find font setting.
> I ran SwingSet2 List demo program with AIX C locale.
> JDK21's line spacing is larger then JDK17.
> Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953).
> When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected.
> 
> This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default.
> According to following URL
> https://docs.oracle.com/en/java/javase/20/intl/font-configuration-files.html
> 
>> Encoding - the canonical name of the default encoding, as provided by java.nio.charset.Charset.defaultCharset().name().
> 
> For C and POSIX locale, following entry is added into `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`
> 
> sequence.allfonts.UTF-8.en.=latin-1
> 
> 
> Additionally, following parts are changed:
> `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name.
> For Java for AIX:
> - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`.
> - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`.
> 
> In my understanding, this fix affects just for AIX platform.
> 
> Note:
> macos-x64 tier1 test was failed, but I think it's not related this PR.

This pull request has now been integrated.

Changeset: a08c5cb3
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a08c5cb3f1be7a20c8f955951d1605bb8b1c1aa4
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8307953: [AIX] C locale's font setting was changed by JEP 400

Reviewed-by: naoto, prr

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

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


From prr at openjdk.org  Tue Jun  6 22:34:04 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 22:34:04 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
Message-ID: <PFEApieGh6R4MHLi1MTzjx5vPrdHdv0nqJJb2WttfTc=.1307b820-2d79-4f8e-bbc7-d78353a24404@github.com>

On Fri, 2 Jun 2023 08:12:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimization removed to use local variables for non-percentage units

Please confirm this test (and all other relevant tests) still pass.
Approving in anticipation of confirmation of the above.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1466236272


From prr at openjdk.org  Tue Jun  6 22:37:00 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 22:37:00 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
Message-ID: <nxPxvV4LavBphc2f7PCnXOkOL2rO-2tBz__abUs-zgg=.195c7b8c-28b9-4bdc-98c3-9df616da338e@github.com>

On Fri, 2 Jun 2023 19:35:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2022, Oracle and/or its affiliates. All rights reserved.

2022 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1220480456


From prr at openjdk.org  Tue Jun  6 22:45:16 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Jun 2023 22:45:16 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
Message-ID: <vkzhPa6ucV0HZToSdHzug3pEU72oJw1NDeS61uao3Qw=.45b65cc8-35fc-4cc3-bf25-69c1e34558b8@github.com>

On Fri, 2 Jun 2023 19:35:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

test/jdk/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java line 164:

> 162:         OverlappingTestBase.doMain(args);
> 163:         captureScreen("Img_5.png");
> 164:     }

It is just a test, so no need to over-engineer it but  it 'feels wrong' to specify the file name
as foo.png here and separately inside captureScreen choose 'png' as the file type to use.
Perhaps  captureScreen("Img_5.png", "png")  ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1220488055


From honkar at openjdk.org  Tue Jun  6 22:45:15 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 22:45:15 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v3]
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <slLouzdiImYeGfXuWKQJyYdMI2EXzzdKMI0hdPPi7gM=.cba2508e-876d-4b9f-89ab-ed2da8b37f27@github.com>

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:

 - updated year
 - spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14289/files
  - new: https://git.openjdk.org/jdk/pull/14289/files/b3bff669..cab078a9

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

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

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


From honkar at openjdk.org  Tue Jun  6 23:00:34 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 23:00:34 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v4]
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <_iIBTyBya4z8H4yUYb2TCqeUFRiln6ZQpdJYSmtJNRk=.81c85ec8-ae6e-48f5-83ea-03f109a417d5@github.com>

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

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

  file format added as parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14289/files
  - new: https://git.openjdk.org/jdk/pull/14289/files/cab078a9..86454670

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

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

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


From honkar at openjdk.org  Tue Jun  6 23:00:34 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 23:00:34 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <nxPxvV4LavBphc2f7PCnXOkOL2rO-2tBz__abUs-zgg=.195c7b8c-28b9-4bdc-98c3-9df616da338e@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
 <nxPxvV4LavBphc2f7PCnXOkOL2rO-2tBz__abUs-zgg=.195c7b8c-28b9-4bdc-98c3-9df616da338e@github.com>
Message-ID: <gy_St0f-ert6CgqILClIQQDya3tYa_XY-bLN93DXGtE=.9f3c2283-1dba-4cba-8de1-1e1a861863dd@github.com>

On Tue, 6 Jun 2023 22:34:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review fix
>
> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2014, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> 2022 ?

This was by miss :) 
Updated to 2023

> test/jdk/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java line 164:
> 
>> 162:         OverlappingTestBase.doMain(args);
>> 163:         captureScreen("Img_5.png");
>> 164:     }
> 
> It is just a test, so no need to over-engineer it but  it 'feels wrong' to specify the file name
> as foo.png here and separately inside captureScreen choose 'png' as the file type to use.
> Perhaps  captureScreen("Img_5.png", "png")  ?

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1220502248
PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1220502673


From honkar at openjdk.org  Tue Jun  6 23:00:54 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Jun 2023 23:00:54 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <2ZxgX4pumZeyQonbfP8xGF9vbX1CvrWmGdEsos0eim8=.c992d709-343f-4ae2-b808-b569b21999c2@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

Marked as reviewed by honkar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14338#pullrequestreview-1466267463


From azvegint at openjdk.org  Wed Jun  7 01:02:05 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 01:02:05 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v2]
In-Reply-To: <nkYs6F_gg8mRxvov3m54wot7sBPQAksRg-qrARudu3Y=.77da6e1e-aaca-4112-8b70-cd14de8259b5@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <nkYs6F_gg8mRxvov3m54wot7sBPQAksRg-qrARudu3Y=.77da6e1e-aaca-4112-8b70-cd14de8259b5@github.com>
Message-ID: <glrh3f1NvaEA-xeSpZgDdcTBDrOGboWNU_AbCAuN6j8=.4e1054f8-0fd7-44ec-b48b-6e5eec7bbdfe@github.com>

On Mon, 5 Jun 2023 16:36:42 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated fix

test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java line 30:

> 28:   @summary Tests that GraphicsConfig for invisible (peerless) windows is
> 29:            updated after showing the window
> 30:   @requires os.family == "windows"

Why are we making it windows only?
It passes on macos and on linux for me.

Could you be more specific about what kind of regression you are seeing on Linux?

test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 61:

> 59:         GraphicsDevice[] gds = ge.getScreenDevices();
> 60: 
> 61:         if (gds.length != 2) {

Shouldn't it be `> 1`? 
To perform the test when 2 or more screens are present.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1220388842
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1220620247


From azvegint at openjdk.org  Wed Jun  7 01:02:07 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 01:02:07 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v2]
In-Reply-To: <NXx9NLRvYxnLsR4ztpFkvHvCVMfk1ym4abkhtYaMJqU=.c2d74763-ee49-44b1-8d89-1fa93c481796@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <Tjrg2NkxXGu9gLNxgA3Mg9il8v2M6VMlV7eHZBSS_MY=.dddf09f0-86f0-424e-964b-928db3250eed@github.com>
 <RybBC2gdplwOwwYORuGj-VJ3Yt69urjc6TP8SEBcWsk=.d39c4a6a-94e4-48b6-99d0-0b9500cec31d@github.com>
 <S4l1gynuMqNfjsRzhhqN2ZDCHOyRVk9bsaGKFwbFesY=.4d66b1e9-7cb7-4d71-b973-9c3dc354257a@github.com>
 <YwNbNsYscGUvtsAM5BbpHrQw9Xb7K7BORLrI7aaexx8=.e66a38f1-1a28-4e7a-a8f8-ff155a21d04d@github.com>
 <jXWQ5ZrOCcI54cMEXMknqZefCKre0iuUxYr3WnRZ6SU=.d87231f4-4052-47b4-9a24-2eadb70aa5af@github.com>
 <NXx9NLRvYxnLsR4ztpFkvHvCVMfk1ym4abkhtYaMJqU=.c2d74763-ee49-44b1-8d89-1fa93c481796@github.com>
Message-ID: <CtcLwlyjzkZkd0so2rUbBIAje-30v-mcZngpAeKwmGU=.262386ad-f3cf-4410-80df-d35c76a0b1a9@github.com>

On Mon, 5 Jun 2023 15:34:46 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I see the difference. Also, I looked back on other fixes that I recall were expanded to be generic, and I see my source of confusion. LAF's were expanded, not tested OS's.
>
> Yeah, so as @azvegint suggested I will update the fix. And also I will update the regression test to windows alone.

I just did a quick test on Windows and macos, this test seems to work.
(However, line 136 should be removed to show the translucent window on macos).

Therefore, we may consider doing a test not only for Linux.

BTW, It may be better to put this test in test/jdk/java/awt/Multiscreen/, where most of multiscreen tests are located.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1220604310


From azvegint at openjdk.org  Wed Jun  7 01:27:50 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 01:27:50 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
Message-ID: <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>

> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
> 
> But this functionality is a very important part of automated testing.
> 
> 
> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
> 
> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
> It has several drawbacks though:
> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
> + There is no way to disable the visual "screen flash" after screenshot
> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
> But we still can consider this option as a fallback.
> 
> 
> 
> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
> 
> + implementation is more complicated comparing to Screenshot API
> + no intermediate file, screenshot data can be obtained from memory
> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
> 
> 
> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
> 
> This change also introduces some new behavior for the robot:
> A system window now appears asking for confirmation from the user to capture the screen.
> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
> + The user can allow a screen capture for all screens or some of them. For screens witho...

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - move screencast-tokens.properties to a new location
 - fix failure of javax/swing/reliability/HangDuringStaticInitialization.java in headless environment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13803/files
  - new: https://git.openjdk.org/jdk/pull/13803/files/63b34b9d..f5579309

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

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

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


From serb at openjdk.org  Wed Jun  7 03:33:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 03:33:59 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <lXEOqOmdDPkgTcGEDkqhGcnog0uBl8dCKuVmchiy1sQ=.4da80c81-b096-42ab-8082-7b84d965e317@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
 <lXEOqOmdDPkgTcGEDkqhGcnog0uBl8dCKuVmchiy1sQ=.4da80c81-b096-42ab-8082-7b84d965e317@github.com>
Message-ID: <LwT-L8HehDfhsRlqk8Ml5gYxetESLidcOnITwql3lYA=.4a1fb7a2-c411-4641-9e53-545d72cda4d8@github.com>

On Tue, 6 Jun 2023 18:22:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 704:
>> 
>>> 702:     gos->orient = orient;
>>> 703: 
>>> 704:     return static_cast<jint>(reinterpret_cast<INT_PTR>(AwtToolkit::GetInstance().InvokeFunction(
>> 
>> So this needs to block until the toolkit thread can process this and return, but since its
>> directly called from Java (ie we are in a JNI method) I think this is likely fine.
>
> That's right.
> 
> In addition to that, `WScrollPanePeer.getScrollOffset` is unused, so it's never called.

If it is unused can we delete it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1220780190


From serb at openjdk.org  Wed Jun  7 03:46:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 03:46:53 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
Message-ID: <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>

On Fri, 2 Jun 2023 08:27:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
> 
> We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.

If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1579831928


From serb at openjdk.org  Wed Jun  7 04:11:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 04:11:51 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <a_DWs1aAiZ3-53ORLCVLyHdWsXwSSOnajDDfl_tM4-g=.ef164e87-d362-4f4b-8573-12517d0bc574@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

Probably we should update the Java_sun_awt_windows_WScrollbarPeer_setValues as well? it calls the SetScrollInfo

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1579851933


From tr at openjdk.org  Wed Jun  7 04:32:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 04:32:54 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v2]
In-Reply-To: <glrh3f1NvaEA-xeSpZgDdcTBDrOGboWNU_AbCAuN6j8=.4e1054f8-0fd7-44ec-b48b-6e5eec7bbdfe@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <nkYs6F_gg8mRxvov3m54wot7sBPQAksRg-qrARudu3Y=.77da6e1e-aaca-4112-8b70-cd14de8259b5@github.com>
 <glrh3f1NvaEA-xeSpZgDdcTBDrOGboWNU_AbCAuN6j8=.4e1054f8-0fd7-44ec-b48b-6e5eec7bbdfe@github.com>
Message-ID: <Owpj2b5cWWPvBnd92UUKSnV2t8r9-LtUkTZEFN_PrU8=.ded2bcf6-b516-461e-894f-ccc0edc9ad8b@github.com>

On Tue, 6 Jun 2023 21:26:31 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated fix
>
> test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java line 30:
> 
>> 28:   @summary Tests that GraphicsConfig for invisible (peerless) windows is
>> 29:            updated after showing the window
>> 30:   @requires os.family == "windows"
> 
> Why are we making it windows only?
> It passes on macos and on linux for me.
> 
> Could you be more specific about what kind of regression you are seeing on Linux?

Strange, it passes for me too with recent fix. Maybe I messed up with previous fix while testing in linux machine. Will revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1220826908


From tr at openjdk.org  Wed Jun  7 04:48:41 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 04:48:41 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v3]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <0U4o0wDAMN2XQi-fGvnSmjT9r2iQ_OZgOXLHbSDrig0=.a35a7c74-dcad-4670-8de6-775455529f30@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/47912757..45ff7b2f

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

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

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


From tr at openjdk.org  Wed Jun  7 04:48:44 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 04:48:44 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v2]
In-Reply-To: <glrh3f1NvaEA-xeSpZgDdcTBDrOGboWNU_AbCAuN6j8=.4e1054f8-0fd7-44ec-b48b-6e5eec7bbdfe@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <nkYs6F_gg8mRxvov3m54wot7sBPQAksRg-qrARudu3Y=.77da6e1e-aaca-4112-8b70-cd14de8259b5@github.com>
 <glrh3f1NvaEA-xeSpZgDdcTBDrOGboWNU_AbCAuN6j8=.4e1054f8-0fd7-44ec-b48b-6e5eec7bbdfe@github.com>
Message-ID: <qHDh9HV-8OP2_8nbPmdpXM-i6UOIUmWiVHs5w5y2XSk=.8384d084-c598-402a-8a38-51eb5a67d29e@github.com>

On Wed, 7 Jun 2023 00:56:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated fix
>
> test/jdk/java/awt/Window/MultiscreenTransparencyTest.java line 61:
> 
>> 59:         GraphicsDevice[] gds = ge.getScreenDevices();
>> 60: 
>> 61:         if (gds.length != 2) {
> 
> Shouldn't it be `> 1`? 
> To perform the test when 2 or more screens are present.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1220833388


From tr at openjdk.org  Wed Jun  7 05:00:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 05:00:54 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
Message-ID: <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>

On Wed, 7 Jun 2023 03:43:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
> > 
> > 
> > We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.
> 
> If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?

In Window, GC is set when during initialization, i.e., `initGC()` is called, also there is separate `setGraphicsConfiguration() ` method. But unlike `Canvas.setGraphicsConfiguration()`, in window `getAppropriateGraphicsConfiguration()` is not used. So with Window, unlike Canvas setting a GC is quite different and doesn't involve  `getAppropriateGraphicsConfiguration()` I hope.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1579887971


From psadhukhan at openjdk.org  Wed Jun  7 05:28:16 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Jun 2023 05:28:16 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
Message-ID: <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>

On Wed, 7 Jun 2023 01:27:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move screencast-tokens.properties to a new location
>  - fix failure of javax/swing/reliability/HangDuringStaticInitialization.java in headless environment

Mostly alignment issue with couple of code comments..

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 53:

> 51: 
> 52:         tryGtk = Boolean.parseBoolean(
> 53:                 AccessController.doPrivileged(

Code formatting..better to align `AccessController `below `Boolean`

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 69:

> 67:                         isOnWayland
> 68:                                 ? METHOD_SCREENCAST
> 69:                                 : METHOD_X11

code alignment issue...will look better if all starts in same column

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 126:

> 124:         int[] pixelArray = new int[1];
> 125:         if (screenshotMethod.equals(METHOD_SCREENCAST)
> 126:                 && ScreencastHelper.isAvailable()) {

align `&&`  below `screenshotMethod`

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 138:

> 136:         int[] pixelArray = new int[bounds.width * bounds.height];
> 137:         if (screenshotMethod.equals(METHOD_SCREENCAST)
> 138:                 && ScreencastHelper.isAvailable()) {

same here

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 142:

> 140:                     bounds.x, bounds.y,
> 141:                     bounds.width, bounds.height,
> 142:                     pixelArray

you can align below the brace ( as it will not cross 80 chars, I believe

src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 150:

> 148:                     bounds.width, bounds.height,
> 149:                     pixelArray, useGtk
> 150:             );

same here

src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 63:

> 61:         SCREENCAST_DEBUG = Boolean.parseBoolean(
> 62:                 AccessController.doPrivileged(
> 63:                         new GetPropertyAction(

align AccessController below Boolean

src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 72:

> 70: 
> 71:         if (!(Toolkit.getDefaultToolkit()
> 72:                 instanceof UNIXToolkit tk && tk.loadGTK())

I guess better to move `Toolkit.getDefaultToolkit() instance UNIXToolkit tk` in same line and align `&& `below Toolkit

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 145:

> 143:                     path,
> 144:                     Set.of(PosixFilePermission.OWNER_READ,
> 145:                             PosixFilePermission.OWNER_WRITE)

alignment issue..Posix..OWNER_WRITE should be placed below Posix..OENER_READ

Also, why we aren't adding OWNER_EXECUTE here too like done above?

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 316:

> 314:             allTokenItems = PROPS.entrySet()
> 315:                     .stream()
> 316:                     .map(o -> {

align below PROPS

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 335:

> 333:             if (tokenItem != null
> 334:                     && tokenItem
> 335:                     .hasAllScreensWithExactMatch(affectedScreenBounds)) {

align below `tokenItem`

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 350:

> 348:                 .map(rectangle -> new Dimension(
> 349:                         rectangle.width,
> 350:                         rectangle.height

align below `affectedScreenBounds`

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 356:

> 354:         for (TokenItem tokenItem : allTokenItems) {
> 355:             if (tokenItem != null
> 356:                     && tokenItem.hasAllScreensOfSameSize(dimensions)) {

align below `tokenItem`

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 371:

> 369:         if (!isWritable()
> 370:                 || malformedRecords == null
> 371:                 || malformedRecords.isEmpty()) {

align below `isWritable`

src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 406:

> 404:     private static boolean isWritable() {
> 405:         if (PROPS_PATH == null
> 406:                 || (Files.exists(PROPS_PATH) && !Files.isWritable(PROPS_PATH))) {

align below PROPS_PATH

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h line 94:

> 92:   gint width;
> 93:   gint height;
> 94: } GdkRectangle;

Any reason why it is removed? I think it's needed in gtk2_interface.c, right? 
Probably we can delete from gtk3_interface.h as it is not used in gtk3_interface.c

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 674:

> 672:             EXCEPTION_CHECK_DESCRIBE();
> 673:             if (!allowedBounds) {
> 674:                 (*env)->ExceptionClear(env);

I guess as mentioned above, DESCRIBE clears exception also so no need of calling  explicit Clear
https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 694:

> 692:                 if ((*env)->ExceptionCheck(env)) {
> 693:                     (*env)->ExceptionDescribe(env);
> 694:                     (*env)->ExceptionClear(env);

same here

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1466590673
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220836005
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220836075
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220836350
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220836410
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220837445
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220837512
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220838239
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220839222
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220853099
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220853881
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220854061
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220854228
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220854400
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220854551
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220854760
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220857001
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220864748
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220865107


From prr at openjdk.org  Wed Jun  7 05:44:04 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 Jun 2023 05:44:04 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
 <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
Message-ID: <GvTWIWw5IobnKjZsZWWaycR841SjNB1wgV9BA-UoQJA=.4d59f9b3-88ea-495b-be5a-be55b5a3f82d@github.com>

On Wed, 7 Jun 2023 05:05:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move screencast-tokens.properties to a new location
>>  - fix failure of javax/swing/reliability/HangDuringStaticInitialization.java in headless environment
>
> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 145:
> 
>> 143:                     path,
>> 144:                     Set.of(PosixFilePermission.OWNER_READ,
>> 145:                             PosixFilePermission.OWNER_WRITE)
> 
> alignment issue..Posix..OWNER_WRITE should be placed below Posix..OENER_READ
> 
> Also, why we aren't adding OWNER_EXECUTE here too like done above?

Because execute is required on directories but not files unless they are programs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220882132


From psadhukhan at openjdk.org  Wed Jun  7 05:49:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Jun 2023 05:49:05 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
 <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
Message-ID: <9usL7shFdr0C_i3xhCxAjSq0JA1XL2jzM3MD0yEanjM=.36c1442e-d628-4b0b-ab7f-1c0b4f3a0d40@github.com>

On Wed, 7 Jun 2023 05:12:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move screencast-tokens.properties to a new location
>>  - fix failure of javax/swing/reliability/HangDuringStaticInitialization.java in headless environment
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h line 94:
> 
>> 92:   gint width;
>> 93:   gint height;
>> 94: } GdkRectangle;
> 
> Any reason why it is removed? I think it's needed in gtk2_interface.c, right? 
> Probably we can delete from gtk3_interface.h as it is not used in gtk3_interface.c

ok, I see it's used in screencast c file so moved to gtk_interface.h

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1220887351


From avu at openjdk.org  Wed Jun  7 07:00:59 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 7 Jun 2023 07:00:59 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
Message-ID: <u9aRCuCviWT1Fo5TU683Yn535tbzFEL6glx-Z1gMZAw=.1e9071f3-18ef-440d-80a7-c53fb627ca49@github.com>

On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by avu (Committer).

The latest changes look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1466776433
PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1580043192


From psadhukhan at openjdk.org  Wed Jun  7 07:04:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Jun 2023 07:04:31 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in Low
 Vision Theme
Message-ID: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>

In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically

![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)

It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
Icon width is made to be 24 in demo in sync with window title font size which made it work ok

![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

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

Commit messages:
 - 4516654: Metalworks Demo: Window title not displayed fully in Low Vision Theme

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

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


From tr at openjdk.org  Wed Jun  7 07:26:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 07:26:54 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
Message-ID: <dZFz3foC6pqwSrWeMOHsNea50_C6YEwSbbLQJtmW36w=.859accda-ece5-4c99-a5fc-f0ec8a5cc514@github.com>

On Wed, 7 Jun 2023 06:55:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
> 
> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

Still slight overlap is seen with windows (Display scaling 150%).
<img width="887" alt="MetalWork_24" src="https://github.com/openjdk/jdk/assets/94159358/d972786b-ce21-4b56-bc44-628ed2ed2ba6">

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1580087529


From tr at openjdk.org  Wed Jun  7 07:29:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Jun 2023 07:29:53 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
Message-ID: <vpJwhT0YHJD10AABOkMd-GpFfz5hv0i3MuvYTl2T_p4=.f3ba1477-1c3c-4deb-b17b-8ad9933daf2a@github.com>

On Wed, 7 Jun 2023 06:55:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
> 
> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

I applied the changes and observed that still some overlap is seen. Any additional properties settings are expected for this fix?

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

PR Review: https://git.openjdk.org/jdk/pull/14346#pullrequestreview-1466855132


From azvegint at openjdk.org  Wed Jun  7 10:36:19 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 10:36:19 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v12]
In-Reply-To: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
Message-ID: <auVxv04EYiFDlMm71gvri4HjAdKEcEK5dGiZouI6T_c=.66ac608d-eac4-47bc-ac5d-2aff24c38dd9@github.com>

> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
> 
> But this functionality is a very important part of automated testing.
> 
> 
> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
> 
> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
> It has several drawbacks though:
> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
> + There is no way to disable the visual "screen flash" after screenshot
> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
> But we still can consider this option as a fallback.
> 
> 
> 
> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
> 
> + implementation is more complicated comparing to Screenshot API
> + no intermediate file, screenshot data can be obtained from memory
> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
> 
> 
> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
> 
> This change also introduces some new behavior for the robot:
> A system window now appears asking for confirmation from the user to capture the screen.
> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
> + The user can allow a screen capture for all screens or some of them. For screens witho...

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

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13803/files
  - new: https://git.openjdk.org/jdk/pull/13803/files/f5579309..76c7bdd2

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

  Stats: 69 lines in 4 files changed: 5 ins; 16 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/13803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803

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


From azvegint at openjdk.org  Wed Jun  7 10:36:20 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 10:36:20 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
 <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
Message-ID: <PQyyGcYazTq8hRfkSPTjj5E3CbzACF7U9yTB5pjmYX8=.505ceeb6-5dc5-4056-b782-f831d4c68b26@github.com>

On Wed, 7 Jun 2023 04:44:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move screencast-tokens.properties to a new location
>>  - fix failure of javax/swing/reliability/HangDuringStaticInitialization.java in headless environment
>
> src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 53:
> 
>> 51: 
>> 52:         tryGtk = Boolean.parseBoolean(
>> 53:                 AccessController.doPrivileged(
> 
> Code formatting..better to align `AccessController `below `Boolean`

I moved a little, but with indent.
Compared to strictly under the Boolean, for my taste it is easier to quickly parse with the eyes, and it does not visually merge.

> src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java line 69:
> 
>> 67:                         isOnWayland
>> 68:                                 ? METHOD_SCREENCAST
>> 69:                                 : METHOD_X11
> 
> code alignment issue...will look better if all starts in same column

Same here.

> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 694:
> 
>> 692:                 if ((*env)->ExceptionCheck(env)) {
>> 693:                     (*env)->ExceptionDescribe(env);
>> 694:                     (*env)->ExceptionClear(env);
> 
> same here

Actually, these checks are not needed here at all, this is an oversight, there was a Java function call before.
The check after ReleaseIntArrayElements is also unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1221300355
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1221300633
PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1221337758


From azvegint at openjdk.org  Wed Jun  7 10:36:20 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 10:36:20 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v11]
In-Reply-To: <GvTWIWw5IobnKjZsZWWaycR841SjNB1wgV9BA-UoQJA=.4d59f9b3-88ea-495b-be5a-be55b5a3f82d@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <nTaA1QOIhvjgGO2dWPY1FMKvO55hxJH25twMHxUJR3o=.bfd2067c-2ddd-4577-ad88-56a5122c1ab4@github.com>
 <CWF7ZbaVzC_EIn_oT-u7vDTXYVA1a8U9u2y4R0hG1OQ=.c37fc09f-4624-4482-90df-a8dc022fcad6@github.com>
 <GvTWIWw5IobnKjZsZWWaycR841SjNB1wgV9BA-UoQJA=.4d59f9b3-88ea-495b-be5a-be55b5a3f82d@github.com>
Message-ID: <6g6ULilKRXmbV_naSWXArp8_arwOd-Hs86TWjoD5K3w=.919c82cf-53e2-416a-8d0c-7861ef693e0b@github.com>

On Wed, 7 Jun 2023 05:40:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 145:
>> 
>>> 143:                     path,
>>> 144:                     Set.of(PosixFilePermission.OWNER_READ,
>>> 145:                             PosixFilePermission.OWNER_WRITE)
>> 
>> alignment issue..Posix..OWNER_WRITE should be placed below Posix..OENER_READ
>> 
>> Also, why we aren't adding OWNER_EXECUTE here too like done above?
>
> Because execute is required on directories but not files unless they are programs.

Exactly, without an execute bit on the directory we cannot access/add/remove its files.

Our file is not a script or executable that needs to be run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1221327703


From aivanov at openjdk.org  Wed Jun  7 11:07:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 11:07:56 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <a_DWs1aAiZ3-53ORLCVLyHdWsXwSSOnajDDfl_tM4-g=.ef164e87-d362-4f4b-8573-12517d0bc574@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <a_DWs1aAiZ3-53ORLCVLyHdWsXwSSOnajDDfl_tM4-g=.ef164e87-d362-4f4b-8573-12517d0bc574@github.com>
Message-ID: <9xlnp3nIlGapuqN07_5ntYfL-EuafN14cgZ5IxWbbqY=.29b75970-3781-4d8d-8704-fa042bb4aa01@github.com>

On Wed, 7 Jun 2023 04:08:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we should update the Java_sun_awt_windows_WScrollbarPeer_setValues as well? it calls the SetScrollInfo

You're right. It needs to be updated too. However, I'd rather do it separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1580534860


From aivanov at openjdk.org  Wed Jun  7 11:07:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 11:07:58 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <LwT-L8HehDfhsRlqk8Ml5gYxetESLidcOnITwql3lYA=.4a1fb7a2-c411-4641-9e53-545d72cda4d8@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <___4DP-X_-gVCaGkOyoRaVhR-fOX04CVUfwzwIpkQ7k=.6e58df57-5e0b-4f32-9304-7b04402fce44@github.com>
 <lXEOqOmdDPkgTcGEDkqhGcnog0uBl8dCKuVmchiy1sQ=.4da80c81-b096-42ab-8082-7b84d965e317@github.com>
 <LwT-L8HehDfhsRlqk8Ml5gYxetESLidcOnITwql3lYA=.4a1fb7a2-c411-4641-9e53-545d72cda4d8@github.com>
Message-ID: <Ot7ZOk-aDc70J5DlXt2zJ0YCg6L0bZTxXTx-ORyd0ZY=.c0e059cf-af39-4447-9eee-c03b89f3ab36@github.com>

On Wed, 7 Jun 2023 03:30:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If it is unused can we delete it?

It's possible. Yet I'd rather leave it for another time.

There's also a specific `WM_AWT_SET_SCROLL_INFO` message to call `::SetScrollInfo`. This message is never used, it can also be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14338#discussion_r1221395024


From aivanov at openjdk.org  Wed Jun  7 11:22:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 11:22:55 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <gy_St0f-ert6CgqILClIQQDya3tYa_XY-bLN93DXGtE=.9f3c2283-1dba-4cba-8de1-1e1a861863dd@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
 <nxPxvV4LavBphc2f7PCnXOkOL2rO-2tBz__abUs-zgg=.195c7b8c-28b9-4bdc-98c3-9df616da338e@github.com>
 <gy_St0f-ert6CgqILClIQQDya3tYa_XY-bLN93DXGtE=.9f3c2283-1dba-4cba-8de1-1e1a861863dd@github.com>
Message-ID: <5bxgXIFaQodGL8Y6w_4GtyaU20A-Z1mHspmGWSJNW54=.45488d0b-fb05-4555-b81a-2f7adb4ede15@github.com>

On Tue, 6 Jun 2023 22:55:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java line 164:
>> 
>>> 162:         OverlappingTestBase.doMain(args);
>>> 163:         captureScreen("Img_5.png");
>>> 164:     }
>> 
>> It is just a test, so no need to over-engineer it but  it 'feels wrong' to specify the file name
>> as foo.png here and separately inside captureScreen choose 'png' as the file type to use.
>> Perhaps  captureScreen("Img_5.png", "png")  ?
>
> Updated

It doesn't feel right this way either. A cleaner approach would be to pass the undecorated file name and add the extension and specify the format inside `captureScreen`. (Passing the same value as a parameter usually produces an IDE warning, which means the parameter is not necessary.)


captureScreen("Img_5");

ImageIO.write(
        robot.createScreenCapture(new Rectangle(0, 0, screenSize.width, screenSize.height)),
        "png",
        new File(filename + ".png")
);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1221410051


From aivanov at openjdk.org  Wed Jun  7 12:48:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 12:48:10 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
Message-ID: <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>

On Fri, 2 Jun 2023 08:12:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimization removed to use local variables for non-percentage units

Overall, it covers most of the values now. There are a couple of omissions though: `BackgroundImage`, `BorderWidthValue` (it could be handled automatically by its superclass, `LengthValue`).

I assume `CssValue` is never used directly, it it?

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2218:

> 2216:         @Override
> 2217:         public int hashCode() {
> 2218:             return Float.hashCode(value);

Now that `equals` method takes into account `value`, `index` and `lu`, they could be added to `hashCode`.

(On the other hand, any `CssValue` object is unlikely to be used as a key in a map.)

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2481:

> 2479:         @Override
> 2480:         public boolean equals(Object val) {
> 2481:             return val instanceof CSS.ColorValue color && c.equals(color.c);

Is it possible that the value of `c` is null? You have the null-check in `hashCode` but you don't test it in `equals`.

`ColorValue.parseCssValue` returns `null` if it can't parse the color. So, `c` should never be `null`.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2545:

> 2543:         @Override
> 2544:         public boolean equals(Object val) {
> 2545:             return val instanceof CSS.BorderStyle border && style.equals(border.style);

The `style` field is of type `CSS.Value` which doesn't implement `equals` (yet). It shouldn't be a problem, however, you may use `==` explicitly.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2677:

> 2675:         @Override
> 2676:         public int hashCode() {
> 2677:             return Float.hashCode(span);

Should `hashCode` take into account `percentage` and `lu` fields which are used in `equals`?

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:

> 2682:             if (percentage) {
> 2683:                 return val instanceof CSS.LengthValue lu
> 2684:                        && Objects.equals(svalue, lu.svalue);

Doesn't comparing `span` work for percentage values? The comment for `span` field implies it should contain the parsed value.

This comparison could fail for the case where there's a space before the `%` in the string.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2918:

> 2916:             hashCode |= Float.hashCode(verticalPosition);
> 2917:             hashCode |= Short.hashCode(relative);
> 2918:             return hashCode;

It's a nit yet you can simply return the computed value:
Suggestion:

            return Float.hashCode(horizontalPosition)
                   | Float.hashCode(verticalPosition)
                   | Short.hashCode(relative);

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 3089:

> 3087:         @Override
> 3088:         public int hashCode() {
> 3089:             return Float.hashCode(value);

Should it take into account other fields which are used in `equals`?

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

PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1467436669
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221444880
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221469195
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221476275
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221506112
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221504991
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221508837
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221511728


From aivanov at openjdk.org  Wed Jun  7 12:51:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 12:51:07 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v12]
In-Reply-To: <en4qNHDaewtfd6BREQH8zVnLPLxo9r2nBTz2uhrd0tM=.19a62dd6-781d-42b0-84dc-f8ca6a2182fb@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <Y-512D4vWT9iDGsEkGqIxJrpN_9Wdn7RpJbTf0tJsgU=.98f7d857-48a7-4a67-a70f-9b847bf449b1@github.com>
 <en4qNHDaewtfd6BREQH8zVnLPLxo9r2nBTz2uhrd0tM=.19a62dd6-781d-42b0-84dc-f8ca6a2182fb@github.com>
Message-ID: <oqBYi_bX3jlu8yA1b2uPe6aDjXtc6U3zLP_q1BbkOdI=.f39f88ac-75e8-464b-87df-0032552ea563@github.com>

On Thu, 1 Jun 2023 02:59:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use local objects for FontSize as per review comment
>
> @prrace @aivanov-jdk Any further comments on this PR? I would like to get it in by RDP1 if it is possible and I guess contentious issues are sorted

@prsadhuk, could you add me as the contributor for the test and `LengthUnit`, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1580746030


From duke at openjdk.org  Wed Jun  7 13:01:04 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 7 Jun 2023 13:01:04 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
Message-ID: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>

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

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

Commit messages:
 - JDK-8307934: JRobot.moveMouseTo must access component on EDT
 - Update full name

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

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


From azvegint at openjdk.org  Wed Jun  7 13:11:15 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 13:11:15 GMT
Subject: Integrated: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots
In-Reply-To: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
Message-ID: <VZmU_H2e_ZmNG3MGZ7XTfaQ_6N91AeSAss80F3VpuYg=.8594bd83-939b-4342-a89e-6d2d86868f45@github.com>

On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
> 
> But this functionality is a very important part of automated testing.
> 
> 
> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
> 
> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
> It has several drawbacks though:
> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
> + There is no way to disable the visual "screen flash" after screenshot
> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
> But we still can consider this option as a fallback.
> 
> 
> 
> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
> 
> + implementation is more complicated comparing to Screenshot API
> + no intermediate file, screenshot data can be obtained from memory
> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
> 
> 
> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
> 
> This change also introduces some new behavior for the robot:
> A system window now appears asking for confirmation from the user to capture the screen.
> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
> + The user can allow a screen capture for all screens or some of them. For screens witho...

This pull request has now been integrated.

Changeset: 9d7bf532
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d7bf5329e5a0393553bca2e3a51ad1125b41b96
Stats:     15080 lines in 106 files changed: 15040 ins; 18 del; 22 mod

8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots

Reviewed-by: prr, kizune, psadhukhan

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

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


From aivanov at openjdk.org  Wed Jun  7 13:59:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 13:59:09 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
Message-ID: <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>

On Wed, 7 Jun 2023 12:45:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> `BorderWidthValue` (it could be handled automatically by its superclass, `LengthValue`)

Yep, it's handled correctly `"border-width: medium"` passes the test.

> This comparison could fail for the case where there's a space before the `%` in the string.

`FontSize` does handle `{"font-size: 100%", "font-size: 100 %"}` pair, but `LengthValue` doesn't.

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

PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1580879664
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221645885


From aivanov at openjdk.org  Wed Jun  7 14:26:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 14:26:05 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
Message-ID: <12tAKtQ1Hjg2jl7W6KCaJJcHC3JMix8zPCrLKQKWpCg=.6b6182c2-89fa-4d0e-8571-26bfd2f82364@github.com>

On Fri, 2 Jun 2023 08:12:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimization removed to use local variables for non-percentage units

So, there are no show-stoppers except for my minor comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1580931539


From aivanov at openjdk.org  Wed Jun  7 14:26:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 14:26:08 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
Message-ID: <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>

On Wed, 7 Jun 2023 13:55:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:
>> 
>>> 2682:             if (percentage) {
>>> 2683:                 return val instanceof CSS.LengthValue lu
>>> 2684:                        && Objects.equals(svalue, lu.svalue);
>> 
>> Doesn't comparing `span` work for percentage values? The comment for `span` field implies it should contain the parsed value.
>> 
>> This comparison could fail for the case where there's a space before the `%` in the string.
>
>> This comparison could fail for the case where there's a space before the `%` in the string.
> 
> `FontSize` does handle `{"font-size: 100%", "font-size: 100 %"}` pair, but `LengthValue` doesn't.

No, it doesn't. For some reason, both `100%` and `200%` are parsed so that `span = 1.0`.

Let's leave it as is then. It handles the most common case.

Handling a space before the percent sign can be postponed to a later fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221688903


From prappo at openjdk.org  Wed Jun  7 14:26:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 14:26:36 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
Message-ID: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>

Please review this long-awaited change to documentation inheritance.

This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:

?{@inheritDoc S}

Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

Commit messages:
 - Disable problematic check
 - Counterbalance changes to method comments algorithm
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

Changes: https://git.openjdk.org/jdk/pull/14357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285368
  Stats: 1827 lines in 32 files changed: 1693 ins; 29 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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


From jjg at openjdk.org  Wed Jun  7 15:29:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 15:29:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:

> 1323:                         //
> 1324:                         //     m.at(pos).newInheritDocTree(ref)
> 1325:                         //

Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221797159


From prappo at openjdk.org  Wed Jun  7 15:45:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:45:01 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
Message-ID: <kMJ-UdMOezmkIu04LMPaFN1E8h0Mzu8jmDJgT7Y55QU=.02c110be-c7fd-4cc4-a71a-305db60003be@github.com>

On Wed, 7 Jun 2023 15:27:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:
> 
>> 1323:                         //
>> 1324:                         //     m.at(pos).newInheritDocTree(ref)
>> 1325:                         //
> 
> Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

I'll tone it down; thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221821265


From prappo at openjdk.org  Wed Jun  7 15:51:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:51:56 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <wosayDaqqnU3b182aUqyDLiG57Iw-hMnXfwIKVaT_uo=.9ad4e309-a3a8-4fe5-849c-1392c39fcaab@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

For details on changes to "methods comment algorithm", see the associated CSR: https://bugs.openjdk.org/browse/JDK-8287152

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581099793


From prappo at openjdk.org  Wed Jun  7 16:02:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 16:02:40 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: make warning less scary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/a56253b3..c0fc69c2

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

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

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


From aivanov at openjdk.org  Wed Jun  7 17:15:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 17:15:03 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
Message-ID: <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>

On Wed, 7 Jun 2023 14:21:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This comparison could fail for the case where there's a space before the `%` in the string.
>> 
>> `FontSize` does handle `{"font-size: 100%", "font-size: 100 %"}` pair, but `LengthValue` doesn't.
>
> No, it doesn't. For some reason, both `100%` and `200%` are parsed so that `span = 1.0`.
> 
> Let's leave it as is then. It handles the most common case.
> 
> Handling a space before the percent sign can be postponed to a later fix.

Aha, the value is capped at 100%:

https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2627-L2628

This is why 200% is parsed as if it were 100%.

The following code

        public boolean equals(Object val) {
            return val instanceof CSS.LengthValue lu
                   && percentage == lu.percentage
                   && span == lu.span
                   && Objects.equals(units, lu.units);
        }

works correctly if you modify this line in the test

https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java#L86

to

            {"margin-top: 100%", "margin-top: 50%"},


The above code also handles the case `"margin-top: 50 %"` correctly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1221932524


From prappo at openjdk.org  Wed Jun  7 17:34:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 17:34:22 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Mf4lFV-lds3s3_tH5fBxTU31hdmdtmsQvpzacfwgb7U=.a6cdc2d2-aefc-4765-a992-1e82b8a86e09@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Full disclosure. Here are all the files that are different before (1) and after (2) the change:

 - https://cr.openjdk.org/~prappo/8285368/1/api
 - https://cr.openjdk.org/~prappo/8285368/2/api

As you can see, the vast majority of differences are in "See Also" sections, which come from `@see` tags. Sadly, `@see` tags are inheritable "by omission". That said, `@see` is also underspecified, somewhat broken, and I believe is not as important as those parts of a doc comment that allow `{@inheritDoc}`.

I suggest that we integrate this PR and take care of `@see` in 22. But if the corrections are really required, I can try to introduce explicit `@see` tags, so there are no changes whatsoever.

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581226538


From duke at openjdk.org  Wed Jun  7 17:34:30 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 7 Jun 2023 17:34:30 GMT
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering [v2]
In-Reply-To: <0tixl2g0Tq-yGHz6_0XsPjZwYoW_YWjuoMcaFOVR_68=.0ef9b8e4-930e-4136-8426-124d1e0a5053@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
 <0tixl2g0Tq-yGHz6_0XsPjZwYoW_YWjuoMcaFOVR_68=.0ef9b8e4-930e-4136-8426-124d1e0a5053@github.com>
Message-ID: <bBLvtSEu1s0pAcu4TgPMvuCY8QYKmJqSj6Vw5HM0C78=.b8759e45-cb07-4f07-885c-92d9832303f3@github.com>

On Tue, 11 Apr 2023 04:47:04 GMT, Jeremy <duke at openjdk.org> wrote:

>> The original write-up contains two complaints:
>> 1. The window is opaque, so pixels that should be transparent are black.
>> 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).
>> 
>> I recommend splitting this up into separate tickets.
>> 
>> This PR addresses the first (probably most offensive) issue: the window is now transparent.
>> 
>> I experimented with a change that resolves the second issue (image resolution) here:
>> https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002
>> 
>> ... that works, but IMO that looks riskier and should be part of a separate discussion.
>> 
>> I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303904: avoid System.exit(1)
>   
>   mrserb recommended against this in a separate PR
>   
>   https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

What is the fate of auto-closed PRs?

That is: as long as I don't delete this branch in my repo will this be available for future reference if anyone dusts off this ticket in the future?

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

PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-1581232754


From duke at openjdk.org  Wed Jun  7 17:53:44 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 7 Jun 2023 17:53:44 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
Message-ID: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>

# 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:

<img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">

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. (In this case: that's the opaque green top two windows.) This is probably coming from `ComponentUI.update`
2. If a JRootPane has a translucent background, that color "wins". It doesn't composite on top of a window's translucent background: it simply *replaces* it. (See the blue-ish bottom-right window. Note it's blue -- not purple.) This is probably because the RepaintManager uses `AlphaComposite.Src` in a couple of places to replace its destination Graphics.
3. If a JRootPane has a null background color, then the Window's background color paints as expected. (See the red-ish bottom-left window.)

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

Commit messages:
 - 8303950: working on occasional unit failures
 - 8303950: avoid System.exit(1)
 - 8303950: adding opaque white window under test windows
 - 8303950: this resolves bug8303950 by adding special RootPaneContainer behavior
 - 8303950: adding unit test for legacy window behavior
 - 8303950: fixing false negative
 - 8303950: adding failing test to identify problem
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - ... and 1 more: https://git.openjdk.org/jdk/compare/98a7a60f...37834391

Changes: https://git.openjdk.org/jdk/pull/14363/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303950
  Stats: 409 lines in 3 files changed: 407 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14363/head:pull/14363

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


From prr at openjdk.org  Wed Jun  7 17:56:44 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 Jun 2023 17:56:44 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <n3zdhDO2-cMn6Y7lGDcCY6M2SAtN2z3PD89u9cIYAbU=.1b40426f-8b7a-475e-abe1-cca19e47adfc@github.com>

On Wed, 7 Jun 2023 12:54:54 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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

test/jdk/javax/swing/regtesthelpers/JRobot.java line 260:

> 258:      */
> 259:     public void convertRectToScreen(Rectangle r, Component c) {
> 260:         AtomicReference<Point> p = new AtomicReference<>();

So this change must be documented on all affected entry points, so that people understand
what it does.
Also touching Robot means you need to run ALL tests that use this utility and make sure you didn't break any. 
Have you done that ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1221975000


From javalists at cbfiddle.com  Wed Jun  7 18:06:23 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 7 Jun 2023 11:06:23 -0700
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
Message-ID: <B8F4CCD1-CF22-489D-992B-536E6868FCB3@cbfiddle.com>

Are you able to test on platforms other than macOS?  (I?m not, so I can?t help with that.)

  Alan



> On Jun 7, 2023, at 10:53 AM, Jeremy <duke at openjdk.org> 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:
> 
> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
> 
> 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. (In this case: that's the opaque green top two windows.) This is probably coming from `ComponentUI.update`
> 2. If a JRootPane has a translucent background, that color "wins". It doesn't composite on top of a window's translucent background: it simply *replaces* it. (See the blue-ish bottom-right window. Note it's blue -- not purple.) This is probably because the RepaintManager uses `AlphaComposite.Src` in a couple of places to replace its destination Graphics.
> 3. If a JRootPane has a null background color, then the Window's background color paints as expected. (See the red-ish bottom-left window.)
> 
> -------------
> 
> Commit messages:
> - 8303950: working on occasional unit failures
> - 8303950: avoid System.exit(1)
> - 8303950: adding opaque white window under test windows
> - 8303950: this resolves bug8303950 by adding special RootPaneContainer behavior
> - 8303950: adding unit test for legacy window behavior
> - 8303950: fixing false negative
> - 8303950: adding failing test to identify problem
> - Merge pull request #4 from openjdk/master
> - Merge pull request #3 from openjdk/master
> - Merge pull request #2 from openjdk/master
> - ... and 1 more: https://git.openjdk.org/jdk/compare/98a7a60f...37834391
> 
> Changes: https://git.openjdk.org/jdk/pull/14363/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8303950
>  Stats: 409 lines in 3 files changed: 407 ins; 1 del; 1 mod
>  Patch: https://git.openjdk.org/jdk/pull/14363.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14363/head:pull/14363
> 
> PR: https://git.openjdk.org/jdk/pull/14363
> 



From mickleness at gmail.com  Wed Jun  7 18:58:26 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Wed, 07 Jun 2023 18:58:26 +0000
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: <B8F4CCD1-CF22-489D-992B-536E6868FCB3@cbfiddle.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
 <B8F4CCD1-CF22-489D-992B-536E6868FCB3@cbfiddle.com>
Message-ID: <emee8b4973-1a85-4afb-a47b-c207cd1e4d12@a922633f.com>

Alan,

No, I?m not currently set up to test OpenJDK PR?s on other platforms.

I?m fuzzy on exactly what happens automatically in an OpenJDK PR. Are my 
new unit tests automatically run on a variety of platforms? (That is: 
are my new unit tests part of what executes here 
<https://github.com/mickleness/jdk/actions/runs/5197802507/jobs/9386648003>? 
Or does that skip several UI-based unit tests?)

I do have a Windows machine, but IIRC setting up OpenJDK to build on my 
Mac was difficult, and I don?t want to go through that again on Windows 
unless I really have to.

  - Jeremy

------ Original Message ------
>From "Alan Snyder" <javalists at cbfiddle.com>
To "Jeremy" <duke at openjdk.org>
Cc client-libs-dev at openjdk.org
Date 6/7/23, 2:06:23 PM
Subject Re: RFR: JDK-8303950: [macos]Translucent Windows Flicker on 
Repaint

>Are you able to test on platforms other than macOS?  (I?m not, so I can?t help with that.)
>
>   Alan
>
>
>
>>  On Jun 7, 2023, at 10:53 AM, Jeremy <duke at openjdk.org> 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:
>>
>>  <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
>>
>>  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. (In this case: that's the opaque green top two windows.) This is probably coming from `ComponentUI.update`
>>  2. If a JRootPane has a translucent background, that color "wins". It doesn't composite on top of a window's translucent background: it simply *replaces* it. (See the blue-ish bottom-right window. Note it's blue -- not purple.) This is probably because the RepaintManager uses `AlphaComposite.Src` in a couple of places to replace its destination Graphics.
>>  3. If a JRootPane has a null background color, then the Window's background color paints as expected. (See the red-ish bottom-left window.)
>>
>>  -------------
>>
>>  Commit messages:
>>  - 8303950: working on occasional unit failures
>>  - 8303950: avoid System.exit(1)
>>  - 8303950: adding opaque white window under test windows
>>  - 8303950: this resolves bug8303950 by adding special RootPaneContainer behavior
>>  - 8303950: adding unit test for legacy window behavior
>>  - 8303950: fixing false negative
>>  - 8303950: adding failing test to identify problem
>>  - Merge pull request #4 from openjdk/master
>>  - Merge pull request #3 from openjdk/master
>>  - Merge pull request #2 from openjdk/master
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/98a7a60f...37834391
>>
>>  Changes: https://git.openjdk.org/jdk/pull/14363/files
>>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=00
>>   Issue: https://bugs.openjdk.org/browse/JDK-8303950
>>   Stats: 409 lines in 3 files changed: 407 ins; 1 del; 1 mod
>>   Patch: https://git.openjdk.org/jdk/pull/14363.diff
>>   Fetch: git fetch https://git.openjdk.org/jdk.git pull/14363/head:pull/14363
>>
>>  PR: https://git.openjdk.org/jdk/pull/14363
>>
>


From jjg at openjdk.org  Wed Jun  7 19:00:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:00:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 94:

> 92:             if (supertype == null) {
> 93:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 94:                 return replacement;

`replacement` may be empty.
Consider using `HtmlDocletWriter.invalidTagOutput`.

(Later, we might want to provide a utility message to wrap `messages.error` and `invalidTagOutput`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Suggestion for eventual future cleanup (not this PR): reduce need for chained fields like`config.utils.elementUtils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Note that `configuration.utils` is available as `utils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 120:

> 118:                 // that this method overrides
> 119:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 120:                 return replacement;

Another case for `invalidTagOutput` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037366
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222032679
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222035009
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037884


From dnguyen at openjdk.org  Wed Jun  7 19:01:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 7 Jun 2023 19:01:51 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <vpJwhT0YHJD10AABOkMd-GpFfz5hv0i3MuvYTl2T_p4=.f3ba1477-1c3c-4deb-b17b-8ad9933daf2a@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vpJwhT0YHJD10AABOkMd-GpFfz5hv0i3MuvYTl2T_p4=.f3ba1477-1c3c-4deb-b17b-8ad9933daf2a@github.com>
Message-ID: <J3s7i-sgPbpSTzQy7I85RUmcMm1C6vipzO9l47KMdGw=.65bf910e-8ae3-43c8-8c84-7ca5e7262e72@github.com>

On Wed, 7 Jun 2023 07:27:02 GMT, Tejesh R <tr at openjdk.org> wrote:

> I applied the changes and observed that still some overlap is seen. Any additional properties settings are expected for this fix?

EDIT: I see the same issue on my device. (Default scaling)

<img width="441" alt="Screenshot 2023-06-07 at 11 55 59 AM" src="https://github.com/openjdk/jdk/assets/96267980/25750a9d-ecdd-4e12-a945-53a9d24f2f3e">

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1581350739


From philip.race at oracle.com  Wed Jun  7 19:02:30 2023
From: philip.race at oracle.com (Philip Race)
Date: Wed, 7 Jun 2023 12:02:30 -0700
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: <emee8b4973-1a85-4afb-a47b-c207cd1e4d12@a922633f.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
 <B8F4CCD1-CF22-489D-992B-536E6868FCB3@cbfiddle.com>
 <emee8b4973-1a85-4afb-a47b-c207cd1e4d12@a922633f.com>
Message-ID: <0cda5aac-1a20-2eee-35a5-05e1bc678a45@oracle.com>

if you are thinking of github actions exactly ZERO client tests are run. 
The testing is all on you.

-phil.

On 6/7/23 11:58 AM, Jeremy Wood wrote:
> Alan,
>
> No, I?m not currently set up to test OpenJDK PR?s on other platforms.
>
> I?m fuzzy on exactly what happens automatically in an OpenJDK PR. Are 
> my new unit tests automatically run on a variety of platforms? (That 
> is: are my new unit tests part of what executes here 
> <https://github.com/mickleness/jdk/actions/runs/5197802507/jobs/9386648003>? 
> Or does that skip several UI-based unit tests?)
>
> I do have a Windows machine, but IIRC setting up OpenJDK to build on 
> my Mac was difficult, and I don?t want to go through that again on 
> Windows unless I really have to.
>
> ?- Jeremy
>
> ------ Original Message ------
> From "Alan Snyder" <javalists at cbfiddle.com>
> To "Jeremy" <duke at openjdk.org>
> Cc client-libs-dev at openjdk.org
> Date 6/7/23, 2:06:23 PM
> Subject Re: RFR: JDK-8303950: [macos]Translucent Windows Flicker on 
> Repaint
>
>> Are you able to test on platforms other than macOS?? (I?m not, so I 
>> can?t help with that.)
>>
>> ? Alan
>>
>>
>>
>>> ?On Jun 7, 2023, at 10:53 AM, Jeremy <duke at openjdk.org> 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:
>>>
>>> ?<img width="805" alt="image" 
>>> src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
>>>
>>> ?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. (In this case: that's the 
>>> opaque green top two windows.) This is probably coming from 
>>> `ComponentUI.update`
>>> ?2. If a JRootPane has a translucent background, that color "wins". 
>>> It doesn't composite on top of a window's translucent background: it 
>>> simply *replaces* it. (See the blue-ish bottom-right window. Note 
>>> it's blue -- not purple.) This is probably because the 
>>> RepaintManager uses `AlphaComposite.Src` in a couple of places to 
>>> replace its destination Graphics.
>>> ?3. If a JRootPane has a null background color, then the Window's 
>>> background color paints as expected. (See the red-ish bottom-left 
>>> window.)
>>>
>>> ?-------------
>>>
>>> ?Commit messages:
>>> ?- 8303950: working on occasional unit failures
>>> ?- 8303950: avoid System.exit(1)
>>> ?- 8303950: adding opaque white window under test windows
>>> ?- 8303950: this resolves bug8303950 by adding special 
>>> RootPaneContainer behavior
>>> ?- 8303950: adding unit test for legacy window behavior
>>> ?- 8303950: fixing false negative
>>> ?- 8303950: adding failing test to identify problem
>>> ?- Merge pull request #4 from openjdk/master
>>> ?- Merge pull request #3 from openjdk/master
>>> ?- Merge pull request #2 from openjdk/master
>>> ?- ... and 1 more: 
>>> https://git.openjdk.org/jdk/compare/98a7a60f...37834391
>>>
>>> ?Changes: https://git.openjdk.org/jdk/pull/14363/files
>>> ?Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=00
>>> ? Issue: https://bugs.openjdk.org/browse/JDK-8303950
>>> ? Stats: 409 lines in 3 files changed: 407 ins; 1 del; 1 mod
>>> ? Patch: https://git.openjdk.org/jdk/pull/14363.diff
>>> ? Fetch: git fetch https://git.openjdk.org/jdk.git 
>>> pull/14363/head:pull/14363
>>>
>>> ?PR: https://git.openjdk.org/jdk/pull/14363
>>>
>>



From jjg at openjdk.org  Wed Jun  7 19:10:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:10:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <n-oEDHNS-V_hrhyTbtNAGUJLhOPuN7-8fgks4CrRM9Q=.73a0158d-1614-48b0-bff8-df89f2c46b69@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritableTaglet.java line 53:

> 51:      *
> 52:      * In the future, this could be reworked using some other mechanism,
> 53:      * such as throwing an exception.

Should `ThrowsTaglet.Failure` (eventually?) be declared here in `InheritableTaglet`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222046447


From prr at openjdk.org  Wed Jun  7 19:11:51 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 Jun 2023 19:11:51 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
Message-ID: <vPRnGawBNBqGkk9qu-tvpMHQ2qUiaIQuzoKVAlTwv4g=.defbdddc-1826-4647-b979-7d8f8e7a33ad@github.com>

On Wed, 7 Jun 2023 17:15:50 GMT, Jeremy <duke at openjdk.org> 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:
> 
> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
> 
> 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. (In this case: that's the opaque green top two windows.) T...

I haven't yet looked at this properly but I'm mightily relieved to see that previous patch gone since
as you say it did look risky and intrusive and I didn't think anyone looking at it would know what it
was intended to solve without plenty of background .. which is often a clue that there's a better fix.

We'll need to test this and since it sounds like you don't have much in the way of testing resources we'll have to see
if we can do that here.
But before we get to that, your tests need "@key headful" .. else the test infrastructure won't know it needs a display.

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

PR Comment: https://git.openjdk.org/jdk/pull/14363#issuecomment-1581365662


From honkar at openjdk.org  Wed Jun  7 19:14:29 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 19:14:29 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows primary
 monitor changes
Message-ID: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>

There are two scenarios related to tray icon distortion.

1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)

2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 

Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was being used to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
 
As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to trigger tray icon update. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.

TrayIconScalingTest's  instructions have been updated to include both the cases described above.

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

Commit messages:
 - year updated
 - fix for tray icon

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

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


From jjg at openjdk.org  Wed Jun  7 19:16:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:16:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 54:

> 52: 
> 53:     @SuppressWarnings("serial")
> 54:     public static final class NoOverriddenMethodFound extends Exception {

General comment, for future work:
Maybe we can combine/merge/unify this exception with `ThrowsTaglet.Failure`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:

> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
> 670: 
> 671:         return true; /* disabled for causing issues in JDK API Documentation build */

Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222051685
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222053011


From jjg at openjdk.org  Wed Jun  7 19:19:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:19:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:

> 2845:                     break;
> 2846:                 }
> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {

What is the significance of the `isPublic` check?
I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222055578


From duke at openjdk.org  Wed Jun  7 19:19:59 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 7 Jun 2023 19:19:59 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v2]
In-Reply-To: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
Message-ID: <3qy9XFIxDHmPrkcCB2pFlo17z9lw0pbdut-3ASRx4cQ=.3e9aaa12-1be0-4b5a-af4e-3c2e6c70097d@github.com>

> # 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:
> 
> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
> 
> 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. (In this case: that's the opaque green top two windows.) T...

Jeremy has updated the pull request incrementally with two additional commits since the last revision:

 - 8303950: Adding "@key headful"
   
   Based on prrace's feedback https://github.com/openjdk/jdk/pull/14363#issuecomment-1581365662
 - 8303950: remove call to Window#toBack()
   
   toBack() moves the Window behind *everything*. If it moved windows only behind other windows in the Swing app that would be great, but that's not what it does.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14363/files
  - new: https://git.openjdk.org/jdk/pull/14363/files/37834391..2c093210

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

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

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


From dnguyen at openjdk.org  Wed Jun  7 20:05:49 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 7 Jun 2023 20:05:49 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
Message-ID: <dJWI_LE_UCK6IBrKQvm8nUK2Nrr5_evw20WD_ai-zLg=.bebbe11f-3fa1-456d-9b2b-554c0c49c084@github.com>

On Wed, 7 Jun 2023 06:55:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
> 
> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

As with my previous comment, I am still getting the same cutoff issue as Tejesh. My personal device's setting has scaling to default but obvious the "Low Vision" theme has some additional scaling to adhere to the theme.

Maybe some additional changes are needed to fix this spacing?

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

PR Review: https://git.openjdk.org/jdk/pull/14346#pullrequestreview-1468468717


From achung at openjdk.org  Wed Jun  7 20:16:49 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 7 Jun 2023 20:16:49 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <W0NSn4cNs3FjTHG2D-QFaMBKEZFmbn8AB0He5kgEzKQ=.98ed00e1-0769-4f23-8753-b66b746c5339@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <W0NSn4cNs3FjTHG2D-QFaMBKEZFmbn8AB0He5kgEzKQ=.98ed00e1-0769-4f23-8753-b66b746c5339@github.com>
Message-ID: <GtFQODu3aJxKA8ulD70rN8hsvvPswFgphP4YegYBTgQ=.0e812c80-4667-4a70-9b81-8caf5a8d2734@github.com>

On Fri, 2 Jun 2023 12:50:31 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation. When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.

I did some testing and I think that without the delay, when the frame moves from iconified to maximized states, the second windowStateChanged event never comes (first being iconified -> normal, second being normal -> maximized), so the test will not pass even if we only check state of the frame on a windowStateChanged event. 

Why do you think no changes are required in the JDK? Shouldn't there be some synchronization needed when calling the native deminiaturize and maximize functions in CPlatformWindow?

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581446552


From aivanov at openjdk.org  Wed Jun  7 20:25:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 20:25:50 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <dJWI_LE_UCK6IBrKQvm8nUK2Nrr5_evw20WD_ai-zLg=.bebbe11f-3fa1-456d-9b2b-554c0c49c084@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <dJWI_LE_UCK6IBrKQvm8nUK2Nrr5_evw20WD_ai-zLg=.bebbe11f-3fa1-456d-9b2b-554c0c49c084@github.com>
Message-ID: <N_C8OT4QitrkATam1x4FSyhy-bjAPlzCqmecHOtTWck=.5a0721a7-17a2-424a-98a7-fe6a56efb640@github.com>

On Wed, 7 Jun 2023 20:02:33 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> My personal device's setting has scaling to default

And what is the default value?

Anything but 100% may cause rendering issues because the size of elements change and not always proportionally.

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1581454303


From dnguyen at openjdk.org  Wed Jun  7 20:25:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 7 Jun 2023 20:25:50 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme
In-Reply-To: <N_C8OT4QitrkATam1x4FSyhy-bjAPlzCqmecHOtTWck=.5a0721a7-17a2-424a-98a7-fe6a56efb640@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <dJWI_LE_UCK6IBrKQvm8nUK2Nrr5_evw20WD_ai-zLg=.bebbe11f-3fa1-456d-9b2b-554c0c49c084@github.com>
 <N_C8OT4QitrkATam1x4FSyhy-bjAPlzCqmecHOtTWck=.5a0721a7-17a2-424a-98a7-fe6a56efb640@github.com>
Message-ID: <edsdiacThhp2ebq14pUIvpqFHt8Sgli7kEFjgXhkvzg=.aac7b720-bf7b-4e1b-b670-512924bb5f8d@github.com>

On Wed, 7 Jun 2023 20:20:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > My personal device's setting has scaling to default
> 
> And what is the default value?
> 
> Anything but 100% may cause rendering issues because the size of elements change and not always proportionally.

Sorry for the vagueness. It's at 100%

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1581456686


From serb at openjdk.org  Wed Jun  7 20:35:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 20:35:50 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <0BRWgfx6UfT6SofS4GPzzT_9MHq62Di9Y2FFGj6D3lU=.15b2f338-3455-4063-8abd-95b4cd170649@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14338#pullrequestreview-1468516787


From serb at openjdk.org  Wed Jun  7 20:35:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 20:35:52 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <9xlnp3nIlGapuqN07_5ntYfL-EuafN14cgZ5IxWbbqY=.29b75970-3781-4d8d-8704-fa042bb4aa01@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <a_DWs1aAiZ3-53ORLCVLyHdWsXwSSOnajDDfl_tM4-g=.ef164e87-d362-4f4b-8573-12517d0bc574@github.com>
 <9xlnp3nIlGapuqN07_5ntYfL-EuafN14cgZ5IxWbbqY=.29b75970-3781-4d8d-8704-fa042bb4aa01@github.com>
Message-ID: <wcFLQM1njosnpQfrzyh2jYIAiuV4yG01jqMWLJjbJ4E=.59da5eba-9f5a-4c26-964f-366797d8f500@github.com>

On Wed, 7 Jun 2023 11:01:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Probably we should update the Java_sun_awt_windows_WScrollbarPeer_setValues as well? it calls the SetScrollInfo
> 
> You're right. It needs to be updated too. However, I'd rather do it separately.

That is up2you, but it looks strange when the patch updates the code which is never executed and skips the code which is executed and has the bug

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1581468337


From jjg at openjdk.org  Wed Jun  7 20:41:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 20:41:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:

> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
> 74:         setAutomaticCheckNoStacktrace(true);
> 75:         { // DocLint is on

"on" -> "explicit"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:

> 83:             }
> 84:         }
> 85:         // DocLint is off

"off" -> "default"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:

> 287: 
> 288:     /*
> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.

possible typo: do you mean "indirect"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:

> 671:      *
> 672:      * For now a warning is issued if a doc comment inherits from
> 673:      * an indirect supertype.

Not sure I agree with this. Can we discuss?

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 61:

> 59: import toolbox.ToolBox;
> 60: 
> 61: /*

Great description! :-)

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 111:

> 109:  *    built.
> 110:  */
> 111: public class TestMethodCommentsAlgorithm extends JavadocTester {

General comment for entire class:  great/clever test!

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:

> 271:             }
> 272:         }
> 273:         System.err.println("Test suite root: " + p);

You might want to use `JavadocTester.out` instead of `System.err`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117577
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117867
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222119420
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222122630
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222124323
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222130052
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222126057


From honkar at openjdk.org  Wed Jun  7 20:48:20 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 20:48:20 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v5]
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

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

  review changes to screen capture

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14289/files
  - new: https://git.openjdk.org/jdk/pull/14289/files/86454670..5b1abfa7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14289&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14289&range=03-04

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

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


From honkar at openjdk.org  Wed Jun  7 20:48:21 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 20:48:21 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v2]
In-Reply-To: <5bxgXIFaQodGL8Y6w_4GtyaU20A-Z1mHspmGWSJNW54=.45488d0b-fb05-4555-b81a-2f7adb4ede15@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <OjqCFfCXO073SZDCPc3zzOq1lMia6X79BEmiaKiWqHM=.c1d72c20-198b-4e92-8968-6d057016f440@github.com>
 <nxPxvV4LavBphc2f7PCnXOkOL2rO-2tBz__abUs-zgg=.195c7b8c-28b9-4bdc-98c3-9df616da338e@github.com>
 <gy_St0f-ert6CgqILClIQQDya3tYa_XY-bLN93DXGtE=.9f3c2283-1dba-4cba-8de1-1e1a861863dd@github.com>
 <5bxgXIFaQodGL8Y6w_4GtyaU20A-Z1mHspmGWSJNW54=.45488d0b-fb05-4555-b81a-2f7adb4ede15@github.com>
Message-ID: <Xo66Y78v2KMy5CXFpXO-8Zrd3pnS72Jxc45UDPDh5-U=.69758beb-6efd-4dc2-844e-ae8956773ed0@github.com>

On Wed, 7 Jun 2023 11:19:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated
>
> It doesn't feel right this way either. A cleaner approach would be to pass the undecorated file name and add the extension and specify the format inside `captureScreen`. (Passing the same value as a parameter usually produces an IDE warning, which means the parameter is not necessary.)
> 
> 
> captureScreen("Img_5");
> 
> ImageIO.write(
>         robot.createScreenCapture(new Rectangle(0, 0, screenSize.width, screenSize.height)),
>         "png",
>         new File(filename + ".png")
> );

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14289#discussion_r1222136262


From serb at openjdk.org  Wed Jun  7 20:48:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 20:48:50 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <l4ae9CRXLXhHJFF2iJ4ZYsrCsg2KA93NhizizF7MRxg=.9981c0a8-13d0-4224-8bf7-81f61693ebc0@github.com>

On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung <achung at openjdk.org> wrote:

> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize
> All client tests passed after change

Possibly some synchronization is needed in the jdk, it needs to be checked why the message is not posted. But it should not be fixed by the "displayChanged" used as a "delay"

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581483465


From prappo at openjdk.org  Wed Jun  7 20:51:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:51:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>

On Wed, 7 Jun 2023 20:29:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
> 
>> 671:      *
>> 672:      * For now a warning is issued if a doc comment inherits from
>> 673:      * an indirect supertype.
> 
> Not sure I agree with this. Can we discuss?

Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222141331


From aivanov at openjdk.org  Wed Jun  7 20:54:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 20:54:50 GMT
Subject: RFR: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <wcFLQM1njosnpQfrzyh2jYIAiuV4yG01jqMWLJjbJ4E=.59da5eba-9f5a-4c26-964f-366797d8f500@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
 <a_DWs1aAiZ3-53ORLCVLyHdWsXwSSOnajDDfl_tM4-g=.ef164e87-d362-4f4b-8573-12517d0bc574@github.com>
 <9xlnp3nIlGapuqN07_5ntYfL-EuafN14cgZ5IxWbbqY=.29b75970-3781-4d8d-8704-fa042bb4aa01@github.com>
 <wcFLQM1njosnpQfrzyh2jYIAiuV4yG01jqMWLJjbJ4E=.59da5eba-9f5a-4c26-964f-366797d8f500@github.com>
Message-ID: <vioPySvSzLwxQFGhBGQSOEl3etfpbDQTTuZvKfL3wRI=.b3444567-99cb-4b08-8b67-dc19ae972bc2@github.com>

On Wed, 7 Jun 2023 20:32:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > Probably we should update the Java_sun_awt_windows_WScrollbarPeer_setValues as well? it calls the SetScrollInfo
> > 
> > 
> > You're right. It needs to be updated too. However, I'd rather do it separately.
> 
> That is up2you, but it looks strange when the patch updates the code which is never executed and skips the code which is executed and has the bug

It has taken a very long time till the root cause for this bug was identified. I admit I was too focused on the code for `ScrollPane` only and I overlooked the fact that `::SetScrollInfo` is also used in `ScrollBar`.

As such, the updated code is limited to the native implementation of `ScrollPane`. Let's leave it this way.

Thank you for finding a similar problem in `ScrollBar`, it needs fixing too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14338#issuecomment-1581491086


From prappo at openjdk.org  Wed Jun  7 20:54:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:54:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
Message-ID: <k8rm3qEl5OMewrQO0KAUt7AJzBff-ERTGxvPk9gFz1s=.78a400ef-5a51-47eb-b303-1a9306bb51cd@github.com>

On Wed, 7 Jun 2023 19:13:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:
> 
>> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
>> 670: 
>> 671:         return true; /* disabled for causing issues in JDK API Documentation build */
> 
> Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

I mentioned it in the test, here: TestDirectedInheritance.testNotDirectSupertype. I reckon referring to code from a test is okay, but not the other way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222148500


From prappo at openjdk.org  Wed Jun  7 21:04:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 21:04:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
Message-ID: <jm474v09yfBS07FBRhAsNybvEs-uG3O1FCilzCRAi80=.cdf90791-5449-4bb7-b9a5-5b0e29bcef54@github.com>

On Wed, 7 Jun 2023 19:16:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:
> 
>> 2845:                     break;
>> 2846:                 }
>> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {
> 
> What is the significance of the `isPublic` check?
> I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

That directly mimics the current behaviour at addSuperInterfaces(Utils.java:802), which in turn is used at ImplementedMethods(VisibleMemberTable.java:1064) to collect overridden methods in superinterfaces. If you look around, it's quite an idiom and predates this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222173441


From aivanov at openjdk.org  Wed Jun  7 21:22:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Jun 2023 21:22:01 GMT
Subject: Integrated: 8297923: java.awt.ScrollPane broken after multiple scroll
 up/down
In-Reply-To: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
References: <TnkQyX0hm92hVbhxmCSq6LIK_ehCD48hhZ5YMXjiOnA=.bd865201-0200-4500-941c-4062647218bd@github.com>
Message-ID: <O6_R3nzadIp8FeKiB0pAh-N0X7x7d34nOB5ROnk97Mo=.390569d1-0a7a-42e5-968f-cd9963f8761b@github.com>

On Tue, 6 Jun 2023 16:07:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem description**
> 
> If you grab the thumb of the scroll bar of `ScrollPane` and drag it slowly and continuously up and down, you'll notice the UI stops rendering correctly: the child component of the scroll pane will render on the left of the frame itself, the inside of the scroll pane will be filled with the background color of its child component.
> 
> **Root cause**
> 
> AWT calls the [`::SetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo) function on EDT when AWT processes scroll bar tracking events. This Windows API is not thread-safe, calling this function on an incorrect thread leads to leaking GDI objects.
> 
> When the process reaches the limit on the number of GDI objects, it cannot create new GDI objects, which results in rendering issues.
> 
> **Fix**
> 
> To resolve the problem, I modified the code so that `::SetScrollInfo` and [`::GetScrollInfo`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getscrollinfo) are always called on the toolkit thread, all AWT components are created on the toolkit thread.
> 
> An automatic test is provided. The test scrolls the vertical scroll bar up and down. Then the test takes a screenshot. When the bug is reproduced, the robot cannot create new GDI objects to capture the screenshot and it throws `OutOfMemoryError`.

This pull request has now been integrated.

Changeset: ea419073
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea41907396a70933c4f6e6b0f247f7ba589a3a23
Stats:     193 lines in 2 files changed: 189 ins; 0 del; 4 mod

8297923: java.awt.ScrollPane broken after multiple scroll up/down

Reviewed-by: honkar, prr, serb

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

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


From honkar at openjdk.org  Wed Jun  7 21:33:52 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 21:33:52 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <GtFQODu3aJxKA8ulD70rN8hsvvPswFgphP4YegYBTgQ=.0e812c80-4667-4a70-9b81-8caf5a8d2734@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <W0NSn4cNs3FjTHG2D-QFaMBKEZFmbn8AB0He5kgEzKQ=.98ed00e1-0769-4f23-8753-b66b746c5339@github.com>
 <GtFQODu3aJxKA8ulD70rN8hsvvPswFgphP4YegYBTgQ=.0e812c80-4667-4a70-9b81-8caf5a8d2734@github.com>
Message-ID: <wmaCHQD9xEG1TW5uymNMOkT2RNU3ksH-QGBlXqLYZVM=.171190fe-684d-4a40-b618-43e4c0adb297@github.com>

On Wed, 7 Jun 2023 20:13:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation.
>> When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. 
>> In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
>
>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation. When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
> 
> I did some testing and I think that without the delay, when the frame moves from iconified to maximized states, the second windowStateChanged event never comes (first being iconified -> normal, second being normal -> maximized), so the test will not pass even if we only check state of the frame on a windowStateChanged event. 
> 
> Why do you think no changes are required in the JDK? Shouldn't there be some synchronization needed when calling the native deminiaturize and maximize functions in CPlatformWindow?

@alisenchung @mrserb 

After reading through the discussion, I think the fix on native side rather than on Java might work better here. I was revisiting a Tray Icon issue which had similar sync problem when I was trying to get updated scale value on Java side by using a DisplayChangedListener [Details here - [PR#8441](https://github.com/openjdk/jdk/pull/8441#issuecomment-1121345834)] and there were multiple events occurring back to back. When I had a hard-coded delay set on Java side, the update to tray icon worked fine. I think this is a similar case where introducing a delay solves the issue. But since hard-coded delay is not the ideal solution probably triggering/ calling the required piece of code after everything is updated on native side is the way to go (event/message-driven).

Handling the code on Window's native code with the help of windows messaging event solved the Trayicon problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581538514


From jjg at openjdk.org  Wed Jun  7 21:43:50 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <fWqllQItWFIRLwYdEjiJEqQWJDJnjc-Pyg7o-4KkS1A=.7385e24a-3930-4132-8920-c531aa1d806c@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Great work in a difficult area overflowing with Technical Debt.

I've made various (optional) suggestions, I'll approve for now, but will look again if you want to make ore changes.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1468628610


From jjg at openjdk.org  Wed Jun  7 21:43:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
Message-ID: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>

On Wed, 7 Jun 2023 20:48:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
>> 
>>> 671:      *
>>> 672:      * For now a warning is issued if a doc comment inherits from
>>> 673:      * an indirect supertype.
>> 
>> Not sure I agree with this. Can we discuss?
>
> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?

For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.

That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222202085


From jjg at openjdk.org  Wed Jun  7 21:43:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
Message-ID: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>

On Wed, 7 Jun 2023 21:37:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011
>
> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
> 
> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
> 
> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)

Thanks for tying these together; I had not realized they were related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222203243


From honkar at openjdk.org  Wed Jun  7 21:46:48 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 21:46:48 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <1FML-6-71COa3S1-_grJbOR-vzU8g8rAOh-WESrJpFI=.bef2b9c1-05fb-4a0a-82d2-a2320603b5a2@github.com>

On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung <achung at openjdk.org> wrote:

> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize
> All client tests passed after change

Also noticed this comment in setWindowState() of [CPlatformWindow.java#L1011 ](https://github.com/openjdk/jdk/blob/ea41907396a70933c4f6e6b0f247f7ba589a3a23/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java#L1011)

_// NOTE: the SWP.windowState field gets updated to the newWindowState
//       value when the native notification comes to us_

May be waiting untill the required native notification using an event-driven wait might work here?

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581550235


From honkar at openjdk.org  Wed Jun  7 21:49:47 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 21:49:47 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <GtFQODu3aJxKA8ulD70rN8hsvvPswFgphP4YegYBTgQ=.0e812c80-4667-4a70-9b81-8caf5a8d2734@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <W0NSn4cNs3FjTHG2D-QFaMBKEZFmbn8AB0He5kgEzKQ=.98ed00e1-0769-4f23-8753-b66b746c5339@github.com>
 <GtFQODu3aJxKA8ulD70rN8hsvvPswFgphP4YegYBTgQ=.0e812c80-4667-4a70-9b81-8caf5a8d2734@github.com>
Message-ID: <sKMXCWovH5rWAfCoOHnBLnXiBYfSGsa1J0KQPbf0JE0=.474e21b4-705c-4b79-afb6-bdbfca00b664@github.com>

On Wed, 7 Jun 2023 20:13:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation.
>> When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. 
>> In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
>
>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation. When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
> 
> I did some testing and I think that without the delay, when the frame moves from iconified to maximized states, the second windowStateChanged event never comes (first being iconified -> normal, second being normal -> maximized), so the test will not pass even if we only check state of the frame on a windowStateChanged event. 
> 
> Why do you think no changes are required in the JDK? Shouldn't there be some synchronization needed when calling the native deminiaturize and maximize functions in CPlatformWindow?

@alisenchung Before digging deeper on Cocoa Event Handling, please check if fixing on native side by waiting for an approriate NSEvent is a viable solution in this case. 

A gist of Cocoa Event Handling mechanism - 

1. NSRunLoop in the event loop [NSApplicationAWT.m#L303](https://github.com/openjdk/jdk/blob/ea41907396a70933c4f6e6b0f247f7ba589a3a23/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L303) handled by NSApp. 
2. NSApp converts this event into NSEvent object and dispatches using sendEvent to the appropriate NSView object.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581552689


From serb at openjdk.org  Wed Jun  7 22:12:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jun 2023 22:12:49 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v5]
In-Reply-To: <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
Message-ID: <ZjZnBiYX6IxgFdIh1S5NqwLZPqbOqnW8Omw0TD4EjQ4=.48c67edc-4483-43c1-9d94-fbbf908942a3@github.com>

On Wed, 7 Jun 2023 20:48:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes to screen capture

DId you able to reproduce the intermittent issue in the mach5 or it is green?

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

PR Comment: https://git.openjdk.org/jdk/pull/14289#issuecomment-1581575826


From honkar at openjdk.org  Wed Jun  7 22:15:48 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Jun 2023 22:15:48 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v5]
In-Reply-To: <ZjZnBiYX6IxgFdIh1S5NqwLZPqbOqnW8Omw0TD4EjQ4=.48c67edc-4483-43c1-9d94-fbbf908942a3@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
 <ZjZnBiYX6IxgFdIh1S5NqwLZPqbOqnW8Omw0TD4EjQ4=.48c67edc-4483-43c1-9d94-fbbf908942a3@github.com>
Message-ID: <17wIGPBSCCqyTjQsUSJdxqO7LpT3Ojv3MLM6p32E1ok=.c211c51c-db3a-4794-b016-fb28caff11f7@github.com>

On Wed, 7 Jun 2023 22:09:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> DId you able to reproduce the intermittent issue in the mach5 or it is green?

 I wasn't able to reproduce the intermittent issue during CI Testing - ran the test individually as well as the whole test group multiple times.

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

PR Comment: https://git.openjdk.org/jdk/pull/14289#issuecomment-1581583303


From rmahajan at openjdk.org  Wed Jun  7 22:43:16 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 7 Jun 2023 22:43:16 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v11]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <ou8MJRRSH0CrjzCTg3Gw_06w-EFpoLZ5NLQQEBII3Ac=.e897733f-b7d7-4e4e-a9eb-836059ec71bd@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/7058250e..9dffa10b

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

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

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


From rmahajan at openjdk.org  Wed Jun  7 22:51:36 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 7 Jun 2023 22:51:36 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v12]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <P4qrrYHGdc8cV-g5Ti7847uiT9EU6iqHzSzemF4YwIk=.8913ea21-25a0-4022-87ec-6f8461276aad@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/9dffa10b..727836ea

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

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

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


From azvegint at openjdk.org  Thu Jun  8 00:01:48 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 8 Jun 2023 00:01:48 GMT
Subject: RFR: 8308152: PropertyDescriptor should work with overridden
 generic getter method
In-Reply-To: <y3357eddJ39AoMw91PyDmOwMBqN_4zdBYoLBgQAazHo=.9ed77076-7332-4bbe-ac5f-631c511eaed5@github.com>
References: <y3357eddJ39AoMw91PyDmOwMBqN_4zdBYoLBgQAazHo=.9ed77076-7332-4bbe-ac5f-631c511eaed5@github.com>
Message-ID: <jnKNM1MSvHww32raIHh_QFA3Eki9JYEuLAD0pORY2tw=.64fc8bab-30cf-41cf-892d-8c22d40f1173@github.com>

On Tue, 30 May 2023 19:13:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Description of the bug, copied from https://github.com/openjdk/jdk/pull/7190
> 
> 
>> In jdk 9 we started to sort the list of methods for each class for two reasons:
>>  1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified.
>>  2. We tried to sort methods so the more specific returns types come first, this was done because our logic for selecting the correct method did not work properly. 
>> 
>> The second issue above was fixed by the separate change [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) so now we only need to sort the list of methods in any order and do not care about return types.
>> 
> 
> Unfortunatly it was found that we have two code paths to create a PropertyDescriptor, one of them is used by the `Introspector.getBeanInfo` and was patched by the [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) and another when the PropertyDescriptor is created directly and it still affected by that bug.
> 
> The code added by this patch is the same we already use in PropertyInfo.java, see
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java#L81

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14228#pullrequestreview-1468749398


From serb at openjdk.org  Thu Jun  8 00:18:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 00:18:56 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v12]
In-Reply-To: <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
Message-ID: <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>

On Fri, 26 May 2023 01:14:48 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> But still why the size on the components are so different? is it really caused by one "pixel/unit" we requested from the native?
>
> So, basically for w,h =19 we calculate a DPI of 140 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 13 x 13 provided by windows as it is closer to DPI=120 (for 125% scaling).
> While for  w,h =20 we calculate a DPI of 147 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 20 x 20 provided by windows as it is closer to DPI=144 (for 150% scaling).
> Thus part size calculated by us and provided by Windows matches and hence we see bigger properly rendered buttons while for the w,h=19 case we have 19x19 , while windows gives 13x13 
> and hence you see scaled down buttons with bad rendering.

Probably I missed something but I would like to clarify. As you mention above we ask Windows to return the image for the component for some specific size, the Windows may return image of exactly requested size if available or any other size. What we will do if the size is different? In the image above it seems we use it as is, but should we? probably we should rescale it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1222306854


From jiangli at openjdk.org  Thu Jun  8 00:29:14 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 8 Jun 2023 00:29:14 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v6]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <mbFWQnL7BoZSoUD2-3H0VnkR4wj1fLtMVQGgaOxFBUc=.fda0de0b-32df-4eab-8028-610a26e32418@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - In clude $MACHINE_FLAG in partial linking flag.
 - Use '-m32' instead of '-m elf_i386'.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/90027ff2...1c2f75dc

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

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=05
  Stats: 223 lines in 10 files changed: 172 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

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


From rmahajan at openjdk.org  Thu Jun  8 00:43:13 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 8 Jun 2023 00:43:13 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v12]
In-Reply-To: <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
Message-ID: <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>

On Thu, 8 Jun 2023 00:16:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So, basically for w,h =19 we calculate a DPI of 140 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 13 x 13 provided by windows as it is closer to DPI=120 (for 125% scaling).
>> While for  w,h =20 we calculate a DPI of 147 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 20 x 20 provided by windows as it is closer to DPI=144 (for 150% scaling).
>> Thus part size calculated by us and provided by Windows matches and hence we see bigger properly rendered buttons while for the w,h=19 case we have 19x19 , while windows gives 13x13 
>> and hence you see scaled down buttons with bad rendering.
>
> Probably I missed something but I would like to clarify. As you mention above we ask Windows to return the image for the component for some specific size, the Windows may return image of exactly requested size if available or any other size. What we will do if the size is different? In the image above it seems we use it as is, but should we? probably we should rescale it?

So, we ask Windows for the component image based on a particular DPI , not some specific size.
The basic premise here is that we expect Windows returning image that would match the DPI , and then we perform our calculations accordingly. In the case above (if Region.clipRound is used) that basic premise is not met (if w, h=19) due to us calculating a DPI value of 140 which is closer to 120 or 125% scaling while our scaling is acytually 150% and Windows returns us a smaller size of the component than expected.
So we don't need to add extra code to rescale , I believe.
If we provide windows with correctly calculated DPI value which my code change does it should work fine as Windows will give us image of the correct size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1222316115


From azvegint at openjdk.org  Thu Jun  8 01:29:48 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 8 Jun 2023 01:29:48 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v3]
In-Reply-To: <0U4o0wDAMN2XQi-fGvnSmjT9r2iQ_OZgOXLHbSDrig0=.a35a7c74-dcad-4670-8de6-775455529f30@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <0U4o0wDAMN2XQi-fGvnSmjT9r2iQ_OZgOXLHbSDrig0=.a35a7c74-dcad-4670-8de6-775455529f30@github.com>
Message-ID: <WxGtU5Bm32PKgzW4B8uoQJP2mr71vW5YYokaZNZII_Q=.4986226c-58fd-4ab9-be4b-6223bd2ea373@github.com>

On Wed, 7 Jun 2023 04:48:41 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

I assume that the pre-integration testing is green.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14246#pullrequestreview-1468842166


From serb at openjdk.org  Thu Jun  8 02:55:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 02:55:02 GMT
Subject: Integrated: 8308152: PropertyDescriptor should work with overridden
 generic getter method
In-Reply-To: <y3357eddJ39AoMw91PyDmOwMBqN_4zdBYoLBgQAazHo=.9ed77076-7332-4bbe-ac5f-631c511eaed5@github.com>
References: <y3357eddJ39AoMw91PyDmOwMBqN_4zdBYoLBgQAazHo=.9ed77076-7332-4bbe-ac5f-631c511eaed5@github.com>
Message-ID: <51sP7c9XaFXbifFj1JnYKvl_eSpWI0SxCU5-j9krEos=.3c1b9ef1-cc38-4070-b15b-8a02f00a5663@github.com>

On Tue, 30 May 2023 19:13:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Description of the bug, copied from https://github.com/openjdk/jdk/pull/7190
> 
> 
>> In jdk 9 we started to sort the list of methods for each class for two reasons:
>>  1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified.
>>  2. We tried to sort methods so the more specific returns types come first, this was done because our logic for selecting the correct method did not work properly. 
>> 
>> The second issue above was fixed by the separate change [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) so now we only need to sort the list of methods in any order and do not care about return types.
>> 
> 
> Unfortunatly it was found that we have two code paths to create a PropertyDescriptor, one of them is used by the `Introspector.getBeanInfo` and was patched by the [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) and another when the PropertyDescriptor is created directly and it still affected by that bug.
> 
> The code added by this patch is the same we already use in PropertyInfo.java, see
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java#L81

This pull request has now been integrated.

Changeset: 73dd03cc
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73dd03cc5afa6d1e01a92d0027dcb82af27a48af
Stats:     107 lines in 2 files changed: 105 ins; 0 del; 2 mod

8308152: PropertyDescriptor should work with overridden generic getter method

Reviewed-by: azvegint

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

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


From serb at openjdk.org  Thu Jun  8 02:59:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 02:59:55 GMT
Subject: RFR: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
Message-ID: <Mygq8gnnE-01jEM3wv_m2aUEwRpof3OInyK4_gdRNv4=.8dbb0233-0c7f-4129-8142-993e453e10ac@github.com>

On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573).
> 
> This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file.

Not a critical comment but it would be good in such cases to add a new bugid to the test which found the bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/14170#issuecomment-1581813780


From serb at openjdk.org  Thu Jun  8 03:15:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 03:15:49 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
 <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
Message-ID: <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>

On Wed, 7 Jun 2023 04:57:55 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
> > > 
> > > 
> > > We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.
> > 
> > 
> > If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?
> 
> In Window, GC is set when during initialization, i.e., `initGC()` is called, also there is separate `setGraphicsConfiguration() ` method. But unlike `Canvas.setGraphicsConfiguration()`, in window `getAppropriateGraphicsConfiguration()` is not used. So with Window, unlike Canvas setting a GC is quite different and doesn't involve `getAppropriateGraphicsConfiguration()` I hope.

So this bug is not reproduced for Canvas? Then probably we should use the code similar to Canvas.setGraphicsConfiguration in the WIndow class?

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1581826509


From duke at openjdk.org  Thu Jun  8 03:23:47 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 8 Jun 2023 03:23:47 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <n3zdhDO2-cMn6Y7lGDcCY6M2SAtN2z3PD89u9cIYAbU=.1b40426f-8b7a-475e-abe1-cca19e47adfc@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <n3zdhDO2-cMn6Y7lGDcCY6M2SAtN2z3PD89u9cIYAbU=.1b40426f-8b7a-475e-abe1-cca19e47adfc@github.com>
Message-ID: <jrBykZtTpiTIN8R8J-prFZgb6bpYOaJOcKJllf6J6Pc=.d1a8f7b2-5db8-4481-82da-085d8959d2e6@github.com>

On Wed, 7 Jun 2023 17:54:18 GMT, Phil Race <prr at openjdk.org> 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
>
> test/jdk/javax/swing/regtesthelpers/JRobot.java line 260:
> 
>> 258:      */
>> 259:     public void convertRectToScreen(Rectangle r, Component c) {
>> 260:         AtomicReference<Point> p = new AtomicReference<>();
> 
> So this change must be documented on all affected entry points, so that people understand
> what it does.
> Also touching Robot means you need to run ALL tests that use this utility and make sure you didn't break any. 
> Have you done that ?

Thanks @prrace for the reviews, 
I have added EDT support for 'getCenterPoint' and 'convertRectToScreen' functions, executed all the tests which are using this function and confirmed its working.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1222406811


From psadhukhan at openjdk.org  Thu Jun  8 03:50:35 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 03:50:35 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v16]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Address hashcode review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/4683844d..9d03fa86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=14-15

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

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


From psadhukhan at openjdk.org  Thu Jun  8 03:56:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 03:56:57 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <PFEApieGh6R4MHLi1MTzjx5vPrdHdv0nqJJb2WttfTc=.1307b820-2d79-4f8e-bbc7-d78353a24404@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <PFEApieGh6R4MHLi1MTzjx5vPrdHdv0nqJJb2WttfTc=.1307b820-2d79-4f8e-bbc7-d78353a24404@github.com>
Message-ID: <1fsgA4j9tXPzGgXxdcfs9KgoPGJ4WrxFk_vSTK5ERyc=.56d5fedc-cca7-4f9e-96e0-2c06e2b1eb03@github.com>

On Tue, 6 Jun 2023 22:31:31 GMT, Phil Race <prr at openjdk.org> wrote:

> Please confirm this test (and all other relevant tests) still pass. Approving in anticipation of confirmation of the above.

Yes, all "clientlibs" test passed along with this test

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

PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1581850603


From psadhukhan at openjdk.org  Thu Jun  8 03:56:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 03:56:58 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
 <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
Message-ID: <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>

On Wed, 7 Jun 2023 17:11:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> No, it doesn't. For some reason, both `100%` and `200%` are parsed so that `span = 1.0`.
>> 
>> Let's leave it as is then. It handles the most common case.
>> 
>> Handling a space before the percent sign can be postponed to a later fix.
>
> Aha, the value is capped at 100%:
> 
> https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2627-L2628
> 
> This is why 200% is parsed as if it were 100%.
> 
> The following code
> 
>         public boolean equals(Object val) {
>             return val instanceof CSS.LengthValue lu
>                    && percentage == lu.percentage
>                    && span == lu.span
>                    && Objects.equals(units, lu.units);
>         }
> 
> works correctly if you modify this line in the test
> 
> https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java#L86
> 
> to
> 
>             {"margin-top: 100%", "margin-top: 50%"},
> 
> 
> The above code also handles the case `"margin-top: 50 %"` correctly.

I had already made that observation in this [comment ](https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093) few days back in case you overlooked
Also, I kept the percentage check for string even though it fails for "space" within string because it seems "space" is not valid in between % value but we can go beyond 100% ie `50 %` is not valid but `200%` is,
 as per https://developer.mozilla.org/en-US/docs/Web/CSS/margin-top
where if you specify `margin-top: 50 %` and then go to other block and come back, you will get a `"X"` but
`margin-top: 200%` is ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222421015


From aivanov at openjdk.org  Thu Jun  8 06:51:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 06:51:01 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
 <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
 <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>
Message-ID: <C7XCSOonVfS8SRDBJ8Zg4VcWQzsXhOcAq7VjMhosTuA=.4359c541-915b-4583-b880-70308ea0dd00@github.com>

On Thu, 8 Jun 2023 03:52:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Aha, the value is capped at 100%:
>> 
>> https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2627-L2628
>> 
>> This is why 200% is parsed as if it were 100%.
>> 
>> The following code
>> 
>>         public boolean equals(Object val) {
>>             return val instanceof CSS.LengthValue lu
>>                    && percentage == lu.percentage
>>                    && span == lu.span
>>                    && Objects.equals(units, lu.units);
>>         }
>> 
>> works correctly if you modify this line in the test
>> 
>> https://github.com/openjdk/jdk/blob/4683844d8a26b56c903f6a67aadb159c81c2a2b8/test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java#L86
>> 
>> to
>> 
>>             {"margin-top: 100%", "margin-top: 50%"},
>> 
>> 
>> The above code also handles the case `"margin-top: 50 %"` correctly.
>
> I had already made that observation in this [comment ](https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093) few days back in case you overlooked
> Also, I kept the percentage check for string even though it fails for "space" within string because it seems "space" is not valid in between % value but we can go beyond 100% ie `50 %` is not valid but `200%` is,
>  as per https://developer.mozilla.org/en-US/docs/Web/CSS/margin-top
> where if you specify `margin-top: 50 %` and then go to other block and come back, you will get a `"X"` but
> `margin-top: 200%` is ok

> I had already made that observation in this https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093few days back in case you overlooked

I did miss this comment. Sorry about that.

Even though space between the value and the percent sign or the units is invalid (I couldn't find it quickly in the W3C spec for CSS), you should compare the parsed values. We pass `100%` and `200%` but the parsed value is `100%` in both cases ? **the attribute sets are indeed *equal***. If you apply either attribute set to a document, you'll get the same result. Does it make sense?

There could be other cases where the computed/parsed values are the same even though the input is different, for example `"font-size: medium"` has a numeric value in points or pixels, so the attribute set with the same value should be equal, don't you agree?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222531449


From psadhukhan at openjdk.org  Thu Jun  8 07:01:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 07:01:59 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <C7XCSOonVfS8SRDBJ8Zg4VcWQzsXhOcAq7VjMhosTuA=.4359c541-915b-4583-b880-70308ea0dd00@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
 <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
 <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>
 <C7XCSOonVfS8SRDBJ8Zg4VcWQzsXhOcAq7VjMhosTuA=.4359c541-915b-4583-b880-70308ea0dd00@github.com>
Message-ID: <sTqeXD4BnAD9h8pbA-sERx678VzhQMILUCgIGdR6a8I=.2a8cf4ae-3b36-4115-9003-275fc2618629@github.com>

On Thu, 8 Jun 2023 06:47:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I had already made that observation in this [comment ](https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093) few days back in case you overlooked
>> Also, I kept the percentage check for string even though it fails for "space" within string because it seems "space" is not valid in between % value but we can go beyond 100% ie `50 %` is not valid but `200%` is,
>>  as per https://developer.mozilla.org/en-US/docs/Web/CSS/margin-top
>> where if you specify `margin-top: 50 %` and then go to other block and come back, you will get a `"X"` but
>> `margin-top: 200%` is ok
>
>> I had already made that observation in this https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093few days back in case you overlooked
> 
> I did miss this comment. Sorry about that.
> 
> Even though space between the value and the percent sign or the units is invalid (I couldn't find it quickly in the W3C spec for CSS), you should compare the parsed values. We pass `100%` and `200%` but the parsed value is `100%` in both cases ? **the attribute sets are indeed *equal***. If you apply either attribute set to a document, you'll get the same result. Does it make sense?
> 
> There could be other cases where the computed/parsed values are the same even though the input is different, for example `"font-size: medium"` has a numeric value in points or pixels, so the attribute set with the same value should be equal, don't you agree?

I am not sure on 100%, 200% ie >= 100% should be considered equal or not..I could not find in spec...also the URL I gave has 200% as valid value...so as of now I have considered what is normal and made `equals` return false for different percentages irrespective of < or > 100%..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222543625


From aivanov at openjdk.org  Thu Jun  8 07:22:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 07:22:05 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v16]
In-Reply-To: <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>
Message-ID: <P8f18_3yJp0E0tITCT7JEOI-lx5vrXpm3g28hpuD0dE=.35a9c984-e5ac-45f6-b945-5a998581438d@github.com>

On Thu, 8 Jun 2023 03:50:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address hashcode review comment

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2218:

> 2216:         @Override
> 2217:         public int hashCode() {
> 2218:             int hashCode = Float.hashCode(value) | Boolean.hashCode(index) ;

Suggestion:

            int hashCode = Float.hashCode(value) | Boolean.hashCode(index);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222561651


From aivanov at openjdk.org  Thu Jun  8 07:22:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 07:22:08 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <sTqeXD4BnAD9h8pbA-sERx678VzhQMILUCgIGdR6a8I=.2a8cf4ae-3b36-4115-9003-275fc2618629@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
 <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
 <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>
 <C7XCSOonVfS8SRDBJ8Zg4VcWQzsXhOcAq7VjMhosTuA=.4359c541-915b-4583-b880-70308ea0dd00@github.com>
 <sTqeXD4BnAD9h8pbA-sERx678VzhQMILUCgIGdR6a8I=.2a8cf4ae-3b36-4115-9003-275fc2618629@github.com>
Message-ID: <S_6SAjiNqU8t5qjsCyKT_fE_0fWVmS3B1yeCbhCwml8=.c78372a9-9222-47ca-a543-5ce2c21b4dd4@github.com>

On Thu, 8 Jun 2023 06:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> I had already made that observation in this https://github.com/openjdk/jdk/pull/13405#discussion_r1213916093few days back in case you overlooked
>> 
>> I did miss this comment. Sorry about that.
>> 
>> Even though space between the value and the percent sign or the units is invalid (I couldn't find it quickly in the W3C spec for CSS), you should compare the parsed values. We pass `100%` and `200%` but the parsed value is `100%` in both cases ? **the attribute sets are indeed *equal***. If you apply either attribute set to a document, you'll get the same result. Does it make sense?
>> 
>> There could be other cases where the computed/parsed values are the same even though the input is different, for example `"font-size: medium"` has a numeric value in points or pixels, so the attribute set with the same value should be equal, don't you agree?
>
> I am not sure on 100%, 200% ie >= 100% should be considered equal or not..I could not find in spec...also the URL I gave has 200% as valid value...so as of now I have considered what is normal and made `equals` return false for different percentages irrespective of < or > 100%..

I also think that capping at 100% is wrong but it's another bug.

Currently, both 100% and 200% result in attribute sets which behave as if both were 100%, therefore they should be equal. I strongly believe we should compare the parsed values not the input string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222563667


From aivanov at openjdk.org  Thu Jun  8 07:25:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 07:25:00 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v16]
In-Reply-To: <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>
Message-ID: <yau0cZ9_ptwLXn49vh5ENIxPZ2dCP8Zafj1T3CJUMzs=.36fef665-3ad0-419b-a552-b23148e83a97@github.com>

On Thu, 8 Jun 2023 03:50:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address hashcode review comment

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:

> 2682:             if (units != null) {
> 2683:                 hashCode |= units.hashCode();
> 2684:             }

In previous cases, you used `Objects.hashCode(units)`, I presume, to avoid explicit null-check and branches. Wouldn't it work here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222566787


From serb at openjdk.org  Thu Jun  8 07:40:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 07:40:58 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v12]
In-Reply-To: <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
Message-ID: <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>

On Thu, 8 Jun 2023 00:40:24 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> So, we ask Windows for the component image based on a particular DPI , not some specific size. The basic premise here is that we expect Windows returning image that would match the DPI , and then we perform our calculations accordingly. In the case above (if Region.clipRound is used) that basic premise is not met (if w, h=19) due to us calculating a DPI value of 140 which is closer to 120 or 125% scaling while our scaling is acytually 150% and Windows returns us a smaller size of the component than expected. So we don't need to add extra code to rescale , I believe. If we provide windows with correctly calculated DPI value which my code change does it should work fine as Windows will give us image of the correct size.


=( I am still missing something.
This is the code we discussing:

            int w = (int) Math.floor(destWidth + 0.5);
            int h = (int) Math.floor(destHeight + 0.5);

It calculates the size of the image we would like to render, it does not calculate the DPI. So if our component is 100x100 in pixels we create the image of that [size](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155) and put it into the cache. Later when want to render that image to the place where the component of size 100x100 is located we request it from the PainterMultiResolutionCachedImage.getResolutionVariant.

After this patch we create the image of one size using ceil, then request the image using floor, and it is somehow affected by the fact that the WIndows may return something different than requested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1222582779


From jwaters at openjdk.org  Thu Jun  8 07:45:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 07:45:53 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <uMc6HjzFQDaaJKL5x2nU2Fa3cxfJzXPzTrAvYlEmDCc=.3beabc5d-eb39-4e5f-8100-7dc797a23a86@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1582066068


From jwaters at openjdk.org  Thu Jun  8 07:45:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 07:45:54 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <O0sIQsDEZpGqz0FPHnk-iENdjkFXlB6I9JKPBDO5GeY=.9332e059-0a31-4167-9548-66eec623a072@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1582066400


From tr at openjdk.org  Thu Jun  8 08:01:50 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Jun 2023 08:01:50 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
 <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
 <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>
Message-ID: <n0JoCpPTHEOyCsRerU2PwyfuX6Yi91CLTLJTQB6a3c0=.599f207a-90ce-4d3d-8385-d0823f150100@github.com>

On Thu, 8 Jun 2023 03:12:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > > > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
> > > > 
> > > > 
> > > > We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.
> > > 
> > > 
> > > If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?
> > 
> > 
> > In Window, GC is set when during initialization, i.e., `initGC()` is called, also there is separate `setGraphicsConfiguration() ` method. But unlike `Canvas.setGraphicsConfiguration()`, in window `getAppropriateGraphicsConfiguration()` is not used. So with Window, unlike Canvas setting a GC is quite different and doesn't involve `getAppropriateGraphicsConfiguration()` I hope.
> 
> So this bug is not reproduced for Canvas? Then probably we should use the code similar to Canvas.setGraphicsConfiguration in the WIndow class?

Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1582088539


From prappo at openjdk.org  Thu Jun  8 08:18:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:18:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v3]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <dMVI5gkY6g1Rua907np654TLzSOFYYSVuFUmj3OxI_Y=.eeb25216-e583-40f0-9f7f-5a2d095039ce@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo 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 seven additional commits since the last revision:

 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - Counterbalance changes to method comments algorithm
   
   The changes are in the JDK API Documentation.
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/c0fc69c2..011d7982

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

  Stats: 17117 lines in 199 files changed: 16677 ins; 145 del; 295 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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


From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v4]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <YCoswj2IrhNiZsAIFLp0fYU3rZiMj7nlywtP_JanSRw=.274888fc-181c-42a6-886e-416bc89d505d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: use utils directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/011d7982..d579a83c

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

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

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


From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
Message-ID: <0nAoH6Na1dRqIGEGYd2-DpPBZb7AfdjApu40jdUkmzM=.37205779-ae2f-4577-86a8-8e8d592e7576@github.com>

On Wed, 7 Jun 2023 18:55:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:
> 
>> 108:             for (Element e : methods) {
>> 109:                 ExecutableElement m = (ExecutableElement) e;
>> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {
> 
> Note that `configuration.utils` is available as `utils`

Done in d579a83cc4a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222652470


From prappo at openjdk.org  Thu Jun  8 09:26:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: DocLint terminology

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/d579a83c..93adde63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=03-04

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

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


From prappo at openjdk.org  Thu Jun  8 09:26:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>

On Wed, 7 Jun 2023 20:23:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:
> 
>> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
>> 74:         setAutomaticCheckNoStacktrace(true);
>> 75:         { // DocLint is on
> 
> "on" -> "explicit"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:
> 
>> 83:             }
>> 84:         }
>> 85:         // DocLint is off
> 
> "off" -> "default"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
> 
>> 287: 
>> 288:     /*
>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
> 
> possible typo: do you mean "indirect"

I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.

I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.

By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.

While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703693
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703773
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222700845


From prappo at openjdk.org  Thu Jun  8 09:31:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v6]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eBdzCAsFsRLgFpL57dGSEb6JSNCFN97DG66FfGhcIc0=.a1c66346-3faf-4e61-99cb-ea346c546dcd@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  suggestion: vocabulary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/93adde63..3da4f473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=04-05

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

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


From prappo at openjdk.org  Thu Jun  8 09:31:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
Message-ID: <dW06V3UKubxH8ow0uco0U7JqH-03Yos7o2nVtR17biY=.558d5dca-e1cf-4a06-8f0c-5be1ba6b89cf@github.com>

On Thu, 8 Jun 2023 09:18:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
>> 
>>> 287: 
>>> 288:     /*
>>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
>> 
>> possible typo: do you mean "indirect"
>
> I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.
> 
> I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.
> 
> By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.
> 
> While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

Have a look at this commit: 3da4f473a7c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222709203


From dfuchs at openjdk.org  Thu Jun  8 09:36:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Jun 2023 09:36:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
Message-ID: <PLCf0TKvR88eBAkckrd1Er8kTIju2SRe3KrpF937NRY=.aa620b43-011b-4c94-baf5-31d72fe881e3@github.com>

On Thu, 8 Jun 2023 09:26:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: DocLint terminology

I will only comment on the changes to the `java.base` classes.

I had a look at the changes to these and they looked right to me. Though I?m not an expert on collections it seemed that you picked the right ?semantically closer parent? to inherit from.
Probably @stuart-marks  could give a more authoritative opinion.

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

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1469424115


From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: remove unduly restrictive warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/3da4f473..dea776e2

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

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

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


From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
 <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
Message-ID: <5_hHiDRF_JOTG6DcmG_2ONSv9ZMcLJyYafTs5q7VNj4=.5149617c-4015-4f9b-b518-7d316a1e92eb@github.com>

On Wed, 7 Jun 2023 21:39:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
>> 
>> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
>> 
>> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.
>
>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)
> 
> Thanks for tying these together; I had not realized they were related.

As agreed out of band, I removed that check and the test for now in dea776e285b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222737390


From psadhukhan at openjdk.org  Thu Jun  8 10:28:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 10:28:17 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v16]
In-Reply-To: <yau0cZ9_ptwLXn49vh5ENIxPZ2dCP8Zafj1T3CJUMzs=.36fef665-3ad0-419b-a552-b23148e83a97@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <gdsP6lwsC72MtXQ5m5GO5RzgEDvn5zNZxzJLh_nIHGo=.625afbd8-ae1e-49b2-843f-99e23d8b9209@github.com>
 <yau0cZ9_ptwLXn49vh5ENIxPZ2dCP8Zafj1T3CJUMzs=.36fef665-3ad0-419b-a552-b23148e83a97@github.com>
Message-ID: <VsNSZKdctFTw1SbTr1rJp8bw1xku4x-UT38WGNBqHoM=.b33b0ec4-f4da-4a21-81e1-6bfe06f5dd35@github.com>

On Thu, 8 Jun 2023 07:22:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address hashcode review comment
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2684:
> 
>> 2682:             if (units != null) {
>> 2683:                 hashCode |= units.hashCode();
>> 2684:             }
> 
> In previous cases, you used `Objects.hashCode(units)`, I presume, to avoid explicit null-check and branches. Wouldn't it work here too?

Yes, we can do it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222820846


From psadhukhan at openjdk.org  Thu Jun  8 10:28:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 10:28:17 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v17]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <zbg9N1HQ7KxtuAl_z3Cvfl2gP2TEg9SNGBGDENa9-6k=.b47f2fff-73f1-4d5c-82fb-67b2ebfc583a@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Fix percentage equality as per span parsed value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/9d03fa86..94249f77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=15-16

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

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


From psadhukhan at openjdk.org  Thu Jun  8 10:28:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 10:28:18 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v15]
In-Reply-To: <S_6SAjiNqU8t5qjsCyKT_fE_0fWVmS3B1yeCbhCwml8=.c78372a9-9222-47ca-a543-5ce2c21b4dd4@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <YGGQAQvpaIqugKNfjPLjwtVR6MC2xd6A0wT6nl2F0_8=.636915d3-847f-42d2-961b-1c9f9fd27a31@github.com>
 <3zYJWMEoS50zPZsmtqlaI0nLw_eWzniSvYVhSHw4KOQ=.39031a62-faf0-4f56-af40-35d4ee3e8ab2@github.com>
 <uJdVE1ojc8EE8v_srW_nExuKJ-mAI_KuWFAvm4KdfOU=.8a35c608-f4a2-4bb0-aa4e-059f1c642a42@github.com>
 <pfkRnlBxDhWICW160__B-j-mPBjJNGR3Zb2u4ylycgE=.b59316c4-2f3c-4fd5-a708-837037aa499a@github.com>
 <cL2uuvxIp6m9Sa9gDYwrrLIPAwLeVYJ85INZcDeR_5M=.58e2958e-7384-48f2-b76f-561edfff2bc5@github.com>
 <ipZZbkpudTw8xl6oWOI0pVAYe7opBGjqLv3wddQ81vI=.3449e665-f27c-48de-886f-af3d65dab2f0@github.com>
 <C7XCSOonVfS8SRDBJ8Zg4VcWQzsXhOcAq7VjMhosTuA=.4359c541-915b-4583-b880-70308ea0dd00@github.com>
 <sTqeXD4BnAD9h8pbA-sERx678VzhQMILUCgIGdR6a8I=.2a8cf4ae-3b36-4115-9003-275fc2618629@github.com>
 <S_6SAjiNqU8t5qjsCyKT_fE_0fWVmS3B1yeCbhCwml8=.c78372a9-9222-47ca-a543-5ce2c21b4dd4@github.com>
Message-ID: <PeRrrTw5Fj8Cp6bVD7NGclHn_lYkXADNLtAkFJ3aocY=.b2b3000f-8b86-4f8f-befc-3ab17dd3c310@github.com>

On Thu, 8 Jun 2023 07:19:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I am not sure on 100%, 200% ie >= 100% should be considered equal or not..I could not find in spec...also the URL I gave has 200% as valid value...so as of now I have considered what is normal and made `equals` return false for different percentages irrespective of < or > 100%..
>
> I also think that capping at 100% is wrong but it's another bug.
> 
> Currently, both 100% and 200% result in attribute sets which behave as if both were 100%, therefore they should be equal. I strongly believe we should compare the parsed values not the input string.

OK. Fair enough..guess CSS implementation and equality should match...Modified...
Upper capping and equality can be looked at later if needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222823156


From alanb at openjdk.org  Thu Jun  8 10:36:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:36:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/TreeMap.java line 1199:

> 1197:      * {@code add} or {@code addAll} operations.
> 1198:      *
> 1199:      * @return {@inheritDoc SortedMap}

An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222847956


From alanb at openjdk.org  Thu Jun  8 10:50:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:50:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <r_kzWNFCCjU2vL3e8WUtgR9dRPSLzg2HWRArVA8fTIk=.f2a36710-a531-4714-8ac6-e825b97ee1c3@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:

> 633:      * @return {@inheritDoc BlockingDeque}
> 634:      */
> 635:     public boolean offer(E e) {

Does this work for @param tags too? Just curious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222860792


From aivanov at openjdk.org  Thu Jun  8 11:13:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 11:13:00 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v17]
In-Reply-To: <zbg9N1HQ7KxtuAl_z3Cvfl2gP2TEg9SNGBGDENa9-6k=.b47f2fff-73f1-4d5c-82fb-67b2ebfc583a@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <zbg9N1HQ7KxtuAl_z3Cvfl2gP2TEg9SNGBGDENa9-6k=.b47f2fff-73f1-4d5c-82fb-67b2ebfc583a@github.com>
Message-ID: <M0EnP6BRJt-y93hzFi-8Sq9QZQGUDjhIqle8VTG7WLE=.57a1db7b-0238-4984-bbc4-e4722dcdd4b5@github.com>

On Thu, 8 Jun 2023 10:28:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix percentage equality as per span parsed value

Thank you for updating the code.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2223:

> 2221:             }
> 2222:             return hashCode;
> 2223:         }

To be consistent with `LengthValue` and `LengthUnit`:
Suggestion:

        public int hashCode() {
            return Float.hashCode(value)
                   | Boolean.hashCode(index)
                   | Objects.hashCode(lu);
        }

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2690:

> 2688:             return val instanceof CSS.LengthValue lu
> 2689:                    && span == lu.span
> 2690:                    && Objects.equals(units, lu.units);

[The `percentage` field](https://github.com/openjdk/jdk/pull/13405#discussion_r1221932524) must also be part of `equals`:
Suggestion:

            return val instanceof CSS.LengthValue lu
                   && percentage == lu.percentage
                   && span == lu.span
                   && Objects.equals(units, lu.units);

You have included it in `hashCode`.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 3090:

> 3088:         public int hashCode() {
> 3089:             return Float.hashCode(value) | Short.hashCode(type)
> 3090:                    | Objects.hashCode(units);

To be consistent with other similar methods above:
Suggestion:

            return Float.hashCode(value)
                   | Short.hashCode(type)
                   | Objects.hashCode(units);

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1469660047
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222878939
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222884735
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222886163


From aivanov at openjdk.org  Thu Jun  8 11:22:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 11:22:52 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

I'll take a look? hopefully next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1582402901


From aivanov at openjdk.org  Thu Jun  8 11:22:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 11:22:52 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <5JbzkQzzF4uMm-_vQnjMYCiWPqxn_yxp0uzjrM91Jlo=.8beaf5f2-b25f-4489-850b-efa609f33d87@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

I'll take a look? hopefully next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1582402225


From aivanov at openjdk.org  Thu Jun  8 11:29:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 11:29:02 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v17]
In-Reply-To: <M0EnP6BRJt-y93hzFi-8Sq9QZQGUDjhIqle8VTG7WLE=.57a1db7b-0238-4984-bbc4-e4722dcdd4b5@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <zbg9N1HQ7KxtuAl_z3Cvfl2gP2TEg9SNGBGDENa9-6k=.b47f2fff-73f1-4d5c-82fb-67b2ebfc583a@github.com>
 <M0EnP6BRJt-y93hzFi-8Sq9QZQGUDjhIqle8VTG7WLE=.57a1db7b-0238-4984-bbc4-e4722dcdd4b5@github.com>
Message-ID: <067K6oIq64ZERv_cVfhhAQQkyelKI0_FvlAZuXjsrcA=.d5b864b9-476b-4db9-8def-3ef7cfc8434b@github.com>

On Thu, 8 Jun 2023 11:05:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix percentage equality as per span parsed value
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2690:
> 
>> 2688:             return val instanceof CSS.LengthValue lu
>> 2689:                    && span == lu.span
>> 2690:                    && Objects.equals(units, lu.units);
> 
> [The `percentage` field](https://github.com/openjdk/jdk/pull/13405#discussion_r1221932524) must also be part of `equals`:
> Suggestion:
> 
>             return val instanceof CSS.LengthValue lu
>                    && percentage == lu.percentage
>                    && span == lu.span
>                    && Objects.equals(units, lu.units);
> 
> You have included it in `hashCode`.

If `percentage` isn't taken into account, the pair `{"margin-top: 100%", "margin-top: 1"}` is considered equal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222907544


From prappo at openjdk.org  Thu Jun  8 11:34:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:34:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
Message-ID: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>

On Thu, 8 Jun 2023 10:33:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: remove unduly restrictive warning
>
> src/java.base/share/classes/java/util/TreeMap.java line 1199:
> 
>> 1197:      * {@code add} or {@code addAll} operations.
>> 1198:      *
>> 1199:      * @return {@inheritDoc SortedMap}
> 
> An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc  PR. I was simply trying to keep JDK API documentation unchanged.

One thing with the `@return` documentation inherited from SortedMap is that compared to the first sentence of TreeMap, it provides one extra bit of information: a set view of the mappings contained in this map, **sorted in ascending key order**. In order to keep that bit, the suggested inline `{@return ...}` should include more than just the first sentence.

> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
> 
>> 633:      * @return {@inheritDoc BlockingDeque}
>> 634:      */
>> 635:     public boolean offer(E e) {
> 
> Does this work for @param tags too? Just curious.

The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:

    @param e {@inheritDoc BlockingDeque}

then the answer is that it's not necessary for keeping the API documentation unchanged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222908801
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222910706


From prappo at openjdk.org  Thu Jun  8 11:41:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:41:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <zmbCcrz9xOw4-kohog4kdkGWwUqpjjRoDxgG7QvADo4=.8b3ecb99-46a5-40a2-b27d-83983bdf4f4d@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

@Martin-Buchholz, could you please have a look at changes to collections and, in particular, those in java.util.concurrent.*?

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582426421


From psadhukhan at openjdk.org  Thu Jun  8 11:58:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 11:58:18 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v18]
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <8TBGWFnfQzfBplUdfPVPDCjT90QTdwp0mlbUTBwfKOQ=.3278e015-f839-4313-94cf-bea0d3d3dc4e@github.com>

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

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

  Fix per review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13405/files
  - new: https://git.openjdk.org/jdk/pull/13405/files/94249f77..bc2c13b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=16-17

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

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


From psadhukhan at openjdk.org  Thu Jun  8 11:58:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2023 11:58:18 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v17]
In-Reply-To: <067K6oIq64ZERv_cVfhhAQQkyelKI0_FvlAZuXjsrcA=.d5b864b9-476b-4db9-8def-3ef7cfc8434b@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <zbg9N1HQ7KxtuAl_z3Cvfl2gP2TEg9SNGBGDENa9-6k=.b47f2fff-73f1-4d5c-82fb-67b2ebfc583a@github.com>
 <M0EnP6BRJt-y93hzFi-8Sq9QZQGUDjhIqle8VTG7WLE=.57a1db7b-0238-4984-bbc4-e4722dcdd4b5@github.com>
 <067K6oIq64ZERv_cVfhhAQQkyelKI0_FvlAZuXjsrcA=.d5b864b9-476b-4db9-8def-3ef7cfc8434b@github.com>
Message-ID: <nYkDzwJgIsAMaUirzG4yd6YqwsElJ8MaWMLDEWaWcfQ=.e9e6e291-693b-4ceb-bd3e-7e6c55b7fd7d@github.com>

On Thu, 8 Jun 2023 11:26:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2690:
>> 
>>> 2688:             return val instanceof CSS.LengthValue lu
>>> 2689:                    && span == lu.span
>>> 2690:                    && Objects.equals(units, lu.units);
>> 
>> [The `percentage` field](https://github.com/openjdk/jdk/pull/13405#discussion_r1221932524) must also be part of `equals`:
>> Suggestion:
>> 
>>             return val instanceof CSS.LengthValue lu
>>                    && percentage == lu.percentage
>>                    && span == lu.span
>>                    && Objects.equals(units, lu.units);
>> 
>> You have included it in `hashCode`.
>
> If `percentage` isn't taken into account, the pair `{"margin-top: 100%", "margin-top: 1"}` is considered equal. (And it essentially is; however, I think we should include the `percentage` field, it is part of the object and the behaviour will be different.)
> 
> By the way, this is another quirk of Swing's CSS implementation: in the CSS spec, values without units are considered an error except for a few cases where such usage is specifically allowed.

Updated..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1222934068


From aivanov at openjdk.org  Thu Jun  8 12:01:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 12:01:02 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode() [v18]
In-Reply-To: <8TBGWFnfQzfBplUdfPVPDCjT90QTdwp0mlbUTBwfKOQ=.3278e015-f839-4313-94cf-bea0d3d3dc4e@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
 <8TBGWFnfQzfBplUdfPVPDCjT90QTdwp0mlbUTBwfKOQ=.3278e015-f839-4313-94cf-bea0d3d3dc4e@github.com>
Message-ID: <i00Qeh_bIlAz6UjJWemh_yCsUYRhZ-YzNMbJ-9Znz0Y=.361ba758-1da9-45c9-8f26-a9bed77fe620@github.com>

On Thu, 8 Jun 2023 11:58:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
>> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
>> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
>> 
>> All jtreg/jck tests are ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix per review comment

Perfect! Looks to me now.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1469749282


From prappo at openjdk.org  Thu Jun  8 12:17:57 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 12:17:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <ZNWvGneK5nZuriiAOR-2z51cMWFWZATiyFpoSX9EnZc=.62c29530-bfb4-4b34-80c1-16ac1747b5b6@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

Note that the change to "method comments algorithm" uncovers and fixes some bugs to Object- or Object-like- methods. 

Using the provided [before][] and [after][] outputs, compare documentation for:

 * toString() in java.time.chrono.{Hijrah,Japanese,Minguo,ThaiBuddhist}Date
 * hashCode() in Hashtable, ConcurrentHashMap.KeySetView, java.util.jar.Attributes, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * equals() in ConcurrentHashMap.KeySetView, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * clone() in javax.management.ImmutableDescriptor, javax.management.modelmbean.DescriptorSupport, javax.naming.directory.BasicAttribute, javax.naming.directory.BasicAttributes
 
Perhaps some of those could be further refined using directed documentation inheritance. For example, ConcurrentHashMap.KeySetView is first and foremost a set and only then a collection. That suggests that the documentation for Object-like methods could be inherited from (some) set rather than a "generic" collection.

Also, the javax.management.ImmutableDescriptor and javax.management.modelmbean.DescriptorSupport clone methods require some attention from area experts. It's likely that those methods' doc comments need to fully inherit documentation from Descriptor.clone(), not just its `@return` tag.

[before]: https://cr.openjdk.org/~prappo/8285368/1/api
[after]: https://cr.openjdk.org/~prappo/8285368/2/api

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582477351


From jwaters at openjdk.org  Thu Jun  8 13:03:51 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 13:03:51 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <xv7WBNt7nmHXlDG1P5ma-TLqGuFhkvX6MeM2I7c9eow=.5c335070-262e-495a-9ef4-4c4c33e3f381@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Thanks aivanov, no rush haha

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1582540074


From alanb at openjdk.org  Thu Jun  8 13:37:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 13:37:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <wxje5E9he5rhzViprJqwj4Q6fC8Kwd9am_ZxVfje9dU=.96fc348e-d257-4fc1-840b-4961c1e83720@github.com>

On Thu, 8 Jun 2023 11:27:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc PR. I was simply trying to keep JDK API documentation unchanged.

Understood, it was just a passing comment that TreeMap::entrySet overrides the description so it's specifying what it returns and using inherited text for the @return description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223053378


From prappo at openjdk.org  Thu Jun  8 14:47:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <82i8za9caZsJgAkr0hX9cR-ItoN94SJdcsHW0EfTswc=.8477eb23-93a7-4ac5-a558-384f9d956371@github.com>

On Wed, 7 Jun 2023 20:33:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:
> 
>> 271:             }
>> 272:         }
>> 273:         System.err.println("Test suite root: " + p);
> 
> You might want to use `JavadocTester.out` instead of `System.err`

Fixed in cccffa660a8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223144388


From prappo at openjdk.org  Thu Jun  8 14:47:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: use JavadocTester.out
  
  Also, trivially fixes grammar (word order) in a comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/dea776e2..cccffa66

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

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

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


From aivanov at openjdk.org  Thu Jun  8 15:18:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 15:18:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>

On Thu, 8 Jun 2023 11:29:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
>> 
>>> 633:      * @return {@inheritDoc BlockingDeque}
>>> 634:      */
>>> 635:     public boolean offer(E e) {
>> 
>> Does this work for @param tags too? Just curious.
>
> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
> 
>     @param e {@inheritDoc BlockingDeque}
> 
> then the answer is that it's not necessary for keeping the API documentation unchanged.

I admit I can't parse this sentence:

> then the answer is that it's not necessary for keeping the API documentation unchanged.

Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?

You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.

So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223197961


From prappo at openjdk.org  Thu Jun  8 15:49:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:49:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
Message-ID: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>

On Thu, 8 Jun 2023 15:16:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
>> 
>>     @param e {@inheritDoc BlockingDeque}
>> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>
> I admit I can't parse this sentence:
> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
> 
> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
> 
> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
> 
> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:

    @param e the element to add

If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.

Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.

Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:

 - javax.imageio.stream.ImageInputStream#flushBefore
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed.
    ```

 - javax.imageio.stream.ImageOutputStream#flushBefore:
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed to the destination.
    ```
Hence, the correction. Does it clarify the matter?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223236596


From prappo at openjdk.org  Thu Jun  8 15:53:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:53:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
Message-ID: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>

On Thu, 8 Jun 2023 15:47:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I admit I can't parse this sentence:
>> 
>>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>> 
>> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
>> 
>> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
>> 
>> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?
>
> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
> 
>     @param e the element to add
> 
> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
> 
> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
> 
> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
> 
>  - javax.imageio.stream.ImageInputStream#flushBefore
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed.
>     ```
> 
>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed to the destination.
>     ```
> Hence, the correction. Does it clarify the matter?

Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:

/** {@inheritDoc} */

It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223241132


From jjg at openjdk.org  Thu Jun  8 19:03:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Jun 2023 19:03:53 GMT
Subject: Integrated: JDK-8305593: Add @spec tags in java.desktop
In-Reply-To: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
References: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
Message-ID: <fuL-K-yYe75v_t5CW0tzq7jQo5eiX12XvkNbx0glrvE=.7cff1404-f088-4c04-a1f6-442fb042cf0c@github.com>

On Wed, 5 Apr 2023 17:29:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files

This pull request has now been integrated.

Changeset: 34f0a6ec
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34f0a6ec6a7d52630e8d6661f9d081abcf57b84a
Stats:     55 lines in 17 files changed: 36 ins; 2 del; 17 mod

8305593: Add @spec tags in java.desktop

Reviewed-by: prr

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

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


From jiangli at openjdk.org  Thu Jun  8 20:34:15 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 8 Jun 2023 20:34:15 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c4e65425...c664c601

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

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=06
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

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


From rmahajan at openjdk.org  Thu Jun  8 20:41:49 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 8 Jun 2023 20:41:49 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v12]
In-Reply-To: <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
 <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
Message-ID: <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>

On Thu, 8 Jun 2023 07:37:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So, we ask Windows for the component image based on a particular DPI , not some specific size.
>> The basic premise here is that we expect Windows returning image that would match the DPI , and then we perform our calculations accordingly. In the case above (if Region.clipRound is used) that basic premise is not met (if w, h=19) due to us calculating a DPI value of 140 which is closer to 120 or 125% scaling while our scaling is acytually 150% and Windows returns us a smaller size of the component than expected.
>> So we don't need to add extra code to rescale , I believe.
>> If we provide windows with correctly calculated DPI value which my code change does it should work fine as Windows will give us image of the correct size.
>
>> So, we ask Windows for the component image based on a particular DPI , not some specific size. The basic premise here is that we expect Windows returning image that would match the DPI , and then we perform our calculations accordingly. In the case above (if Region.clipRound is used) that basic premise is not met (if w, h=19) due to us calculating a DPI value of 140 which is closer to 120 or 125% scaling while our scaling is acytually 150% and Windows returns us a smaller size of the component than expected. So we don't need to add extra code to rescale , I believe. If we provide windows with correctly calculated DPI value which my code change does it should work fine as Windows will give us image of the correct size.
> 
> 
> =( I am still missing something.
> This is the code we discussing:
> 
>             int w = (int) Math.floor(destWidth + 0.5);
>             int h = (int) Math.floor(destHeight + 0.5);
> 
> It calculates the size of the image we would like to render, it does not calculate the DPI. So if our component is 100x100 in pixels we create the image of that [size](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155) and put it into the cache. Later when want to render that image to the place where the component of size 100x100 is located we request it from the PainterMultiResolutionCachedImage.getResolutionVariant.
> 
> After this patch we create the image of one size using ceil, then request the image using floor, and it is somehow affected by the fact that the WIndows may return something different than requested.

The above code calls getImage() and passes width and height to it.

This is the flow :
getImage(){CachedPainter.java} -> paintToImage() {XPStyle.java} -> ThemeReader.paintBackground ()

We calculate and set scale in getImage() with this:

Line 172, CachedPainter.java

 if (volatileImage == null) {
     if ((w != baseWidth || h != baseHeight)) {
         g2.scale((double) w / baseWidth, 
                 (double) h / baseHeight); 
     }
     paintToImage(c, image, g2, baseWidth, baseHeight, args);
 }
 
 So, scale changes based on height and width of the image which we get from the
 code you mentioned above.
 
 This scale is then used in paintToImage() to calculate DPI at Line 711 of XPStyle.java:
 
   // Get DPI to pass further to ThemeReader.paintBackground()
  Graphics2D g2d = (Graphics2D) g;
  AffineTransform at = g2d.getTransform();
  int dpi = (int)(at.getScaleX() * 96);
 
 
 This DPI is then used to get the part size from windows and it changes as I explained in the previous comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1223525747


From serb at openjdk.org  Thu Jun  8 21:32:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 21:32:40 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
Message-ID: <3rtm90iPJS7WpoELNS1Lw6H-obZb9EoFzX_E2_Mwe8U=.d6eaee8b-b5b9-484c-ade5-29366d5c1b38@github.com>

On Wed, 7 Jun 2023 19:05:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are two scenarios related to tray icon distortion.
> 
> 1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)
> 
> 2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 
> 
> Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was being used to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
>  
> As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to trigger tray icon update. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.
> 
> TrayIconScalingTest's  instructions have been updated to include both the cases described above.

The old fix did not add any scale checks since the updateNativeImage was called on dpi change only. If we will start to call updateNativeImage on each monitor change event then probably we should recreate images only if the scale was changed?

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

PR Comment: https://git.openjdk.org/jdk/pull/14368#issuecomment-1583371398


From serb at openjdk.org  Thu Jun  8 21:38:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Jun 2023 21:38:51 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <n0JoCpPTHEOyCsRerU2PwyfuX6Yi91CLTLJTQB6a3c0=.599f207a-90ce-4d3d-8385-d0823f150100@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
 <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
 <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>
 <n0JoCpPTHEOyCsRerU2PwyfuX6Yi91CLTLJTQB6a3c0=.599f207a-90ce-4d3d-8385-d0823f150100@github.com>
Message-ID: <psAMQ5IJxw_0rp9NYXmrKbffrEPiCFNzUXN_OPslbRQ=.050f3966-4e9b-485c-8531-eba05c0b82af@github.com>

On Thu, 8 Jun 2023 07:59:01 GMT, Tejesh R <tr at openjdk.org> wrote:

> Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.

The patch which added the getAppropriateGraphicsConfiguration was supposed to fix the same bug but looks like it was implemented for the Canvas only, I think we can do the same thing for the Window class as well. Note that getAppropriateGraphicsConfiguration on all other platforms is noop so it should not affected.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1583390909


From rmahajan at openjdk.org  Thu Jun  8 21:42:17 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 8 Jun 2023 21:42:17 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v13]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <_lWSqeZwmYNsCcFOyD4OxFuL5-sNZ9UCAVXREi1SOJE=.37ea420e-d248-49cc-b42a-23d673be8e79@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  code changes as per suggestions by reviewer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/727836ea..a780bf0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=11-12

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

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


From honkar at openjdk.org  Fri Jun  9 00:08:41 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 9 Jun 2023 00:08:41 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <3rtm90iPJS7WpoELNS1Lw6H-obZb9EoFzX_E2_Mwe8U=.d6eaee8b-b5b9-484c-ade5-29366d5c1b38@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
 <3rtm90iPJS7WpoELNS1Lw6H-obZb9EoFzX_E2_Mwe8U=.d6eaee8b-b5b9-484c-ade5-29366d5c1b38@github.com>
Message-ID: <Y9bbq158lJf7c4MqcNz5_-SptrC2apCq_FAjUdHA_zc=.4cd993b8-9e09-40cc-a7be-f2b1d28f3b72@github.com>

On Thu, 8 Jun 2023 21:29:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There are two scenarios related to tray icon distortion.
>> 
>> 1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)
>> 
>> 2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 
>> 
>> Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was being used to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
>>  
>> As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to trigger tray icon update. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.
>> 
>> TrayIconScalingTest's  instructions have been updated to include both the cases described above.
>
> The old fix did not add any scale checks since the updateNativeImage was called on dpi change only. If we will start to call updateNativeImage on each monitor change event then probably we should recreate images only if the scale was changed?

@mrserb 

> The old fix did not add any scale checks since the updateNativeImage was called on dpi change only. If we will start to call updateNativeImage on each monitor change event then probably we should recreate images only if the scale was changed?

The update for any tray icons happens within `AwtTrayIcon::WmTaskbarCreated()` and for only the 'WM_DISPLAYCHANGE' events forwarded to `AwtTrayIcon::TrayWindowProc` . In case 2, we are ideally switching between 2 different scales because the 2 monitors are at different scales and the taskbar is added to the primary monitor which is at a different scale from the previous one.

I checked the case where both monitors are at same scale and the the primary display is toggled btw the two, WM_DISPLAYCHANGE is received but WmTaskbarCreated() is not called in this scenario and as a result updateNativeImage() is not called as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/14368#issuecomment-1583637563


From serb at openjdk.org  Fri Jun  9 00:16:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Jun 2023 00:16:40 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
Message-ID: <my0wZY-Uzz6Vmb2JgPzt0F5-qRR9j1B7tE_gQSBO9Bw=.421d4742-276f-40b6-88c4-c532e4d90d5c@github.com>

On Wed, 7 Jun 2023 19:05:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are two scenarios related to tray icon distortion.
> 
> 1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)
> 
> 2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 
> 
> Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was used to set `m_bDPIChanged` which is used within  `AwtTrayIcon::WmTaskbarCreated()` to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
>  
> As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to update `m_bDPIChanged`. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.
> 
> TrayIconScalingTest's  instructions have been updated to include both the cases described above.

Marked as reviewed by serb (Reviewer).

Then it looks fine, thank you for clarification.

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

PR Review: https://git.openjdk.org/jdk/pull/14368#pullrequestreview-1470941945
PR Comment: https://git.openjdk.org/jdk/pull/14368#issuecomment-1583654258


From tr at openjdk.org  Fri Jun  9 04:50:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Jun 2023 04:50:54 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <psAMQ5IJxw_0rp9NYXmrKbffrEPiCFNzUXN_OPslbRQ=.050f3966-4e9b-485c-8531-eba05c0b82af@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
 <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
 <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>
 <n0JoCpPTHEOyCsRerU2PwyfuX6Yi91CLTLJTQB6a3c0=.599f207a-90ce-4d3d-8385-d0823f150100@github.com>
 <psAMQ5IJxw_0rp9NYXmrKbffrEPiCFNzUXN_OPslbRQ=.050f3966-4e9b-485c-8531-eba05c0b82af@github.com>
Message-ID: <a9e5bvIhJn4QHFrCyfZVLLzc7jivREvNYfMcHpgxCBA=.aef2dc39-4e6a-459c-b194-030a2d14bad6@github.com>

On Thu, 8 Jun 2023 21:35:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The patch which added the getAppropriateGraphicsConfiguration was supposed to fix the same bug but looks like it was implemented for the Canvas only, I think we can do the same thing for the Window class as well. Note that getAppropriateGraphicsConfiguration on all other platforms is noop so it should not affected.
Hmm, ok then let me work on fixing this. In windows, there is an issue too when we drag a window to another screen like the ellipse becomes an arc. So if  we re using getAppropriateGraphicsConfiguration at setGraphicsConfiguration, that one might as well get solved.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1583970102


From psadhukhan at openjdk.org  Fri Jun  9 05:33:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Jun 2023 05:33:19 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
Message-ID: <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>

> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
> 
> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

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

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14346/files
  - new: https://git.openjdk.org/jdk/pull/14346/files/c70cc5c8..2e169762

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

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

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


From psadhukhan at openjdk.org  Fri Jun  9 05:42:40 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Jun 2023 05:42:40 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
Message-ID: <iYo9rHRTcIm1DNmhfhU00K0ZC_zrEa_6CAtzax0zqV0=.534b9ed0-ae7f-4be2-8d7a-980a50107c2d@github.com>

On Fri, 9 Jun 2023 05:33:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
>> 
>> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
>> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

The issue actually is caused by non-updation of `xOffSet` with correct value..
In MetalTitlePane, the initial `xOffset` is calculated with IMAGE_WIDTH value which is hardcoded to `16` so xOffset was 5+ 16 + 5 = 26 to draw the title string so we just about manage to draw the string outside the bounds of icon width which is `24 ` in `Metalworks Low Vision demo` but when icon image size is increased to `30` same xOffset of `26` is not sufficient so title string is drawn at xOffset 26 but [fillRect](https://github.com/openjdk/jdk/blob/6f492e800597c9ce332b9d5b54c00f551f145a0d/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTitlePane.java#L852-L857) happens for width `30` so icon area fillect clears few pixels from string area and overlap of icon area and string happened.
Fix is to make sure `x Offset` is calculated with correct width so it will become 5 +30 (icon width) + 5 = 40

Issue of not getting large icon proportional to icon size is another issue and will be tackled separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1584004417


From tr at openjdk.org  Fri Jun  9 07:26:52 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Jun 2023 07:26:52 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
Message-ID: <5mC-2XX0GZ7sc1tOXpfdt9vBHNRPcK_YcIic6fk4xfg=.d808ff88-3f33-4bf1-b947-9aa7f446c8a2@github.com>

On Fri, 9 Jun 2023 05:33:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
>> 
>> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
>> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Working as expected.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14346#pullrequestreview-1471390454


From mbaesken at openjdk.org  Fri Jun  9 10:19:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jun 2023 10:19:57 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982
Message-ID: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>

After
[JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
the AIX build fails.
We get

* For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
/aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found

I cannot find endian.h on my AIX machine.
Instead there is <sys/machine.h> which provides some info on byte order etc. instead .

Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.

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

Commit messages:
 - JDK-8309703

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

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


From mbaesken at openjdk.org  Fri Jun  9 10:42:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jun 2023 10:42:59 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
Message-ID: <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>

> After
> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
> the AIX build fails.
> We get
> 
> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
> 
> I cannot find endian.h on my AIX machine.
> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
> 
> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.

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

  use BIG_ENDIAN in define

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14390/files
  - new: https://git.openjdk.org/jdk/pull/14390/files/6706fcdc..4e4bd5d3

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

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

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


From aivanov at openjdk.org  Fri Jun  9 10:43:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 10:43:43 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
Message-ID: <btTKQ21fduOwgEKrBFXCfRfKcuPY-E_RaXN1fLI1lM0=.7512eb92-d2aa-4fd7-9b2c-15b7674be002@github.com>

On Wed, 7 Jun 2023 19:05:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are two scenarios related to tray icon distortion.
> 
> 1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)
> 
> 2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 
> 
> Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was used to set `m_bDPIChanged` which is used within  `AwtTrayIcon::WmTaskbarCreated()` to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
>  
> As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to update `m_bDPIChanged`. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.
> 
> TrayIconScalingTest's  instructions have been updated to include both the cases described above.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14368#pullrequestreview-1471704243


From aivanov at openjdk.org  Fri Jun  9 10:43:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 10:43:44 GMT
Subject: RFR: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <Y9bbq158lJf7c4MqcNz5_-SptrC2apCq_FAjUdHA_zc=.4cd993b8-9e09-40cc-a7be-f2b1d28f3b72@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
 <3rtm90iPJS7WpoELNS1Lw6H-obZb9EoFzX_E2_Mwe8U=.d6eaee8b-b5b9-484c-ade5-29366d5c1b38@github.com>
 <Y9bbq158lJf7c4MqcNz5_-SptrC2apCq_FAjUdHA_zc=.4cd993b8-9e09-40cc-a7be-f2b1d28f3b72@github.com>
Message-ID: <XZgmhiMQXyr7eAZx_78AUPWpod11J0htsnEibNo8vyA=.3486783c-d703-4350-bb3f-3eae08113b42@github.com>

On Fri, 9 Jun 2023 00:05:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> I checked the case where both monitors are at same scale and the the primary display is toggled btw the two, WM_DISPLAYCHANGE is received but WmTaskbarCreated() is not called in this scenario and as a result updateNativeImage() is not called as well.

So, we set the flag that the icon needs updating? but because the scale remains unchanged the Taskbar doesn't broadcast its `"TaskbarCreated"` message, therefore the icons aren't updated.

Sounds reasonable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14368#issuecomment-1584367253


From mdoerr at openjdk.org  Fri Jun  9 10:50:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 9 Jun 2023 10:50:40 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
 <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
Message-ID: <nh2GX3MPeC1gqT0kwW2iMqVabxaM_4LVjmhlisR__Dw=.3587c750-08ac-4083-97ab-293b878457de@github.com>

On Fri, 9 Jun 2023 10:42:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After
>> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
>> the AIX build fails.
>> We get
>> 
>> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
>> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
>> 
>> I cannot find endian.h on my AIX machine.
>> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
>> 
>> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use BIG_ENDIAN in define

LGTM. Thanks for fixing it. We should consider fixing it upstream, too (https://github.com/PipeWire/pipewire).

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14390#pullrequestreview-1471712833


From aivanov at openjdk.org  Fri Jun  9 11:46:42 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 11:46:42 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
Message-ID: <iXZBaXyDKfoioesm61R0lN16xB7rx5PRfSIfCoRKpj4=.97f34f04-f8e0-465f-a85e-549b314ec915@github.com>

On Fri, 9 Jun 2023 05:33:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
>> 
>> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
>> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Marked as reviewed by aivanov (Reviewer).

src/demo/share/jfc/Metalworks/BigContrastMetalTheme.java line 128:

> 126:         table.put("PasswordField.border", textBorder);
> 127:         table.put("TextArea.border", textBorder);
> 128:         table.put("TextPane.font", controlFont);

Does this change also contributes to the fix?

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

PR Review: https://git.openjdk.org/jdk/pull/14346#pullrequestreview-1471689886
PR Review Comment: https://git.openjdk.org/jdk/pull/14346#discussion_r1224138751


From aivanov at openjdk.org  Fri Jun  9 11:46:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 11:46:44 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <iYo9rHRTcIm1DNmhfhU00K0ZC_zrEa_6CAtzax0zqV0=.534b9ed0-ae7f-4be2-8d7a-980a50107c2d@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
 <iYo9rHRTcIm1DNmhfhU00K0ZC_zrEa_6CAtzax0zqV0=.534b9ed0-ae7f-4be2-8d7a-980a50107c2d@github.com>
Message-ID: <U-ZAKv29X7iM1RzP2Ch2hGLFc1q4Rw40Nu3mw5o0JoA=.d4399e0d-8765-41b2-8719-106fa9782ec4@github.com>

On Fri, 9 Jun 2023 05:39:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fix is to make sure `x Offset` is calculated with correct width so it will become 5 +30 (icon width) + 5 = 40
> 
> Issue of not getting large icon proportional to icon size is another issue and will be tackled separately.

Looks good to me. No objections to handle following issues separately.

![Metalworks with the fix](https://github.com/openjdk/jdk/assets/70774172/6c8d1bf1-41d1-4039-a6ff-04475aa57e9c)

The icon in the titlebar isn't centered in Low Vision theme, however, JInternalFrame handles the situation correctly. The gap between the icon and text in the titlebar looks too large too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14346#issuecomment-1584444377


From kevin.rushforth at oracle.com  Fri Jun  9 11:55:58 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 9 Jun 2023 04:55:58 -0700
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
Message-ID: <d8806ba5-1d85-93c2-a9e5-fbfff468eb44@oracle.com>

[Redirected from jdk-dev]

You should be aware that Wayland is not a supported desktop platform. 
Work is ongoing under the Wakefield [1] project to add such support, but 
that is a longer term effort. Having said that, many thing should 
already work, so you might try a more recent version of Java (JDK 20 or 
JDK 21 early-access) and see if your results are different.

Maybe others on this list will have comments about your specific issue.

-- Kevin

[1] https://openjdk.org/projects/wakefield/


On 6/9/2023 2:32 AM, Martin Petzold wrote:
> I have a Java application running on:
>
> XWayland 2:1.20.11-1+deb11u6, Weston 9.0.0-1, OpenJDK 
> 11.0.18+10-1~deb11u1, Debian 11, Kernel 5.10.52
>
> My JFrame (Window) is set to: 
> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(this);
>
> I can then see my interface on the full screen (in my case it is a TV 
> and I have CEC enabled in the Kernel). However, after I unplug HDMI 
> and plug HDMI again, my interface is gone (black screen). There is 
> only one small 1x1 pixel left. It seems the size of the Window is 
> changed by Java / XWayland / (Weston). I am sure, that I am not 
> changing it - I check all resize methods on JFrame.
>
> When I restart my Java application, it is back again - so it is not an 
> issue of the OS (Linux) directly and also - most probably - not Weston.
>
> I also don't have this issue with a pure Wayland application (e.g. 
> Weston flower). Using only Wayland (without Java and XWayland) things 
> work.
>
> When I PLUG the HDMI there is NO java.awt.event.ComponentEvent
>
> When I UNPLUG HDMI, I get the following java.awt.event.ComponentEvent:
>
> java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1x1)] on frame0
> java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167)
> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167)
> java.desktop/java.awt.Component.processComponentEvent(Component.java:6461)
> java.desktop/java.awt.Component.processEvent(Component.java:6415)
> java.desktop/java.awt.Container.processEvent(Container.java:2263)
> java.desktop/java.awt.Window.processEvent(Window.java:2049)
> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> java.base/java.security.AccessController.doPrivileged(Native Method)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> java.base/java.security.AccessController.doPrivileged(Native Method)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
>
> Unfortunately I also don't know how to manipulate the size after I 
> catched this event. I tried to directly set the size back, but this 
> did not work. I think it may don't work because at this time HDMI is 
> UNPLUGGED. Also, if I try to set the size back to normal once the HDMI 
> is plugged again, it does not work. I get overruled and the size is 
> then back to 1x1 pixel.
>
> As I don't get any event when the HDMI is PLUGGED again, I also don't 
> know when to (try to) set the size back to "normal".
>
>
> Thanks,
>
>
> Martin



From psadhukhan at openjdk.org  Fri Jun  9 11:56:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Jun 2023 11:56:50 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <iXZBaXyDKfoioesm61R0lN16xB7rx5PRfSIfCoRKpj4=.97f34f04-f8e0-465f-a85e-549b314ec915@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
 <iXZBaXyDKfoioesm61R0lN16xB7rx5PRfSIfCoRKpj4=.97f34f04-f8e0-465f-a85e-549b314ec915@github.com>
Message-ID: <RbXN7IMUZz7L7CCQZnrE-rwUn_qoyC7p_wQlkBdVzI4=.04fbc960-1449-48d0-aa65-3551da1549b4@github.com>

On Fri, 9 Jun 2023 10:29:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> src/demo/share/jfc/Metalworks/BigContrastMetalTheme.java line 128:
> 
>> 126:         table.put("PasswordField.border", textBorder);
>> 127:         table.put("TextArea.border", textBorder);
>> 128:         table.put("TextPane.font", controlFont);
> 
> Does this change also contributes to the fix?

No, but it looks wrong passing border value for font

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14346#discussion_r1224208399


From afarley at openjdk.org  Fri Jun  9 12:03:48 2023
From: afarley at openjdk.org (Adam Farley)
Date: Fri, 9 Jun 2023 12:03:48 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <qZAYwPZFHQxWbGZMfF8NbiLAOiXloDcLDZ_kP1wjCl4=.be191b45-bee9-4380-8e57-eab00bb1fe70@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

Note: I asked the bot for help because the documentation [here](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/backport), along with examples [here](https://github.com/openjdk/jdk/pull/8205#issuecomment-1153856655) and [here](https://github.com/openjdk/jdk/pull/4128#issuecomment-873779183), seem to imply that backport is not a valid command for closed PRs, so I wanted to know what my options were.

I mean, options aside from the somewhat lengthier process detailed [here](https://wiki.openjdk.org/display/SKARA/Backports), which I'll do if I must.

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

PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1584465618


From mbaesken at openjdk.org  Fri Jun  9 12:13:50 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jun 2023 12:13:50 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <f_rH7BT5RfYV3lB4fkf63OZPM-czX0L2SAK8AU0YF5k=.bc183e78-199e-486e-8d96-7297fa3159a0@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

Hi Adam , I do my backports from a commit , not a PR. Not sure if this works from a PR too, maybe it does, maybe not - at least the  'create pull request'  link showed up so I guess you will find out if it works too from PRs .

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

PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1584476339


From afarley at openjdk.org  Fri Jun  9 12:26:49 2023
From: afarley at openjdk.org (Adam Farley)
Date: Fri, 9 Jun 2023 12:26:49 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <acfGH53m-bjzApH95lohkeKLMvceo7MTYX315dyIQRg=.b79b3837-269d-41de-b5df-71c2c0764bce@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

Thanks Mat. Seems to work from PRs, and the [PR it created](https://github.com/openjdk/jdk11u-dev/pull/1940) seems to be valid. I'll update the [associated issue](https://bugs.openjdk.org/browse/JDK-8304291) now.

Not sure why [previous](https://github.com/openjdk/jdk/pull/8205#issuecomment-1153856655) [committers](https://github.com/openjdk/jdk/pull/4128#issuecomment-873779183) had issues. Maybe this is new functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1584488967
PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1584490712


From aivanov at openjdk.org  Fri Jun  9 13:35:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 13:35:41 GMT
Subject: RFR: 4516654: Metalworks Demo: Window title not displayed fully in
 Low Vision Theme [v2]
In-Reply-To: <RbXN7IMUZz7L7CCQZnrE-rwUn_qoyC7p_wQlkBdVzI4=.04fbc960-1449-48d0-aa65-3551da1549b4@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
 <vWOzSnOBiFK_MtLNwmtnGdufo9dTyYYUD89mfDHebC0=.8efa0512-da64-4d6d-b813-78fe6be1483b@github.com>
 <iXZBaXyDKfoioesm61R0lN16xB7rx5PRfSIfCoRKpj4=.97f34f04-f8e0-465f-a85e-549b314ec915@github.com>
 <RbXN7IMUZz7L7CCQZnrE-rwUn_qoyC7p_wQlkBdVzI4=.04fbc960-1449-48d0-aa65-3551da1549b4@github.com>
Message-ID: <_h7bt_yemdlMZYRFaLH4gTFrDpZw2KVEJhM9BLb7ATQ=.2e1092bf-d63a-4d1d-8e0a-3cee4d97f6cb@github.com>

On Fri, 9 Jun 2023 11:53:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> No, but it looks wrong passing border value for font

I couldn't agree more. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14346#discussion_r1224316886


From clanger at openjdk.org  Fri Jun  9 13:41:48 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 9 Jun 2023 13:41:48 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
 <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
Message-ID: <z9HvbO3MFplQjFW3DxyJrByPmYhsqQZpz6XSBG05s2I=.0fc8f5a2-f82a-4ffa-a51a-9e3484399dd2@github.com>

On Fri, 9 Jun 2023 10:42:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After
>> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
>> the AIX build fails.
>> We get
>> 
>> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
>> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
>> 
>> I cannot find endian.h on my AIX machine.
>> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
>> 
>> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use BIG_ENDIAN in define

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14390#pullrequestreview-1472106085


From alexey.ivanov at oracle.com  Fri Jun  9 13:47:38 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Fri, 9 Jun 2023 14:47:38 +0100
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <d8806ba5-1d85-93c2-a9e5-fbfff468eb44@oracle.com>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
 <d8806ba5-1d85-93c2-a9e5-fbfff468eb44@oracle.com>
Message-ID: <27d44240-1592-cfe4-ae11-5af104098b85@oracle.com>

If it is a full-screen JFrame, you can exit full-screen mode and enter 
it again. It may help.

Try using a more recent JDK, as Kevin suggested.

-- 
Regards,
Alexey

On 09/06/2023 12:55, Kevin Rushforth wrote:
> [Redirected from jdk-dev]
>
> You should be aware that Wayland is not a supported desktop platform. 
> Work is ongoing under the Wakefield [1] project to add such support, 
> but that is a longer term effort. Having said that, many thing should 
> already work, so you might try a more recent version of Java (JDK 20 
> or JDK 21 early-access) and see if your results are different.
>
> Maybe others on this list will have comments about your specific issue.
>
> -- Kevin
>
> [1] https://openjdk.org/projects/wakefield/
>
>
> On 6/9/2023 2:32 AM, Martin Petzold wrote:
>> I have a Java application running on:
>>
>> XWayland 2:1.20.11-1+deb11u6, Weston 9.0.0-1, OpenJDK 
>> 11.0.18+10-1~deb11u1, Debian 11, Kernel 5.10.52
>>
>> My JFrame (Window) is set to: 
>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(this);
>>
>> I can then see my interface on the full screen (in my case it is a TV 
>> and I have CEC enabled in the Kernel). However, after I unplug HDMI 
>> and plug HDMI again, my interface is gone (black screen). There is 
>> only one small 1x1 pixel left. It seems the size of the Window is 
>> changed by Java / XWayland / (Weston). I am sure, that I am not 
>> changing it - I check all resize methods on JFrame.
>>
>> When I restart my Java application, it is back again - so it is not 
>> an issue of the OS (Linux) directly and also - most probably - not 
>> Weston.
>>
>> I also don't have this issue with a pure Wayland application (e.g. 
>> Weston flower). Using only Wayland (without Java and XWayland) things 
>> work.
>>
>> When I PLUG the HDMI there is NO java.awt.event.ComponentEvent
>>
>> When I UNPLUG HDMI, I get the following java.awt.event.ComponentEvent:
>>
>> java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1x1)] on frame0
>> java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>>
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>>
>> java.desktop/java.awt.Component.processComponentEvent(Component.java:6461) 
>>
>> java.desktop/java.awt.Component.processEvent(Component.java:6415)
>> java.desktop/java.awt.Container.processEvent(Container.java:2263)
>> java.desktop/java.awt.Window.processEvent(Window.java:2049)
>> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
>> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
>> java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
>> java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
>> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
>> java.base/java.security.AccessController.doPrivileged(Native Method)
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>>
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) 
>>
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
>> java.base/java.security.AccessController.doPrivileged(Native Method)
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>>
>> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
>> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) 
>>
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) 
>>
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) 
>>
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) 
>>
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) 
>>
>> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) 
>>
>>
>> Unfortunately I also don't know how to manipulate the size after I 
>> catched this event. I tried to directly set the size back, but this 
>> did not work. I think it may don't work because at this time HDMI is 
>> UNPLUGGED. Also, if I try to set the size back to normal once the 
>> HDMI is plugged again, it does not work. I get overruled and the size 
>> is then back to 1x1 pixel.
>>
>> As I don't get any event when the HDMI is PLUGGED again, I also don't 
>> know when to (try to) set the size back to "normal".
>>
>>
>> Thanks,
>>
>>
>> Martin
>



From aivanov at openjdk.org  Fri Jun  9 13:55:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 13:55:49 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <cDGUYe8rz8yOj88-8WTeJdgudKG93PpM1KTLJyVMKHM=.2fc25980-b712-4a76-8deb-09469a5b6a17@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

The `/backport` command didn't work in PR, you had to issue it as a comment to the commit. I faced it myself. I guess the functionality has been updated so that it now works in PRs too. Good to know it.

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

PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1584614223


From azvegint at openjdk.org  Fri Jun  9 15:51:44 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 9 Jun 2023 15:51:44 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
 <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
Message-ID: <2jJSPD8Qc8Q1_aa3xsjMc8bj1c3ZfaH6dqoonAdPfes=.c8c982d8-c0f4-4b76-83d9-5078a99dd03c@github.com>

On Fri, 9 Jun 2023 10:42:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After
>> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
>> the AIX build fails.
>> We get
>> 
>> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
>> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
>> 
>> I cannot find endian.h on my AIX machine.
>> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
>> 
>> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use BIG_ENDIAN in define

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14390#pullrequestreview-1472481109


From azvegint at openjdk.org  Fri Jun  9 15:51:46 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 9 Jun 2023 15:51:46 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <nh2GX3MPeC1gqT0kwW2iMqVabxaM_4LVjmhlisR__Dw=.3587c750-08ac-4083-97ab-293b878457de@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
 <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
 <nh2GX3MPeC1gqT0kwW2iMqVabxaM_4LVjmhlisR__Dw=.3587c750-08ac-4083-97ab-293b878457de@github.com>
Message-ID: <ys7q3I-t2o4oqcX5Y3yAPLERF0DetPIqqeQu7tVUXvs=.475ed861-cdd1-480a-905e-75c940b62442@github.com>

On Fri, 9 Jun 2023 10:48:01 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We should consider fixing it upstream, too (https://github.com/PipeWire/pipewire).

please note that this is only a mirror of https://gitlab.freedesktop.org/pipewire/pipewire/

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

PR Comment: https://git.openjdk.org/jdk/pull/14390#issuecomment-1584798397


From tsteele at openjdk.org  Fri Jun  9 16:10:45 2023
From: tsteele at openjdk.org (Tyler Steele)
Date: Fri, 9 Jun 2023 16:10:45 GMT
Subject: RFR: JDK-8309703: AIX build fails after JDK-8280982 [v2]
In-Reply-To: <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
 <7I3UTiLzOz4Z_APfHueX2RoNDsA1WUgfRMctSx4bRJ4=.30b268a0-007b-4cbd-9b94-50bfc5351490@github.com>
Message-ID: <hIGMGmwH3P9iHSND8GMcsNSFBoL7ilkpHbVeyRWSSzI=.06da928a-9244-4586-a725-76e288c6e766@github.com>

On Fri, 9 Jun 2023 10:42:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After
>> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
>> the AIX build fails.
>> We get
>> 
>> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
>> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
>> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
>> 
>> I cannot find endian.h on my AIX machine.
>> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
>> 
>> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use BIG_ENDIAN in define

Thanks @MBaesken!

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

PR Comment: https://git.openjdk.org/jdk/pull/14390#issuecomment-1584823568


From honkar at openjdk.org  Fri Jun  9 16:14:50 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 9 Jun 2023 16:14:50 GMT
Subject: Integrated: JDK-8305645: System Tray icons get corrupted when Windows
 primary monitor changes
In-Reply-To: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
References: <s4p7iZgpezhYGuDX1ccPAX3lLd_v0TCouAdhqCqOkuo=.ed8cd75e-dd2f-4a8e-b7c5-196bcb06e932@github.com>
Message-ID: <2PEAmXEliQQ26omigHG8L1ubMk2Dvtyysm9kXXcxu6k=.364e1ae1-5c0b-48d6-b06f-fce77cc10638@github.com>

On Wed, 7 Jun 2023 19:05:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are two scenarios related to tray icon distortion.
> 
> 1. Single Screen - when DPI / Scale is changed on the fly - this was resolved as part of [PR#8441](https://github.com/openjdk/jdk/pull/8441)
> 
> 2. Multi Screen - when screens are set to different scales and the primary display is toggled. This is a variation of scenario one. 
> 
> Earlier Windows msg - [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) was used to set `m_bDPIChanged` which is used within  `AwtTrayIcon::WmTaskbarCreated()` to update the tray icons. This message is sent when window DPI changes. WM_DPICHANGED msg is not received when taskbar switches to primary display under multiple screen scenario, hence the tray icon was still seen distorted in case 2.
>  
> As [WM_DISPLAYCHANGE](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange) is received in both cases, it is used as the new message to update `m_bDPIChanged`. This message also works when the main display monitor gets disconnected accidently making the other display the primary display.
> 
> TrayIconScalingTest's  instructions have been updated to include both the cases described above.

This pull request has now been integrated.

Changeset: 6cd370e0
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cd370e04b01c3033eb439de0f38e9b6d703c6f4
Stats:     16 lines in 2 files changed: 7 ins; 0 del; 9 mod

8305645: System Tray icons get corrupted when Windows primary monitor changes

Reviewed-by: serb, aivanov

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

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


From jiangli at openjdk.org  Fri Jun  9 16:26:44 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 16:26:44 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
 <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
 <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>
Message-ID: <EpA_MdbQY0exQ6mlojFmKSP90pzphgt6pFPhOixriGM=.af1f27ff-e986-4d58-8bd0-01b429a08d7a@github.com>

On Fri, 2 Jun 2023 14:04:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?
> 
> I have no concerns regarding clang on Linux.

I've updated this PR to include partial linking for building static libraries with clang on Linux only. On macosx builds, relative path is used when needed for long path and many objects. @erikj79, could you please help run another iteration of your tests to see if there are any remaining missed cases. Hopefully we'll be able to wrap up this change. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1584840824


From martin.petzold at tavla.de  Fri Jun  9 17:18:52 2023
From: martin.petzold at tavla.de (Martin Petzold)
Date: Fri, 9 Jun 2023 19:18:52 +0200
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <27d44240-1592-cfe4-ae11-5af104098b85@oracle.com>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
 <d8806ba5-1d85-93c2-a9e5-fbfff468eb44@oracle.com>
 <27d44240-1592-cfe4-ae11-5af104098b85@oracle.com>
Message-ID: <8b0343cc-a62c-1cbd-8632-dc7750907916@tavla.de>

Am 09.06.23 um 15:47 schrieb Aleksei Ivanov:
> If it is a full-screen JFrame, you can exit full-screen mode and enter 
> it again. It may help.
>
Thanks, I can restore the size with your suggestion: I'm now using a 
scheduled executor service to check size and if it is not full screen 
remove full screen and set full screen window again. However, the Window 
does not show - it is not rendered. I tried setVisible(true) again, but 
no effect.

Martin



From azvegint at openjdk.org  Fri Jun  9 17:31:05 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 9 Jun 2023 17:31:05 GMT
Subject: RFR: 8309745: Problem list open client tests failing on Ubuntu_23.04
Message-ID: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>

Several tests began to fail on Ubuntu 23.04, while passing on previous Ubuntu releases.
They also fail with JDK 20, 17.

So problem list them to reduce the noise.

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

Commit messages:
 - initial

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

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


From serb at openjdk.org  Fri Jun  9 18:11:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Jun 2023 18:11:39 GMT
Subject: RFR: 8309745: Problem list open client tests failing on
 Ubuntu_23.04
In-Reply-To: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
References: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
Message-ID: <jDRauiI_hoJsbwMyAKc4g3ombfumssNFXxJELAa9LI4=.54ea7247-dfe0-4415-938e-f073a900aa83@github.com>

On Fri, 9 Jun 2023 17:25:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Several tests began to fail on Ubuntu 23.04, while passing on previous Ubuntu releases.
> They also fail with JDK 20, 17.
> 
> So problem list them to reduce the noise.

The SelectEditTableCell does not have any code related to rendering, why it is started to fail robot cannot click on the components? BTW the bug JDK-8309734 does not have any logs or something.

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

PR Comment: https://git.openjdk.org/jdk/pull/14400#issuecomment-1584948722


From azvegint at openjdk.org  Fri Jun  9 19:06:45 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 9 Jun 2023 19:06:45 GMT
Subject: RFR: 8309745: Problem list open client tests failing on
 Ubuntu_23.04
In-Reply-To: <jDRauiI_hoJsbwMyAKc4g3ombfumssNFXxJELAa9LI4=.54ea7247-dfe0-4415-938e-f073a900aa83@github.com>
References: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
 <jDRauiI_hoJsbwMyAKc4g3ombfumssNFXxJELAa9LI4=.54ea7247-dfe0-4415-938e-f073a900aa83@github.com>
Message-ID: <Dog3uDm2MsUguecITLIqPQCx4zPJurb0IJoRred-2Uw=.e1ba4e0b-622a-49e7-80b6-c87b6bf09ac7@github.com>

On Fri, 9 Jun 2023 17:56:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The SelectEditTableCell does not have any code related to rendering, why it is started to fail robot cannot click on the components? 

At first glance, it seems that something related to insets has changed on the Ubuntu 23.04 side and our code is not ready for it.

We're now initially getting zero insets(java.awt.Insets[top=0,left=0,bottom=0,right=0]) from the system, instead of actual java.awt.Insets[top=37,left=0,bottom=0,right=0].

And it's [cached](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java#L294-L296),  so we're not trying to get an updated one.

However, a detailed investigation is necessary.

As an example of side effect 100x100 windows are no longer square:

![image](https://github.com/openjdk/jdk/assets/77687766/83c38240-16ba-4ec2-bec3-7c2a21e72b2f)


> BTW the bug JDK-8309734 does not have any logs or something.

added as comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/14400#issuecomment-1585016461


From martin.petzold at tavla.de  Fri Jun  9 12:01:53 2023
From: martin.petzold at tavla.de (Martin Petzold)
Date: Fri, 9 Jun 2023 14:01:53 +0200
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <1ebc6904-1790-b6b2-c7fe-d36dda848c1a@oracle.com>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
 <1ebc6904-1790-b6b2-c7fe-d36dda848c1a@oracle.com>
Message-ID: <77ce2758-4473-87b0-e323-8aa8032791b5@tavla.de>

Dear Kevin,

thanks for your reply and forwarding this message. I am referring to 
Java with XWayland mainly.

We have an embedded device with i.MX8MP hardware platform. It is not 
that easy to go for very recent Linux platform, a lot of dependencies to 
hardware components. I already talked to the Wayland mailing list. It 
was not clear what causes this issue. There is only a guess recent 
builds could fix it.

I would like to understand this bug. Even if I do 'setReziable(false)' 
Java does change the size. Maybe you know about some work-around, how I 
can catch and block this behaviour?

According to XrandR output the resolution is correct (however the 
XWAYLAND name changes from 0..2). This brings it closer to Java:

HDMI PLUGGED (on boot)

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1110mm x 620mm
 ?? 1920x1080???? 59.96*+

HDMI UNPLUGGED

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1150mm x 650mm
 ?? 1920x1080???? 59.96*+

HDMI RE-PLUGGED

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND2 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1110mm x 620mm
 ?? 1920x1080???? 59.96*+

Thanks,

Martin Petzold

Am 09.06.23 um 13:52 schrieb Kevin Rushforth:
> [Redirected from jdk-dev]
>
> You should be aware that Wayland is not a supported desktop platform. 
> Work is ongoing under the Wakefield [1] project to add such support, 
> but that is a longer term effort. Having said that, many thing should 
> already work, so you might try a more recent version of Java (JDK 20 
> or JDK 21 early-access) and see if your results are different.
>
> Maybe others on this list will have comments about your specific issue.
>
> -- Kevin
>
> [1] https://openjdk.org/projects/wakefield/
>
>
>
> On 6/9/2023 2:32 AM, Martin Petzold wrote:
>>
>> I have a Java application running on:
>>
>> XWayland 2:1.20.11-1+deb11u6, Weston 9.0.0-1, OpenJDK 
>> 11.0.18+10-1~deb11u1, Debian 11, Kernel 5.10.52
>>
>> My JFrame (Window) is set 
>> to:|GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(this);|
>>
>> I can then see my interface on the full screen (in my case it is a TV 
>> and I have CEC enabled in the Kernel). However, after I unplug HDMI 
>> and plug HDMI again, my interface is gone (black screen). There is 
>> only one small 1x1 pixel left. It seems the size of the Window is 
>> changed by Java / XWayland / (Weston). I am sure, that I am not 
>> changing it - I check all resize methods on JFrame.
>>
>> When I restart my Java application, it is back again - so it is not 
>> an issue of the OS (Linux) directly and also - most probably - not 
>> Weston.
>>
>> I also don't have this issue with a pure Wayland application (e.g. 
>> Weston flower). Using only Wayland (without Java and XWayland) things 
>> work.
>>
>> When I PLUG the HDMI there is NO java.awt.event.ComponentEvent
>>
>> When I UNPLUG HDMI, I get the following java.awt.event.ComponentEvent:
>>
>> |java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1x1)] on frame0 
>> java.base/java.lang.Thread.getStackTrace(Thread.java:1602) 
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>> java.desktop/java.awt.Component.processComponentEvent(Component.java:6461) 
>> java.desktop/java.awt.Component.processEvent(Component.java:6415) 
>> java.desktop/java.awt.Container.processEvent(Container.java:2263) 
>> java.desktop/java.awt.Window.processEvent(Window.java:2049) 
>> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011) 
>> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) 
>> java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) 
>> java.desktop/java.awt.Component.dispatchEvent(Component.java:4843) 
>> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) 
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) 
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) 
>> java.base/java.security.AccessController.doPrivileged(Native Method) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) 
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) 
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) 
>> java.base/java.security.AccessController.doPrivileged(Native Method) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) 
>> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) 
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) 
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) 
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) 
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) 
>> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) 
>> |
>>
>> Unfortunately I also don't know how to manipulate the size after I 
>> catched this event. I tried to directly set the size back, but this 
>> did not work. I think it may don't work because at this time HDMI is 
>> UNPLUGGED. Also, if I try to set the size back to normal once the 
>> HDMI is plugged again, it does not work. I get overruled and the size 
>> is then back to 1x1 pixel.
>>
>> As I don't get any event when the HDMI is PLUGGED again, I also don't 
>> know when to (try to) set the size back to "normal".
>>
>>
>> Thanks,
>>
>>
>> Martin
>>
>
-- 
Martin Petzold (Inhaber & Gesch?ftsf?hrer)

TAVLA Technology GmbH
Im Dau 14
50678 K?ln
Deutschland

Telefon: +49 (0)221 / 3466 0885
Mobil: +49 (0)179 / 9220154
E-Mail:martin.petzold at tavla.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230609/ac57c5b6/attachment.htm>

From martin.petzold at tavla.de  Fri Jun  9 13:55:35 2023
From: martin.petzold at tavla.de (Martin Petzold)
Date: Fri, 9 Jun 2023 15:55:35 +0200
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <1ebc6904-1790-b6b2-c7fe-d36dda848c1a@oracle.com>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
 <1ebc6904-1790-b6b2-c7fe-d36dda848c1a@oracle.com>
Message-ID: <345e9915-0a84-e85e-51ae-6b826bfdf463@tavla.de>

Dear Kevin,

thanks for your reply and forwarding this message. I am referring to 
Java with XWayland mainly.

We have an embedded device with i.MX8MP hardware platform. It is not 
that easy to go for very recent Linux platform, a lot of dependencies to 
hardware components. I already talked to the Wayland mailing list. It 
was not clear what causes this issue. There is only a guess recent 
builds could fix it.

I would like to understand this bug. Even if I do 'setReziable(false)' 
Java does change the size. Maybe you know about some work-around, how I 
can catch and block this behaviour?

According to XrandR output the resolution is correct (however the 
XWAYLAND name changes from 0..2). This brings it closer to Java:

HDMI PLUGGED (on boot)

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1110mm x 620mm
 ?? 1920x1080???? 59.96*+

HDMI UNPLUGGED

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1150mm x 650mm
 ?? 1920x1080???? 59.96*+

HDMI RE-PLUGGED

xrandr --current
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND2 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1110mm x 620mm
 ?? 1920x1080???? 59.96*+

Thanks,

Martin Petzold

Am 09.06.23 um 13:52 schrieb Kevin Rushforth:
> [Redirected from jdk-dev]
>
> You should be aware that Wayland is not a supported desktop platform. 
> Work is ongoing under the Wakefield [1] project to add such support, 
> but that is a longer term effort. Having said that, many thing should 
> already work, so you might try a more recent version of Java (JDK 20 
> or JDK 21 early-access) and see if your results are different.
>
> Maybe others on this list will have comments about your specific issue.
>
> -- Kevin
>
> [1] https://openjdk.org/projects/wakefield/
>
>
>
> On 6/9/2023 2:32 AM, Martin Petzold wrote:
>>
>> I have a Java application running on:
>>
>> XWayland 2:1.20.11-1+deb11u6, Weston 9.0.0-1, OpenJDK 
>> 11.0.18+10-1~deb11u1, Debian 11, Kernel 5.10.52
>>
>> My JFrame (Window) is set 
>> to:|GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(this);|
>>
>> I can then see my interface on the full screen (in my case it is a TV 
>> and I have CEC enabled in the Kernel). However, after I unplug HDMI 
>> and plug HDMI again, my interface is gone (black screen). There is 
>> only one small 1x1 pixel left. It seems the size of the Window is 
>> changed by Java / XWayland / (Weston). I am sure, that I am not 
>> changing it - I check all resize methods on JFrame.
>>
>> When I restart my Java application, it is back again - so it is not 
>> an issue of the OS (Linux) directly and also - most probably - not 
>> Weston.
>>
>> I also don't have this issue with a pure Wayland application (e.g. 
>> Weston flower). Using only Wayland (without Java and XWayland) things 
>> work.
>>
>> When I PLUG the HDMI there is NO java.awt.event.ComponentEvent
>>
>> When I UNPLUG HDMI, I get the following java.awt.event.ComponentEvent:
>>
>> |java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1x1)] on frame0 
>> java.base/java.lang.Thread.getStackTrace(Thread.java:1602) 
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167) 
>> java.desktop/java.awt.Component.processComponentEvent(Component.java:6461) 
>> java.desktop/java.awt.Component.processEvent(Component.java:6415) 
>> java.desktop/java.awt.Container.processEvent(Container.java:2263) 
>> java.desktop/java.awt.Window.processEvent(Window.java:2049) 
>> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011) 
>> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) 
>> java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) 
>> java.desktop/java.awt.Component.dispatchEvent(Component.java:4843) 
>> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) 
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) 
>> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) 
>> java.base/java.security.AccessController.doPrivileged(Native Method) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) 
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) 
>> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) 
>> java.base/java.security.AccessController.doPrivileged(Native Method) 
>> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) 
>> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) 
>> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) 
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) 
>> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) 
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) 
>> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) 
>> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) 
>> |
>>
>> Unfortunately I also don't know how to manipulate the size after I 
>> catched this event. I tried to directly set the size back, but this 
>> did not work. I think it may don't work because at this time HDMI is 
>> UNPLUGGED. Also, if I try to set the size back to normal once the 
>> HDMI is plugged again, it does not work. I get overruled and the size 
>> is then back to 1x1 pixel.
>>
>> As I don't get any event when the HDMI is PLUGGED again, I also don't 
>> know when to (try to) set the size back to "normal".
>>
>>
>> Thanks,
>>
>>
>> Martin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230609/f48a000a/attachment.htm>

From aivanov at openjdk.org  Fri Jun  9 19:53:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 Jun 2023 19:53:40 GMT
Subject: RFR: 8309745: Problem list open client tests failing on
 Ubuntu_23.04
In-Reply-To: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
References: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
Message-ID: <UoyZepvWQIGalPHQVWPqUEaLJppPdPC-4DZBQdqaFTg=.9ccf3f96-4203-4161-b27b-3cf6a2cd6aba@github.com>

On Fri, 9 Jun 2023 17:25:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Several tests began to fail on Ubuntu 23.04, while passing on previous Ubuntu releases.
> They also fail with JDK 20, 17.
> 
> So problem list them to reduce the noise.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14400#pullrequestreview-1472978262


From azvegint at openjdk.org  Fri Jun  9 19:57:03 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 9 Jun 2023 19:57:03 GMT
Subject: Integrated: 8309745: Problem list open client tests failing on
 Ubuntu_23.04
In-Reply-To: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
References: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
Message-ID: <JqDSM-EGiv07OAbhIX03HDgOnOLm0azd7C16I88uCFQ=.07276b40-940a-4193-af65-3d2e604b39d9@github.com>

On Fri, 9 Jun 2023 17:25:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Several tests began to fail on Ubuntu 23.04, while passing on previous Ubuntu releases.
> They also fail with JDK 20, 17.
> 
> So problem list them to reduce the noise.

This pull request has now been integrated.

Changeset: f5ec93eb
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5ec93eb889636d93d1e490871b528cd1deca89e
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8309745: Problem list open client tests failing on Ubuntu_23.04

Reviewed-by: aivanov

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

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


From erikj at openjdk.org  Fri Jun  9 20:05:43 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Jun 2023 20:05:43 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
Message-ID: <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>

On Thu, 8 Jun 2023 20:34:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into JDK-8307858
>  - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
>  - Merge branch 'master' into JDK-8307858
>  - Address comments/suggestions from @erikj79:
>    - Only do partial linking step for building static libraries with clang on linux.
>    - On macosx, workaround the long argument issue for 'AR' with relative path.
>    
>    Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
>  - Update make/common/NativeCompilation.gmk
>    
>    Thanks you!
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>  - Update make/common/NativeCompilation.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8307858
>  - Merge branch 'master' into JDK-8307858
>  - Clean up.
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/c4e65425...c664c601

All our builds succeeded, so this is looking pretty good now. Just a minor suggestion left.

make/common/NativeCompilation.gmk line 1186:

> 1184:     # Include partial linking when building the static library with clang on linux.
> 1185:     ifeq ($(call isTargetOs, linux), true)
> 1186:       ifneq ($(findstring $(TOOLCHAIN_TYPE), clang), )

This combination of conditions is repeated 3 times. Maybe we could assign the result to a variable (e.g. `$1_ENABLE_PARTIAL_LINKING`) and check for that instead?

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

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1472988455
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1224714975


From serb at openjdk.org  Fri Jun  9 23:03:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Jun 2023 23:03:17 GMT
Subject: RFR: 8309745: Problem list open client tests failing on
 Ubuntu_23.04
In-Reply-To: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
References: <aiDuEivHqsu8s1hhYsTSj5aVQz0Fs8oyNckzlBvknrM=.6fa0b967-a95a-49a4-917b-48b70ab5d360@github.com>
Message-ID: <9kfB7C1BstM68nH9_Ntg_oALVSlw_FhONtGKLklkZfk=.d8faa05a-3d4c-4117-b540-03f741b7769c@github.com>

On Fri, 9 Jun 2023 17:25:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Several tests began to fail on Ubuntu 23.04, while passing on previous Ubuntu releases.
> They also fail with JDK 20, 17.
> 
> So problem list them to reduce the noise.

Then all of them looks like a regressions, that should not be problem listed in batch as a p4 bug. Especially taking into account it is now excluded on all linux not only on non-released ubuntu 23.04.

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

PR Comment: https://git.openjdk.org/jdk/pull/14400#issuecomment-1585181381


From jiangli at openjdk.org  Fri Jun  9 23:04:33 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 23:04:33 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v8]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JDK-8307858
 - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
 - Merge branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - ... and 11 more: https://git.openjdk.org/jdk/compare/beec734f...28585b84

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

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=07
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

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


From jiangli at openjdk.org  Fri Jun  9 23:04:33 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 23:04:33 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
 <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>
Message-ID: <4UxQ6tu2JPttQxkKLhi-TFLR7M46F0CgeXt4QZzWNN0=.b7620fe4-725c-41c9-a0fa-1a90b8013769@github.com>

On Fri, 9 Jun 2023 20:03:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> All our builds succeeded, so this is looking pretty good now. Just a minor suggestion left.

Thanks a lot!

> This combination of conditions is repeated 3 times. Maybe we could assign the result to a variable (e.g. `$1_ENABLE_PARTIAL_LINKING`) and check for that instead?

Done, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1585213568
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1224866324


From erikj at openjdk.org  Fri Jun  9 23:43:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Jun 2023 23:43:44 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v8]
In-Reply-To: <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>
Message-ID: <vhiSPrvXKhH5j32Bnb0zz0GR0FNy2v6dO9smZI0JsMU=.65bb7de3-eaa3-4b48-8181-7ad604b5228f@github.com>

On Fri, 9 Jun 2023 23:04:33 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'master' into JDK-8307858
>  - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
>  - Merge branch 'master' into JDK-8307858
>  - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
>  - Merge branch 'master' into JDK-8307858
>  - Address comments/suggestions from @erikj79:
>    - Only do partial linking step for building static libraries with clang on linux.
>    - On macosx, workaround the long argument issue for 'AR' with relative path.
>    
>    Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
>  - Update make/common/NativeCompilation.gmk
>    
>    Thanks you!
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>  - Update make/common/NativeCompilation.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8307858
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/beec734f...28585b84

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1473186956


From serb at openjdk.org  Sat Jun 10 01:24:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 10 Jun 2023 01:24:10 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v13]
In-Reply-To: <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
 <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
 <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>
Message-ID: <bCDtlL7ndb_1q6LhqZPNqEDY3CKQw77SmkyrR1cLp-Y=.4e4be911-e54c-428c-939a-616665f196d0@github.com>

On Thu, 8 Jun 2023 20:39:09 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>>> So, we ask Windows for the component image based on a particular DPI , not some specific size. The basic premise here is that we expect Windows returning image that would match the DPI , and then we perform our calculations accordingly. In the case above (if Region.clipRound is used) that basic premise is not met (if w, h=19) due to us calculating a DPI value of 140 which is closer to 120 or 125% scaling while our scaling is acytually 150% and Windows returns us a smaller size of the component than expected. So we don't need to add extra code to rescale , I believe. If we provide windows with correctly calculated DPI value which my code change does it should work fine as Windows will give us image of the correct size.
>> 
>> 
>> =( I am still missing something.
>> This is the code we discussing:
>> 
>>             int w = (int) Math.floor(destWidth + 0.5);
>>             int h = (int) Math.floor(destHeight + 0.5);
>> 
>> It calculates the size of the image we would like to render, it does not calculate the DPI. So if our component is 100x100 in pixels we create the image of that [size](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155) and put it into the cache. Later when want to render that image to the place where the component of size 100x100 is located we request it from the PainterMultiResolutionCachedImage.getResolutionVariant.
>> 
>> After this patch we create the image of one size using ceil, then request the image using floor, and it is somehow affected by the fact that the WIndows may return something different than requested.
>
> The above code calls getImage() and passes width and height to it.
> 
> This is the flow :
> getImage(){CachedPainter.java} -> paintToImage() {XPStyle.java} -> ThemeReader.paintBackground ()
> 
> We calculate and set scale in getImage() with this:
> 
> https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L170-L175
>  
>  So, scale changes based on height and width of the image which we get from the
>  code you mentioned above.
>  
>  This scale is then used in paintToImage() to calculate DPI at Line 711 of XPStyle.java:
> 
> https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java#L709-L711 
>  
>  This DPI is then used to get the part size from windows and it changes as I explained in the previous comment.
>  https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java#L164

II am not sure that is correct way to calculate the dpi based on the "adhoc" change of the image size. That will add the mismatch between the code where we create the image, and the code where we request the image. We probably should change them both, or calculate the dpi in some other way.

Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1224959410


From markus at headcrashing.eu  Sat Jun 10 11:35:52 2023
From: markus at headcrashing.eu (Markus Karg)
Date: Sat, 10 Jun 2023 13:35:52 +0200
Subject: RFC: 8309726: Reader::readString
Message-ID: <000001d99b8f$b6e1a4d0$24a4ee70$@eu>

By analyzing several existing applications I noticed that many of them need
to read a String from an input source (be it an input stream or a reader),
and there are a lot of solutions applied which all are more or less
suboptimal:

* Files.readString(Path) - Fast, convenient, uses JLA.newStringNoRepl, only
works with files (not with sockets or other sources).
* new String(inputStream.readAllBytes()) - Fast, complex, enforces dealing
with an array in user code, cannot use JLA.newStringNoRepl.
* bufferedReader.lines().collect(StringBuilder::new, StringBuilder::append,
StringBuilder::append).toString(); - Complex, enforces dealing with a stream
in user code, doesn't use JLA.newStringNoRepl.
* reader.transferTo(stringWriter); stringWriter.toString(); - Medium
convient, medium performance, synchronized as it relies on StringBuffer
instead of StringBuilder.
* Custom loop using char[] of various default sizes (some 8k, some 16k, some
configurable) - Slow, complex, doesn't use JLA.newStringNoRepl.
* etc.

Checking back with the particular authors of these applications I noticed
that what they all miss is (a) guidance which solution is "best" (mostly
thinking in speed, but also in reduced GC stress and memory consumption),
(b) something convenient like Files.readString() but working with any reader
implementation, not just with files.

I think we can do better, hence I'd like to propose the introduction of a
new Reader::readString method. The benefits are:
* Guidance. The introduction of this method is a clear signal to all
application programmers to use *this* one by default.
* Convenience. It couldn't be any easier for the caller.
* Performance. OpenJDK committers can optimize it for both, convenience,
speed, reduced GC stress, and memory consumption, at the very same time.
* Optimizable. Each Reader implementation can choose an algorithm fitting
best its own needs, while java.io.Reader itself provides a convenient
default implementation based on a loop over this.read().

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230610/9e270a57/attachment.htm>

From duke at openjdk.org  Sat Jun 10 17:26:55 2023
From: duke at openjdk.org (duke)
Date: Sat, 10 Jun 2023 17:26:55 GMT
Subject: Withdrawn: JDK-8302281 - ImageReader and ImageWrite should implement
 Closable
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <rKNJca94ZmslxyLZkwxG3dNVWXslyON74e0e9iO4XK0=.061d56f2-bfd1-4da0-951d-ea9cf64b8712@github.com>

On Thu, 19 Jan 2023 18:41:08 GMT, Markus KARG <duke at openjdk.org> wrote:

> The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for a method called `close()`, or assume that resources only need to get closed when they support try-with-resource. As a result, there is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently.
> 
> This is not a big change, but it is useful for those working with ImageIO.

This pull request has been closed without being integrated.

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

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


From asemenov at openjdk.org  Sun Jun 11 15:40:28 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 15:40:28 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
 <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
Message-ID: <eBtSHGuk6jA2M9fjawmCo9mpiqkzcvZUXalngywokB0=.4f3f5cfc-45ba-4cb8-94c6-fbe843201879@github.com>

On Tue, 6 Jun 2023 17:47:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is rarely used in the code and is not the essence of the current changes.
>> If you introduce such changes, then throughout the code.
>> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225
>
> I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

I think you can create a separate ticket and pull request to discuss this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1225842637


From asemenov at openjdk.org  Sun Jun 11 16:38:31 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 16:38:31 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - update
 - update
 - update
 - update
 - 8308286 Fix clang warnings in linux code

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

Changes: https://git.openjdk.org/jdk/pull/14033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04
  Stats: 16 lines in 6 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

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


From jiangli at openjdk.org  Mon Jun 12 02:18:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 12 Jun 2023 02:18:57 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v9]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <ihqFliQYggKep8pnBDk8p9hPDo7CG9RfpWhiDXkp4cU=.c2a5b740-308f-498d-8040-07d8fde0dddc@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
 - Merge branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - ... and 12 more: https://git.openjdk.org/jdk/compare/16c3d53b...af271e2c

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

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=08
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

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


From mbaesken at openjdk.org  Mon Jun 12 06:59:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 06:59:58 GMT
Subject: Integrated: JDK-8309703: AIX build fails after JDK-8280982
In-Reply-To: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
References: <VGfQUpvK0WPbLrlN7DareKZpB_dsHns4fmd7H-l4y2w=.e53ab9be-4559-4520-91a6-95e57c8ffbf7@github.com>
Message-ID: <pxjdI6Vrtjg9Xta7Jc60eF1mlbNWzX0vr48r10_NNLI=.97f0acbe-bae3-41bb-ab33-8ff09e0c5ea6@github.com>

On Fri, 9 Jun 2023 10:12:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After
> [JDK-8280982](https://bugs.openjdk.org/browse/JDK-8280982): [Wayland] [XWayland] java.awt.Robot taking screenshots
> the AIX build fails.
> We get
> 
> * For target support_native_java.desktop_libawt_xawt_screencast_pipewire.o:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c:33:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.h:40:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/debug/types.h:17:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/utils/type-info.h:33:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/type-info.h:8:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/param-types.h:50:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/type-info.h:8:
> In file included from /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw-types.h:18:
> /aixbuild/jdk-dev/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h:15:10: fatal error: 'endian.h' file not found
> 
> I cannot find endian.h on my AIX machine.
> Instead there is <sys/machine.h> which provides some info on byte order etc. instead .
> 
> Additionally we have a "warning as error"  in src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c ; xlc17 clang 15 is very picky about the vfprintf used there. I disabled the warning.

This pull request has now been integrated.

Changeset: 3981297f
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3981297fd34a628dff44898e6c60455cf071741a
Stats:     12 lines in 2 files changed: 11 ins; 0 del; 1 mod

8309703: AIX build fails after JDK-8280982

Reviewed-by: mdoerr, clanger, azvegint

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

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


From psadhukhan at openjdk.org  Mon Jun 12 08:53:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Jun 2023 08:53:52 GMT
Subject: Integrated: 4516654: Metalworks Demo: Window title not displayed fully
 in Low Vision Theme
In-Reply-To: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
References: <bfzHBCEuRAlJXxA8afuAbm-r0xGi1vLMoj1mM_yHMAU=.96e82fd0-4415-4154-81c2-48e942b50c2b@github.com>
Message-ID: <_3w8S9OnFia8Ek6OqEeZlLVejpHWQu_iDVrgXj_HaII=.24d18a58-68fe-4e7d-a335-9620d9d6c602@github.com>

On Wed, 7 Jun 2023 06:55:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Metalworks demo in Low Vision theme, window title is not diplayed fully in this theme. The first letter of the title, that is letter "M", is cut vertically
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/b122787c-8144-4771-a74a-71b60e1a63f9)
> 
> It is because the iconsize is hardcoded to be 30 and windows titlePane title is rendered at same place irrespective of theme (only font size is made bigger from normal pt 12 to 24 for Low Vision theme) so icon width overlaps the title.
> Icon width is made to be 24 in demo in sync with window title font size which made it work ok
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/fa61f2cb-8339-4e92-8612-b1d8d32e8b7f)

This pull request has now been integrated.

Changeset: 4d470696
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d4706967d44b6908406818bb135f94130f373a0
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

4516654: Metalworks Demo: Window title not displayed fully in Low Vision Theme

Reviewed-by: tr, aivanov

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

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


From tr at openjdk.org  Mon Jun 12 10:40:03 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 Jun 2023 10:40:03 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v4]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <3mGy7OIRo7dBx2h7UrD4mkIuZZ8IE5trV3kR-XncKvg=.72d6fd11-3906-4083-9244-0c2cc01ddcbd@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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

  Fix - Modified setGC to use getAppropriateGC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/45ff7b2f..0b7bc979

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

  Stats: 68 lines in 5 files changed: 59 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14246/head:pull/14246

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


From tr at openjdk.org  Mon Jun 12 11:10:58 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 Jun 2023 11:10:58 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v4]
In-Reply-To: <3mGy7OIRo7dBx2h7UrD4mkIuZZ8IE5trV3kR-XncKvg=.72d6fd11-3906-4083-9244-0c2cc01ddcbd@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <3mGy7OIRo7dBx2h7UrD4mkIuZZ8IE5trV3kR-XncKvg=.72d6fd11-3906-4083-9244-0c2cc01ddcbd@github.com>
Message-ID: <be9xwHkHOGHlCScACEsU5FH1GKPQOd47Fx5ZGnf-i5k=.8730816d-bbb7-41ed-8731-f0ed3aed41d9@github.com>

On Mon, 12 Jun 2023 10:40:03 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix - Modified setGC to use getAppropriateGC

The patch which sets GC using `getAppropriateGraphicsConfiguration()` method in `Canvas` is used in `Window` too (Only `XWindowPeer` which means for linux alone). CI testing shows green.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1587106750


From erikj at openjdk.org  Mon Jun 12 12:30:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jun 2023 12:30:55 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <gsunSnFI-zLXJ0T0_foKShSTuXvUuhY0J7y-8oA-HAk=.1a6208f6-261e-49eb-8786-cd11dd2a7c31@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Build changes look ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1587242876


From mbaesken at openjdk.org  Mon Jun 12 14:20:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 14:20:16 GMT
Subject: RFR: 8309703: AIX build fails after JDK-8280982
Message-ID: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>

8309703: AIX build fails after JDK-8280982

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

Commit messages:
 - Backport 3981297fd34a628dff44898e6c60455cf071741a

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

PR: https://git.openjdk.org/jdk21/pull/8


From mdoerr at openjdk.org  Mon Jun 12 14:34:55 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 12 Jun 2023 14:34:55 GMT
Subject: RFR: 8309703: AIX build fails after JDK-8280982
In-Reply-To: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
References: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
Message-ID: <my-Xi3cg5_aU3OnCVae-AYewjjtoJ-wZ4z6gXxBJMGY=.e794f40c-ab1a-4240-9631-49b761edc504@github.com>

On Mon, 12 Jun 2023 14:13:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309703: AIX build fails after JDK-8280982

This is a must have for JDK 21. Fixes AIX build. Low risk because code is protected by ifdefs and change is small.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/8#pullrequestreview-1475090255


From mbaesken at openjdk.org  Mon Jun 12 14:44:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 14:44:59 GMT
Subject: Integrated: 8309703: AIX build fails after JDK-8280982
In-Reply-To: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
References: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
Message-ID: <YtLB9GfQshqg8ZacZtxJ1gZuDPhY6QF2lQKzOlVFeHE=.8b30dd20-2168-4d8d-be68-82bd453f8b81@github.com>

On Mon, 12 Jun 2023 14:13:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309703: AIX build fails after JDK-8280982

This pull request has now been integrated.

Changeset: 005006e7
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/005006e7c4bc9d59f3110b5f26362444b2bd214a
Stats:     12 lines in 2 files changed: 11 ins; 0 del; 1 mod

8309703: AIX build fails after JDK-8280982

Reviewed-by: mdoerr
Backport-of: 3981297fd34a628dff44898e6c60455cf071741a

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

PR: https://git.openjdk.org/jdk21/pull/8


From mbaesken at openjdk.org  Mon Jun 12 14:44:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 14:44:59 GMT
Subject: RFR: 8309703: AIX build fails after JDK-8280982
In-Reply-To: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
References: <xnv63QxvytLVJ7gihSlidYw9Sm8n2UN0C08CBYc14CA=.c2497bf7-d38c-4647-93d1-045ee49c58a8@github.com>
Message-ID: <Fs2xqRG0OFNVRl6nVrsMtNzazPUJehgF0u9Z7hKTBl0=.4ae8ea45-fd70-4b40-b9a1-d7967a1ca5dd@github.com>

On Mon, 12 Jun 2023 14:13:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309703: AIX build fails after JDK-8280982

Hi Martin, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk21/pull/8#issuecomment-1587485013


From jiangli at openjdk.org  Mon Jun 12 16:25:50 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 12 Jun 2023 16:25:50 GMT
Subject: Integrated: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <LFF7yUAdSpOi9weD_xfrHJGO2ugT7R7xTV9fNsU2x5k=.c8d923ae-5bfd-474e-ab88-b5a07a4f14f8@github.com>

On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

This pull request has now been integrated.

Changeset: 45414fc2
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45414fc2dfa41cbbfc6de7fec15eb47f41cf8986
Stats:     224 lines in 10 files changed: 173 ins; 34 del; 17 mod

8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

Co-authored-by: Erik Joelsson <erikj at openjdk.org>
Reviewed-by: erikj

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

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


From aivanov at openjdk.org  Mon Jun 12 18:08:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Jun 2023 18:08:52 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v5]
In-Reply-To: <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
Message-ID: <8Ljoc1JIweF8QZOzPtZZJSW3x5VIvw9kgrABjNEIOwA=.030a90ed-4e1c-4763-a5da-83ff98d5c36e@github.com>

On Wed, 7 Jun 2023 20:48:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes to screen capture

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14289#pullrequestreview-1475520548


From rmahajan at openjdk.org  Mon Jun 12 19:50:39 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Mon, 12 Jun 2023 19:50:39 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v14]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <cxEfvnSMggHK3FiCdKEGJPb-hALDsBv4nkXeQO0cMzo=.fa41ba61-1412-4e6a-980b-6fddfafc27a1@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  code changes as per reviewers suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/a780bf0d..36bec863

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=12-13

  Stats: 9 lines in 4 files changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

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


From aivanov at openjdk.org  Mon Jun 12 20:02:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Jun 2023 20:02:02 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v14]
In-Reply-To: <bCDtlL7ndb_1q6LhqZPNqEDY3CKQw77SmkyrR1cLp-Y=.4e4be911-e54c-428c-939a-616665f196d0@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
 <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
 <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>
 <bCDtlL7ndb_1q6LhqZPNqEDY3CKQw77SmkyrR1cLp-Y=.4e4be911-e54c-428c-939a-616665f196d0@github.com>
Message-ID: <L_NQEzsrTrx3Jl5b3ms0hU8U-dRdbQTME2LQs_OYhH8=.f6ccfb07-9517-4916-8f4a-dd1d62aa9529@github.com>

On Sat, 10 Jun 2023 01:20:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> II am not sure that is correct way to calculate the dpi based on the "adhoc" change of the image size. That will add the mismatch between the code where we create the image, and the code where we request the image.

There's always a mismatch (at this time). We already discussed it [above](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571).

For example, for 125% scale, Windows returns 13?13 like for 100%; yet Swing expects 16.25. This is handled by rendering the 13?13-sized theme background into 16?16-sized bitmap ? *to avoid any scale transformations being applied* to keep the image *crisp*.

> We probably should change them both, or calculate the dpi in some other way.

The DPI is calculated based on the scale set on the Graphics. Rajat provided the relevant excerpt:

https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java#L708-L711

This scale is calculated based on the size of the image.

So, we probably should? change. As [I already said](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571), this fix should've been as simple as a `MultiResolutionImage` where [`getResolutionVariant`](https://github.com/openjdk/jdk/blob/a780bf0dda4c2c3dce4337ccea37bcdce52045de/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L316) returns the image of the correct size if it's already stored or retrieves it from the system. But it's not the case, and `CachedPainter` seems to be a hindrance rather than a helper.

That being said, we're planning to look further into simplifying it. Perhaps, `XPStyle.SkinPainter` shouldn't extend `CachedPainter`?

> Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)

The point of the this fix is to *avoid rescaling* what Windows returns. And it *succeeds*: check boxes and radio buttons look much better ? sharper and crisper ? when you drag Swing UI frame from a display with one DPI to that with another; they even look better on the main display if its DPI is 120 or 168, that is 125% and 175% correspondingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227173718


From aivanov at openjdk.org  Mon Jun 12 20:26:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Jun 2023 20:26:00 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v14]
In-Reply-To: <aQUac6JBuCL61qi08F2fh7CPXj-J8pEz6pyCwKmtF4I=.744adc9e-ceea-4cb1-a332-da23415430f4@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <AtakUYhXuWwWNYIh6dmjHSte3dCZc5d3xsFIXhPxdDY=.20b24c11-fe6a-4921-8de9-f7352d3444d4@github.com>
 <jDKWvs3-SqBPy9sgOebDg5ZSPXnIw2qZ2fb3w274yk4=.ba7ad6e1-1a21-425c-9841-60b33ce00faf@github.com>
 <WpxDvVY_Fb61gdRe7HM85PrX5MBrF-h-HyOHsgX_tiI=.32a6e113-864f-465c-9240-3a38f6801ef1@github.com>
 <k9U4bWSkv_j3-CcQGE6KCUgaQyG4MSwgxHYYh8Ofwxk=.3ef596ca-d4e7-4274-af5c-ca6b472a9a62@github.com>
 <aQUac6JBuCL61qi08F2fh7CPXj-J8pEz6pyCwKmtF4I=.744adc9e-ceea-4cb1-a332-da23415430f4@github.com>
Message-ID: <bK8i3aJN3fCi60m1MRWpZ-BdZtJIYBaHRBz6vVX1FQw=.b83979df-b443-4517-bb89-9f9e112cf4c1@github.com>

On Mon, 8 May 2023 18:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> It may be useful to be able to run Java on previous versions though, yet it's not a priority.
>> 
>> Then probably it is better to add a fallback since that method was added to the win 10 after GA, and it does not exist in the early version.
>
>> > It may be useful to be able to run Java on previous versions though, yet it's not a priority.
>> 
>> Then probably it is better to add a fallback since that method was added to the win 10 after GA, and it does not exist in the early version.
> 
> But the earlier versions of Windows 10 are already unsupported, including the one where the `OpenThemeDataForDpi` function was added.
> 
> If required, the fallback could be implemented under a new bug. ~~Anyway, I don't have a strong opinion on this matter.~~

I think it's *unfeasible* to provide the fallback to keep the code simpler.

If `OpenThemeDataForDpi` isn't available, we cannot get per-DPI images. Then we have to fallback to using the DPI of the main display and scale up / down all the returned values and images.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227202738


From serb at openjdk.org  Mon Jun 12 20:42:01 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 Jun 2023 20:42:01 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v14]
In-Reply-To: <L_NQEzsrTrx3Jl5b3ms0hU8U-dRdbQTME2LQs_OYhH8=.f6ccfb07-9517-4916-8f4a-dd1d62aa9529@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
 <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
 <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>
 <bCDtlL7ndb_1q6LhqZPNqEDY3CKQw77SmkyrR1cLp-Y=.4e4be911-e54c-428c-939a-616665f196d0@github.com>
 <L_NQEzsrTrx3Jl5b3ms0hU8U-dRdbQTME2LQs_OYhH8=.f6ccfb07-9517-4916-8f4a-dd1d62aa9529@github.com>
Message-ID: <w6vPerx744LYfPWtOcDHeoJvO264GXckiZ-ljQLAumo=.f5078e65-38aa-4c46-a0fe-4997420b6200@github.com>

On Mon, 12 Jun 2023 19:59:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> II am not sure that is correct way to calculate the dpi based on the "adhoc" change of the image size. That will add the mismatch between the code where we create the image, and the code where we request the image. We probably should change them both, or calculate the dpi in some other way.
>> 
>> Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)
>
>> II am not sure that is correct way to calculate the dpi based on the "adhoc" change of the image size. That will add the mismatch between the code where we create the image, and the code where we request the image.
> 
> There's always a mismatch (at this time). We already discussed it [above](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571).
> 
> For example, for 125% scale, Windows returns 13?13 like for 100%; yet Swing expects 16.25. This is handled by rendering the 13?13-sized theme background into 16?16-sized bitmap ? *to avoid any scale transformations being applied* to keep the image *crisp*.
> 
>> We probably should change them both, or calculate the dpi in some other way.
> 
> The DPI is calculated based on the scale set on the Graphics. Rajat provided the relevant excerpt:
> 
> https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java#L708-L711
> 
> This scale is calculated based on the size of the image.
> 
> So, we probably should? change. As [I already said](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571), this fix should've been as simple as a `MultiResolutionImage` where [`getResolutionVariant`](https://github.com/openjdk/jdk/blob/a780bf0dda4c2c3dce4337ccea37bcdce52045de/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L316) returns the image of the correct size if it's already stored or retrieves it from the system. But it's not the case, and `CachedPainter` seems to be a hindrance rather than a helper.
> 
> That being said, we're planning to look further into simplifying it. Perhaps, `XPStyle.SkinPainter` shouldn't extend `CachedPainter`?
> 
>> Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)
> 
> The point of the this fix is to *avoid rescaling* what Windows returns. And it *succeeds*: check boxes and radio buttons look much better ? sharper and crisper ? when you drag Swing UI frame from a display with one DPI to that with another; they even look better on the main display if its DPI is 120 or 168, that is 125% and 175% correspondingly.

> > II am not sure that is correct way to calculate the dpi based on the "adhoc" change of the image size. That will add the mismatch between the code where we create the image, and the code where we request the image.
> 
> There's always a mismatch (at this time). We already discussed it [above](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571).
> 
> For example, for 125% scale, Windows returns 13?13 like for 100%; yet Swing expects 16.25. This is handled by rendering the 13?13-sized theme background into 16?16-sized bitmap ? _to avoid any scale transformations being applied_ to keep the image _crisp_.

Are you sure? Currently the code for image [creation](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155) and the image [requests](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L317) use the same "ceil" logic.

> The DPI is calculated based on the scale set on the Graphics. Rajat provided the relevant excerpt:
> 
> https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java#L708-L711
> 
> This scale is calculated based on the size of the image.

I am still would like to get clarification about the size we changed by the patch, is it a size of the destination area we should render the component to, or something different. If it is a size of the destination area how we can change that to calculate the DPI? 

> > Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)
> 
> The point of the this fix is to _avoid rescaling_ what Windows returns. And it _succeeds_: check boxes and radio buttons look much better ? sharper and crisper ? when you drag Swing UI frame from a display with one DPI to that with another; they even look better on the main display if its DPI is 120 or 168, that is 125% and 175% correspondingly.

Since we cannot guarantee that the Windows always return exact size we should have a backup code to rescale the image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227217269


From aivanov at openjdk.org  Mon Jun 12 21:04:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Jun 2023 21:04:57 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v14]
In-Reply-To: <w6vPerx744LYfPWtOcDHeoJvO264GXckiZ-ljQLAumo=.f5078e65-38aa-4c46-a0fe-4997420b6200@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <H8W5epzwyedzU4yq46Gw3utW48_9wA7znYhNeZp94a4=.9128e201-1f97-49ad-b09c-98d2e5601d37@github.com>
 <t4n9kKlBH4oX9834I1HaxxZFVkOiK7hBryYs5afLdhM=.646fa069-ae52-45c0-90c5-c87854498176@github.com>
 <e09Hz4-rIyilfyIAScwRPNTSxaY9sBTVqG-3Ldadpps=.a5d6ed0d-5b4c-40af-b6ee-a0e2db363657@github.com>
 <p570rtlHFq06qTi8tcgchz-u-RZIhrdFf4HsfHJp-R8=.4fe51844-ffc2-4336-9f41-e5f585b456db@github.com>
 <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com>
 <LRFE_yQ1TP9U9oqKQWebfLqDqLBk_uQBIBzXgf5jPCU=.a6e0ad85-7152-4efe-86c1-390456ead668@github.com>
 <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com>
 <T_HP7giwt2yfQKM9qKWzpqp0znyiKpHSow5qJ8z4uJE=.41863916-bb8f-49d9-835b-c3adbec9731d@github.com>
 <eYQxuIHx0s_EmaRlnJyUrefxPmD-szn9tW6Es62-NNo=.acd25fe6-e902-48b6-b741-6a43dcd5a8c8@github.com>
 <ovOknDDWPerdOVVdPGKdI9zhVX0F3Zbs-aA
 e70_-rEE=.aae5fc64-34b6-4a16-9636-f4a333b26a4c@github.com>
 <vjdlejlnD2WOPG0n2aeFa3Jr_6sCtW5_WaJMwji_QSM=.f757c862-b1d4-4966-a251-36b576f50e7b@github.com>
 <33KUlwyZp_cUI9zVYqBp6fbut55FtD4Zlqadq-hPpxs=.5123293e-dd79-4318-9b0e-77030261fefc@github.com>
 <PSbqx6y_ii-ZY4l6Q9VNwmykwEa_-fg69wbS888YO3s=.ed4847f7-8319-4d3b-89c2-1ce9009606b0@github.com>
 <gTkCPraHNaCfl6_3T_ARcq4-Wq0t-47ZNoHpKXRQugo=.1927bfe9-1080-4543-82d7-0f1bb029437c@github.com>
 <bZ8lguWum_j8bm9H65oeyx2liOM3QpWXDS4K2AjeOcU=.0f236ce6-1482-49f5-9500-895fc9f52845@github.com>
 <bCDtlL7ndb_1q6LhqZPNqEDY3CKQw77SmkyrR1cLp-Y=.4e4be911-e54c-428c-939a-616665f196d0@github.com>
 <L_NQEzsrTrx3Jl5b3ms0hU8U-dRdbQTME2LQs_OYhH8=.f6ccfb07-9517-4916-8f4a-dd1d62aa9529@github.com>
 <w6vPerx744LYfPWtOcDHeoJvO264GXckiZ-ljQLAumo=.f5078e65-38aa-4c46-a0fe-4997420b6200@github.com>
Message-ID: <UQF-8v640323RQV-zhFpWWLY1PoaT_EixJN_sSyyqJc=.5d62f242-5410-49ee-8f84-b466cb7f794d@github.com>

On Mon, 12 Jun 2023 20:38:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > There's always a mismatch (at this time). We already discussed it [above](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571).
> >
> > For example, for 125% scale, Windows returns 13?13 like for 100%; yet Swing expects 16.25. This is handled by rendering the 13?13-sized theme background into 16?16-sized bitmap ? _to avoid any scale transformations being applied_ to keep the image _crisp_.
> 
> Are you sure? Currently the code for image [creation](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155) and the image [requests](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L317) use the same "ceil" logic.

Yes, I am. The base width and height are 13?13, in 125% the parameters to `getResolutionVariant` are 16.25 and 16.25 ? so the image created was 17?17.

Yet, as you can see, it doesn't match the destination width and height, so a scale to compensate for it is applied in `CachedPainter`.

With the updated formula, the image created is 16?16 which is closer to the requested size. The scale to compensate for the difference is still applied but it results in less distortion, which eventually looks better.

> > > Also the fact that on the image above one component is rendered twice smaller that another make me think that we did not rescale the image if the Windows return the image of the different size(You probably can prove that by always returning the wrong size from the native and check how it will look on HiDPI screen)
> > 
> > The point of the this fix is to _avoid rescaling_ what Windows returns. And it _succeeds_: check boxes and radio buttons look much better ? sharper and crisper ? when you drag Swing UI frame from a display with one DPI to that with another; they even look better on the main display if its DPI is 120 or 168, that is 125% and 175% correspondingly.
> 
> Since we cannot guarantee that the Windows always return exact size we should have a backup code to rescale the image.

No, we should not have a backup code to rescale the image: we request Windows to paint the image in the resolution appropriate for the DPI set for a display we're rendering for. If, for whatever reason, Windows returns an image that is too small for this DPI, you will notice it in all Windows native controls and apps, Java apps will not be different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227235963


From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk21/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11


From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540


From jlu at openjdk.org  Mon Jun 12 21:29:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:29:54 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775


From prr at openjdk.org  Mon Jun 12 21:31:03 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Jun 2023 21:31:03 GMT
Subject: RFR: 8309756: Occasional crashes with pipewire screen capture on
 Wayland
Message-ID: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>

This fix seems to resolve some occasional crashes in our usage of pipewire for Wayland screen capture.
See the bug report for more information.

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

Commit messages:
 - 8309756

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

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


From kcr at openjdk.org  Mon Jun 12 21:45:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 21:45:55 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
Message-ID: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>

On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

@justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.

See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416


From jlu at openjdk.org  Mon Jun 12 21:55:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:55:48 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
 <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
Message-ID: <ZVzi-lqSlf4r01XSuWXwqs8_Ku3uEGgB_f2BRDOqsvQ=.9c38d799-5e1e-4ec7-8f74-81a9603cde4d@github.com>

On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.
>
> @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.
> 
> See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

@kevinrushforth Thanks for the reminder, will make the change in ML first.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115


From jlu at openjdk.org  Mon Jun 12 22:07:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:07:11 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk/pull/14430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

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


From jlu at openjdk.org  Mon Jun 12 22:16:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:16:50 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <sLPcMLisa0Fflyr2kNxtrP3t6X2r7TFh7K59biOLnuw=.cb69b335-cac4-4565-9587-93d4abfae7ed@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092


From duke at openjdk.org  Mon Jun 12 22:20:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 12 Jun 2023 22:20:53 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089


From achung at openjdk.org  Mon Jun 12 22:29:25 2023
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 12 Jun 2023 22:29:25 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>

> 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:

  use realsync to flush native queue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14226/files
  - new: https://git.openjdk.org/jdk/pull/14226/files/add97291..2f689808

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

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

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


From jlu at openjdk.org  Mon Jun 12 22:32:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88

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

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

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


From jlu at openjdk.org  Mon Jun 12 22:32:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:34 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
Message-ID: <QG0atcb6MH7fn3CaUG7kFAU8Z-0dx0lvt8vPPzz6fD4=.750f4a45-f895-49f6-becd-7d9e6c994207@github.com>

On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:
> 
>> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
>> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
>> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)
> 
> This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807


From honkar at openjdk.org  Mon Jun 12 23:15:01 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 Jun 2023 23:15:01 GMT
Subject: RFR: JDK-8299052 : ViewportOverlapping test fails intermittently
 on Win10 & Win11 [v5]
In-Reply-To: <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
 <XkF2tR6xzQOsKyjsxqaFX11Tk_NNzuglamZN9aazexw=.40872208-21ef-4135-8336-529de069a4b9@github.com>
Message-ID: <SkDbnF2h1GBtQ_k317lnYc_svdct1yaJT-pUxN1SFAU=.5f85d6c7-d03c-48a7-8270-d2c72168b6fd@github.com>

On Wed, 7 Jun 2023 20:48:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
>> 
>> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
>> 
>> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes to screen capture

ViewportOverlappingTest intermittent failure was not replicable during CI testing. It has been de-problemlisted and screen capture code has been added to help debug this intermittent issue in case it should occur again.

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

PR Comment: https://git.openjdk.org/jdk/pull/14289#issuecomment-1588231798


From honkar at openjdk.org  Mon Jun 12 23:15:04 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 Jun 2023 23:15:04 GMT
Subject: Integrated: JDK-8299052 : ViewportOverlapping test fails
 intermittently on Win10 & Win11
In-Reply-To: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
References: <AtkARvjsKqOAD9C0SAVXILx1oguilGOTq1DRCs7QvPw=.d12b2771-7dff-4594-8d14-206fa8de2277@github.com>
Message-ID: <eatB8AHVwoYUC5SPqwWyaTmfi_n76EpFuN802OCu0co=.4eabb0e5-01e7-4cf8-85db-a4d952f5dda7@github.com>

On Fri, 2 Jun 2023 17:56:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping test was failing intermittently during CI runs on Win10 and Win11. 
> 
> Although this intermittent issue wasn't replicable when the individual test as well as the test group was run multiple times. Hence screenshot capture has been at various points in the test to aid debugging this intermittent issue, in case it should occur again. 
> 
> PS: Only relevant code in OverlappingTestBase has been cleaned-up as required by this test. There are other parts of the base class that require code clean-up  which is best if taken up as a separate issue as it has common code across many AWT_Mixing tests.

This pull request has now been integrated.

Changeset: 2dca5ae4
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dca5ae4fdc0a2232a0ca3cd295d57a9e362e64c
Stats:     108 lines in 3 files changed: 48 ins; 13 del; 47 mod

8299052: ViewportOverlapping test fails intermittently on Win10 & Win11

Reviewed-by: aivanov

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

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


From psadhukhan at openjdk.org  Tue Jun 13 10:08:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Jun 2023 10:08:01 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing
Message-ID: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>

Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
I could not find any JBS which did that code change.

Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..

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

Commit messages:
 - test fix
 - test fix
 - 6664309: Docking point of a floating toolbar changes after closing
 - 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/14444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6664309
  Stats: 110 lines in 2 files changed: 101 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14444/head:pull/14444

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


From prappo at openjdk.org  Tue Jun 13 10:11:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:11:28 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/e7a50303...563a8761

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/cccffa66..563a8761

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

  Stats: 11904 lines in 355 files changed: 9502 ins; 1007 del; 1395 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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


From prappo at openjdk.org  Tue Jun 13 10:13:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:13:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
Message-ID: <gl2P0tzBbsQgl6CXhFtwG12d0aX_d2b4G1sIiaOepmY=.a6c0bdaa-1a47-4abb-9a0e-3fb8c8dfe4b7@github.com>

On Thu, 8 Jun 2023 14:47:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: use JavadocTester.out
>   
>   Also, trivially fixes grammar (word order) in a comment.

core-libs, client: any reviewers?

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1588987444


From ngubarkov at openjdk.org  Tue Jun 13 14:10:13 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 13 Jun 2023 14:10:13 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows [v2]
In-Reply-To: <3VhJQbl-oD9hYuyOyhZjaIzShRk7P5YBofaswEIAe-k=.6c95c1e1-24b5-4208-8c58-f316b766e867@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
 <3VhJQbl-oD9hYuyOyhZjaIzShRk7P5YBofaswEIAe-k=.6c95c1e1-24b5-4208-8c58-f316b766e867@github.com>
Message-ID: <3K5i5twxnuFosJMnx26fG3lLZVAEKQGtd3PJ0Bn0NeA=.e419f8e1-ea15-4b6f-a1d9-fe79870eac2c@github.com>

On Tue, 25 Apr 2023 21:17:58 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use malloc instead of fixed size buffers.
>
> src/java.desktop/windows/native/libfontmanager/fontpath.c line 522:
> 
>> 520: #define MAX_DATA_BUFFER (MAX_PATH*2+2)
>> 521:     const wchar_t wname[MAX_NAME_BUFFER];
>> 522:     const char data[MAX_DATA_BUFFER];
> 
> Looking at this I think we need to do more here and forget using the fixed buffer sizes and use what the query returns.
> 
> Let's consider NAME and DATA one at a time.
> 
> 1) NAME
> First note that we call the "W" version of the function so anything that is a string will be measured in wchars, not bytes
> NAME is a string so the value we get back is the number of chars in the string.
> Since we allocate using wchar_t we are OK there.
> But we also need to note that the returned len doesn't include the terminating null.
> So it seems to me that we need to adjust the check
> dwMaxValueNameLen >= MAX_NAME_BUFFER
> 
> 
> However going back to NAME the maximum name len has nothing to do with file paths.
> So FILENAME_MAX and MAX_PATH are completely irrelevant and the code shouldn't be using it for NAME.
> If there's a TTC with 10 fonts in it the name will look like
> "NAME_XXXXXXXXXXXXXX_1 & NAME_XXXXXXXXXXX_2 & ... <elided> ...... & NAME_XXXXXXXXXXXX10 ... (TrueType)"
> then we can exceed FILENAME_MAX and MAX_PATH very easily.
> [BTW I checked and FILENAME_MAX and MAX_PATH are both 260]
> 
> So I think we need to dynamically allocate the buffer based on the returned value of dwMaxValueNameLen
> which does NOT include the terminating NULL.
> 
> So I'd want code like
> wname = (wchar_t*)(calloc(dwMaxValueNameLen+1, sizeof(wchar_t))
> 
> and then remember to  add code to free wname (!)
> 
> 2) DATA
> Since FILENAME_MAX and MAX_PATH are both 260, the current proposal doesn't change anything for NAME.
> However it doubles the allocation for DATA. I can see why this is needed.
> I see that for user installed fonts the registry value is the whole path (folder path + filename) ,
> whereas for the installed fonts for which this was "designed" it is just the file name.
> But why use the hard coded value when the registry call already told us what we need ?
> 
> RegQueryInfoKeyW specifies that it returns the data length in BYTES.
> However we know its a unicode string, so depending how we allocate the array
> its either len or len/2 - if its wchar_t.
> 
> wchar_t *data = (wchar_t*)(calloc(dwMaxValueNameLen, sizeof(char))
> 
> - we already cast to LPWSTR so why not make it a wchar_t anyway ?
> - I used calloc just to be paranoid to get zeroed out memory
> - I tested and can confirm that for DATA the returned len includes the allocation for the term...

Changed to dynamic allocation as you suggested. Though I used malloc, because it seems to be used more common across JDK code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13359#discussion_r1228189181


From ngubarkov at openjdk.org  Tue Jun 13 14:10:11 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 13 Jun 2023 14:10:11 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows [v2]
In-Reply-To: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
Message-ID: <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>

> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.

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

  Use malloc instead of fixed size buffers.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13359/files
  - new: https://git.openjdk.org/jdk/pull/13359/files/63d26f84..d6218b55

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

  Stats: 22 lines in 1 file changed: 6 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13359/head:pull/13359

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


From dmarkov at openjdk.org  Tue Jun 13 14:33:09 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 13 Jun 2023 14:33:09 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
Message-ID: <e4E4HQ47c-vLhysSDtMhnAd2XGq6lB_J-H8VZwZGbBg=.e2432b54-f91c-49db-8a56-361b76fee435@github.com>

On Mon, 12 Jun 2023 22:29:25 GMT, Alisen Chung <achung at openjdk.org> 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:
> 
>   use realsync to flush native queue

Changes requested by dmarkov (Reviewer).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 989:

> 987:                     // the zoom call toggles between the normal and the max states
> 988:                     unmaximize();
> 989:                     peer.getLWToolkit().realSync();

Well.. `realSync()` works here but I am not sure if that invocation really fixes the issue or just hides it by introducing a delay.
I believe we need some function which ensures that the frame is in correct (`NORMAL`) state right after `unmaximize()` call and before `execute(CWrapper.NSWindow::miniaturize)` invocation.

Possible implementation of that method below:


private void waitForWindowState(int state) {
        Object lock = new Object();
        target.addWindowStateListener(new WindowStateListener() {
            public void windowStateChanged(WindowEvent e) {
                synchronized(lock) {
                    if (e.getNewState() == state) {
                        lock.notifyAll();
                    }
                }
            }
        });
        if (peer.getState() != state) {
            synchronized(lock) {
                try {
                    lock.wait();
                } catch(InterruptedException ie) {}
            }
        }
    }


So in code you will call `waitForWindowState(Frame.NORMAL)` instead of `realSync()`

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

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1477327791
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1228226627


From aturbanov at openjdk.org  Tue Jun 13 16:23:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 16:23:56 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v4]
In-Reply-To: <3mGy7OIRo7dBx2h7UrD4mkIuZZ8IE5trV3kR-XncKvg=.72d6fd11-3906-4083-9244-0c2cc01ddcbd@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <3mGy7OIRo7dBx2h7UrD4mkIuZZ8IE5trV3kR-XncKvg=.72d6fd11-3906-4083-9244-0c2cc01ddcbd@github.com>
Message-ID: <--0mnH2-hWpxjD5QbsiviuT26U7-Try0OEoEikltot8=.a96be324-2b06-490b-bd97-59622858e360@github.com>

On Mon, 12 Jun 2023 10:40:03 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix - Modified setGC to use getAppropriateGC

src/java.desktop/share/classes/java/awt/Window.java line 3218:

> 3216:     @Override
> 3217:     void setGraphicsConfiguration(GraphicsConfiguration gc) {
> 3218:         synchronized(getTreeLock()) {

Suggestion:

        synchronized (getTreeLock()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1228398187


From avu at openjdk.org  Tue Jun 13 17:01:49 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 13 Jun 2023 17:01:49 GMT
Subject: RFR: 8309756: Occasional crashes with pipewire screen capture on
 Wayland
In-Reply-To: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
References: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
Message-ID: <i6sZxVMo5O23Vib8xS2ArbhjOaTdOaLPrK5-liXcKV4=.2922f794-3d76-4cfd-a993-e8dc197b2a43@github.com>

On Mon, 12 Jun 2023 21:24:16 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix seems to resolve some occasional crashes in our usage of pipewire for Wayland screen capture.
> See the bug report for more information.

Looks good to me

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14428#pullrequestreview-1477670731


From naoto at openjdk.org  Tue Jun 13 18:41:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:41:52 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:

> 138: 
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf

Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505:

> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505: 

These translations are very cryptic. Cannot understand it at first hand.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:

> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959: 

The translation of "well-formed" is incorrect. It is not ???

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

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769


From rriggs at openjdk.org  Tue Jun 13 18:43:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 18:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <G-5lUrL5o1mHBF518jX21fRDl9mfxMVsTU07-gS2piA=.d9caf34d-c126-4168-a6c1-5748f3ba9c74@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6992bbe1...563a8761

Look ok for core-libs classes

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477840678


From jlu at openjdk.org  Tue Jun 13 18:56:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 18:56:44 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>

On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
> 
>> 138: 
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
> 
> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:
> 
>> 957: 
>> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959: 
> 
> The translation of "well-formed" is incorrect. It is not ???

For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665


From aivanov at openjdk.org  Tue Jun 13 19:31:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <YN_XIXW4Pky8-d7C7JXyQiDrT5B98PQjkKd3EhgKoVs=.d8fe969f-d5be-48d6-8814-31e951becf84@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/79d4fbab...563a8761

Looks good to me for client changes.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477876414


From aivanov at openjdk.org  Tue Jun 13 19:31:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:59 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
 <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
Message-ID: <XryojXZM0ga3TLZZDfzG85pI_XAwPs7ZY4uNgb3PahM=.fa4efe54-e45d-4567-af0a-f1f431321c14@github.com>

On Thu, 8 Jun 2023 15:51:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
>> 
>>     @param e the element to add
>> 
>> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
>> 
>> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
>> 
>> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
>> 
>>  - javax.imageio.stream.ImageInputStream#flushBefore
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed.
>>     ```
>> 
>>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed to the destination.
>>     ```
>> Hence, the correction. Does it clarify the matter?
>
> Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:
> 
> /** {@inheritDoc} */
> 
> It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

Thank you, it helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228577519


From naoto at openjdk.org  Tue Jun 13 20:24:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 20:24:46 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some suggestions. Should be looked at by translators later.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

Suggestion:

FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502:

> 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501: 
> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504:

> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956:

> 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955: 
> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958:

> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384


From weijun at openjdk.org  Tue Jun 13 20:58:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jun 2023 20:58:51 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Some comments:

- `src/java.base/share/classes/sun/launcher/resources/launcher`

`? private`. "private" should be translated, just like the "static" in the 2nd box.

- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`

`compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?

`compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.

`compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".


- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:

`javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.

- `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`

I don't think the new translation is better than the old one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825


From jlu at openjdk.org  Tue Jun 13 21:06:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:25 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <geYM5H0XN5NNvVmRzx5TxgqMaD17xbb7-DCnO_oFVbw=.d00caade-f19d-466e-a71d-7f7cbba183cc@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Review: use Naoto's recommended ja values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb

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

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

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


From jlu at openjdk.org  Tue Jun 13 21:06:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:28 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
Message-ID: <Kj4eUHsEVJoYJLTG7eTiBVFd68yRljmoagn0pAEqPdI=.0c0cf9b7-9710-4802-9cce-aad8c0f35a71@github.com>

On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:
> 
>> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
>> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
>> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
> 
> Suggestion:
> 
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234


From jlu at openjdk.org  Tue Jun 13 22:09:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:40 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512

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

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

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


From jlu at openjdk.org  Tue Jun 13 22:09:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:43 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
Message-ID: <eUpEuDxtBW4zFIazvfci4moBpPFzPDXyAkpgYNd4F9E=.61170e21-43a3-40d7-a5cc-fc9685a8a2e2@github.com>

On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> Some comments:
> 
> - `src/java.base/share/classes/sun/launcher/resources/launcher`
> 
> `? private`. "private" should be translated, just like the "static" in the 2nd box.
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`
> 
> `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?
> 
> `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.
> 
> `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".
> 
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
> - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> I don't think the new translation is better than the old one.

Thank you for the review @wangweij,

I have addressed these recommendations

>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
>     * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> 
> I don't think the new translation is better than the old one.

For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. 

I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839


From smarks at openjdk.org  Tue Jun 13 23:28:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 23:28:06 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/332eaf7c...563a8761

I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478203733


From naoto at openjdk.org  Wed Jun 14 00:09:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 00:09:03 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
Message-ID: <sGkMLbM6Iyp04SnzPdG_CLR9wMlzypOQwrpdy_9iheM=.1f136a3d-f264-42a2-85e5-c4506564eb74@github.com>

On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value

Looks good, Justin

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336


From martin at openjdk.org  Wed Jun 14 00:53:08 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 00:53:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
Message-ID: <exFXZi0DI28DB807MgElHWkyA2xeAEybsLjwb3Vm7GI=.c0d93736-d6cb-4a97-bead-cc817b24c2dc@github.com>

On Tue, 13 Jun 2023 23:24:46 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

I agree with stuart-marks@

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590262295


From martin at openjdk.org  Wed Jun 14 01:23:20 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 01:23:20 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/0db0007a...563a8761

We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:

> 1532: 
> 1533:     /**
> 1534:      * {@inheritDoc ConcurrentMap}

This clarifies the authors' intent, so is clear progress. 

Semantic difficulties remain:
- it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
- we never want to inherit AbstractFoo @implNotes
- ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

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

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478285774
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228861243


From itakiguchi at openjdk.org  Wed Jun 14 04:54:59 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 14 Jun 2023 04:54:59 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded
In-Reply-To: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
References: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
Message-ID: <E1zkdkQ_Mf4nY37C_9Y1Mfi7CrQX0wWyHxDcMN606s8=.8c1ef1bd-ec66-4422-8ac6-83c14d48b944@github.com>

On Thu, 20 Apr 2023 05:47:35 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> 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...

Gentle reminder, can I have a reviewer's comment ?
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1590464753


From tr at openjdk.org  Wed Jun 14 07:32:51 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Jun 2023 07:32:51 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v5]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/0b7bc979..ff0b5ee8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=03-04

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

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


From prappo at openjdk.org  Wed Jun 14 09:02:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 09:02:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <1l4rCRZlweJ91CBc-cVcKLnqMAfXZtLThPK2EQ_hk-Y=.e7349c38-3bf7-46c9-95a6-3127959488d3@github.com>

On Wed, 14 Jun 2023 01:19:57 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

I've generated something you might find helpful: https://cr.openjdk.org/~prappo/8285368/specdiff/overview-summary.html

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590779943


From tr at openjdk.org  Wed Jun 14 09:25:14 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Jun 2023 09:25:14 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label cut
 off in Metal Look&Feel
Message-ID: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>

"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)

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

Commit messages:
 - Removed white space
 - Fix + Manual Test

Changes: https://git.openjdk.org/jdk/pull/14464/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301606
  Stats: 140 lines in 2 files changed: 139 ins; 0 del; 1 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 Jun 14 09:37:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Jun 2023 09:37:57 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing
In-Reply-To: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
Message-ID: <vED6XZp2KBOxQ9G5aVDFvpKSFhh__QMMF2Cghz3Y_Rw=.4960f2e3-bafb-44ab-99c1-35e68772ce75@github.com>

On Tue, 13 Jun 2023 09:53:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
> This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
> I could not find any JBS which did that code change.
> 
> Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..

test/jdk/javax/swing/JToolBar/TestToolBarConstraint.java line 41:

> 39: import javax.swing.SwingUtilities;
> 40: import javax.swing.SwingConstants;
> 41: import javax.swing.WindowConstants;

Importing `WindowConstants` can be removed, since its not used.

test/jdk/javax/swing/JToolBar/TestToolBarConstraint.java line 69:

> 67:     }
> 68: 
> 69:     private static void creatUI() {

Typo for method name(`createUI`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14444#discussion_r1229309471
PR Review Comment: https://git.openjdk.org/jdk/pull/14444#discussion_r1229312491


From psadhukhan at openjdk.org  Wed Jun 14 09:41:54 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2023 09:41:54 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
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: <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>

On Wed, 14 Jun 2023 09:17:06 GMT, Tejesh R <tr at openjdk.org> 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)

Although this might be a bug in insets but for this issue, I guess in native filechooser, "Size" is left aligned which is what we follow..
I think in Java Windows L&F too, it is right aligned which I think we should rectify otherwise it can come as another bug that we are not following native look..

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1590846544


From abhiscxk at openjdk.org  Wed Jun 14 09:41:58 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Jun 2023 09:41:58 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
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: <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>

On Wed, 14 Jun 2023 09:17:06 GMT, Tejesh R <tr at openjdk.org> 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)

test/jdk/javax/swing/JFileChooser/FileChooserSizeLabelCutOffTest.java line 102:

> 100:         frame.pack();
> 101:         frame.setVisible(true);
> 102:     }

Please add a blank line between method implementation.

test/jdk/javax/swing/JFileChooser/FileChooserSizeLabelCutOffTest.java line 111:

> 109:         detailsBtn.doClick();
> 110:     }
> 111:     private static AbstractButton findDetailsButton(final Container container) {

Please add a blank line here as well.

test/jdk/javax/swing/JFileChooser/FileChooserSizeLabelCutOffTest.java line 118:

> 116:     }
> 117: 
> 118:     private static JTable findTable(final Container container) {

This method is not called at any place, can it be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1229315240
PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1229315941
PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1229316858


From psadhukhan at openjdk.org  Wed Jun 14 09:45:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2023 09:45:20 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing [v2]
In-Reply-To: <vED6XZp2KBOxQ9G5aVDFvpKSFhh__QMMF2Cghz3Y_Rw=.4960f2e3-bafb-44ab-99c1-35e68772ce75@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
 <vED6XZp2KBOxQ9G5aVDFvpKSFhh__QMMF2Cghz3Y_Rw=.4960f2e3-bafb-44ab-99c1-35e68772ce75@github.com>
Message-ID: <ojrmclIlrU5ufMoxxhlkVg5mOKEsG0XGygiZjvkCBj8=.6a8aaf76-2cd6-421c-81cf-ff2a0448d732@github.com>

On Wed, 14 Jun 2023 09:33:06 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/JToolBar/TestToolBarConstraint.java line 41:
> 
>> 39: import javax.swing.SwingUtilities;
>> 40: import javax.swing.SwingConstants;
>> 41: import javax.swing.WindowConstants;
> 
> Importing `WindowConstants` can be removed, since its not used.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14444#discussion_r1229319399


From psadhukhan at openjdk.org  Wed Jun 14 09:45:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2023 09:45:17 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing [v2]
In-Reply-To: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
Message-ID: <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>

> Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
> This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
> I could not find any JBS which did that code change.
> 
> Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14444/files
  - new: https://git.openjdk.org/jdk/pull/14444/files/e6f00e60..d941bebb

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

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

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


From prappo at openjdk.org  Wed Jun 14 10:10:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 10:10:02 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>

On Wed, 14 Jun 2023 01:15:51 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> * we never want to inherit AbstractFoo @implNotes

`@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:

    @implSpec {@inheritDoc}

> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1229354100


From psadhukhan at openjdk.org  Wed Jun 14 12:50:13 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2023 12:50:13 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
Message-ID: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>

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.

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

Commit messages:
 - 8049347: HTMLDocument throws NPE for Block Tag
 - 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/14466/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14466&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8049347
  Stats: 43 lines in 2 files changed: 39 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14466/head:pull/14466

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


From asemenov at openjdk.org  Wed Jun 14 13:19:01 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 14 Jun 2023 13:19:01 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v5]
In-Reply-To: <lh9SAkxvg76-gmSiZ-uvurU4vQKzrOqv1r8NapIg8cY=.2d5b0e6d-20ff-471f-a010-caf2899e81d0@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
 <lh9SAkxvg76-gmSiZ-uvurU4vQKzrOqv1r8NapIg8cY=.2d5b0e6d-20ff-471f-a010-caf2899e81d0@github.com>
Message-ID: <onxMhGDyupiLEnP5ZG2y6Tf7MYzjjQI3Jv1GUUa9Jvw=.06b04347-8eb0-48b8-b4f3-ea454abaed4e@github.com>

On Tue, 16 May 2023 17:56:04 GMT, Artem Semenov <asemenov at openjdk.org> 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 need to close this pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/13001#issuecomment-1591191482


From tr at openjdk.org  Wed Jun 14 15:52:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Jun 2023 15:52:57 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>
Message-ID: <FfVvDRqwanRzHM-44jaI8KuqrVb8YkyTwkgkIva725I=.8c5de64b-f702-4a2c-8ac7-7864eea060af@github.com>

On Wed, 14 Jun 2023 09:36:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although this might be a bug in insets but for this issue, I guess in native filechooser, "Size" is left aligned which is what we follow.. I think in Java Windows L&F too, it is right aligned which I think we should rectify otherwise it can come as another bug that we are not following native look..

Yeah, can do that, will update that also in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1591521277


From jlu at openjdk.org  Wed Jun 14 16:25:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Jun 2023 16:25:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
Message-ID: <i2xpAM4Cbkg3wxLwU6xXUsAerpA3w3n1wHE9BFFtI0Q=.49a5cd2b-b201-4322-af3a-dd198470a544@github.com>

On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
>> 
>>> 138: 
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
>> 
>> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance.

The language specialist confirmed the double quotes are locale specific for de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212


From honkar at openjdk.org  Wed Jun 14 18:18:01 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 Jun 2023 18:18:01 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
Message-ID: <y5mVYl-tNk2vFHFyZMMzRCT_KAI_pDyahcIQvSfiPxA=.b2d80eb1-72d5-45b2-a519-3fdeb9eaaa31@github.com>

On Mon, 12 Jun 2023 22:29:25 GMT, Alisen Chung <achung at openjdk.org> 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:
> 
>   use realsync to flush native queue

@alisenchung 

The current fix works for the cases listed in the test but fails for the following scenarios. To make the test more stable it is better to reassign the static variable `lastFrameState = Frame.NORMAL` in examineStates after creating a new Frame [here ](https://github.com/openjdk/jdk/blob/57b8251241e2044d5039ce162bf4637a9b2e5466/test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java#L78), so that each time a new case is run it sets lastFrameState to default state.


// CASE 1:
examineStates(new int[] {Frame.NORMAL, Frame.MAXIMIZED_BOTH, Frame.ICONIFIED});
// CASE 2:
examineStates(new int[] {Frame.NORMAL, Frame.ICONIFIED, Frame.MAXIMIZED_BOTH});

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

Changes requested by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1480046670


From honkar at openjdk.org  Wed Jun 14 18:33:23 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 Jun 2023 18:33:23 GMT
Subject: RFR: JDK-8309958: Incorrect @since tag format in Container.java
Message-ID: <l78Xx-MpAs4SZMYc4EfMCItcZqH-FAKw2zjfQhxXVdw=.2f940c47-e6a7-4afe-8a00-1fc8c8b7b57b@github.com>

Minor Javadoc change for since tag in Container.java

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

Commit messages:
 - minor java doc change

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

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


From dmarkov at openjdk.org  Wed Jun 14 19:26:58 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 14 Jun 2023 19:26:58 GMT
Subject: RFR: JDK-8309958: Incorrect @since tag format in Container.java
In-Reply-To: <l78Xx-MpAs4SZMYc4EfMCItcZqH-FAKw2zjfQhxXVdw=.2f940c47-e6a7-4afe-8a00-1fc8c8b7b57b@github.com>
References: <l78Xx-MpAs4SZMYc4EfMCItcZqH-FAKw2zjfQhxXVdw=.2f940c47-e6a7-4afe-8a00-1fc8c8b7b57b@github.com>
Message-ID: <JJXtirYrIK0V47iffWJxwApEKH2cJn4AS1haPG7NCV0=.8b875c30-6da4-4ff6-a651-28deaf6f6bbe@github.com>

On Wed, 14 Jun 2023 18:25:31 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Minor Javadoc change for since tag in Container.java

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14474#pullrequestreview-1480151433


From honkar at openjdk.org  Wed Jun 14 19:52:05 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 Jun 2023 19:52:05 GMT
Subject: Integrated: JDK-8309958: Incorrect @since tag format in Container.java
In-Reply-To: <l78Xx-MpAs4SZMYc4EfMCItcZqH-FAKw2zjfQhxXVdw=.2f940c47-e6a7-4afe-8a00-1fc8c8b7b57b@github.com>
References: <l78Xx-MpAs4SZMYc4EfMCItcZqH-FAKw2zjfQhxXVdw=.2f940c47-e6a7-4afe-8a00-1fc8c8b7b57b@github.com>
Message-ID: <EGSp82D1GPoPjRyLqGCBxni2gS7bAFe9ocwYAKUtxrI=.273b131e-7d01-4f5f-998b-42f11448e5df@github.com>

On Wed, 14 Jun 2023 18:25:31 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Minor Javadoc change for since tag in Container.java

This pull request has now been integrated.

Changeset: ee4ab670
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8309958: Incorrect @since tag format in Container.java

Reviewed-by: dmarkov

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

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


From prr at openjdk.org  Wed Jun 14 20:12:59 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 Jun 2023 20:12:59 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
Message-ID: <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>

On Mon, 12 Jun 2023 22:29:25 GMT, Alisen Chung <achung at openjdk.org> 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:
> 
>   use realsync to flush native queue

I don't like the idea of a delay in either of the ways discussed here.
And although I do think that its much better to wait for delivery of an event,  I'm not sure I understand the windowState listener proposal.
How do you know in this code that the transition of
iconified-> normal will then followed by normal->maximised ?
Perhaps you'll wait for ever ?
But I don't know what the macOS native model is for all of this.
This sequence is kind of odd and I'm curious what happens on older macOS releases - Sergey touched on this but I don't see direct followup.
There seems to be assumptions it was like this previously but now it is slower ?

I suggest explicit verification of what happens on macOS 12.6.
Are we now getting two native events when there used to be only one ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1591904154


From aivanov at openjdk.org  Wed Jun 14 20:26:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Jun 2023 20:26:07 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
Message-ID: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>

After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:

https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109

After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.

This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).

**Fix**

The insets are updated in the native implementation of `setSpans` directly.

The native implmenation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

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

Commit messages:
 - 8297923: Add the bugid to the test
 - 8310054: ScrollPane insets are incorrect

Changes: https://git.openjdk.org/jdk/pull/14478/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310054
  Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14478/head:pull/14478

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


From achung at openjdk.org  Wed Jun 14 20:37:59 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 14 Jun 2023 20:37:59 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
 <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>
Message-ID: <nUShWDISGozG3gLdI1JFruD8chLxHIXvae2nk_-58DQ=.d5bd497c-37cf-4db6-a287-7edf263cc15d@github.com>

On Wed, 14 Jun 2023 20:09:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't like the idea of a delay in either of the ways discussed here. And although I do think that its much better to wait for delivery of an event, I'm not sure I understand the windowState listener proposal. How do you know in this code that the transition of iconified-> normal will then followed by normal->maximised ? 

The code here is trying to do a transition from iconified -> maximized, but splits it up into iconified -> normal and normal -> maximized.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1591942508


From dmarkov at openjdk.org  Wed Jun 14 20:52:04 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 14 Jun 2023 20:52:04 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
 <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>
Message-ID: <_Nl_l_USUOqQuMcp2uWMsBWhsTUA7NzrL0pqhTOWk88=.34e5d47a-4142-49a8-9b8d-9e182c0a1fc3@github.com>

On Wed, 14 Jun 2023 20:09:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't like the idea of a delay in either of the ways discussed here. And although I do think that its much better to wait for delivery of an event, I'm not sure I understand the windowState listener proposal. How do you know in this code that the transition of iconified-> normal will then followed by normal->maximised ? Perhaps you'll wait for ever ? But I don't know what the macOS native model is for all of this. This sequence is kind of odd and I'm curious what happens on older macOS releases - Sergey touched on this but I don't see direct followup. There seems to be assumptions it was like this previously but now it is slower ?
> 
> I suggest explicit verification of what happens on macOS 12.6. Are we now getting two native events when there used to be only one ?

We cannot move a frame directly from `ICONIFIED` to `MAXIMIZED_BOTH` and vice versa. We need to go through the `NORMAL` state, (i.e. `ICONIFIED` -> `NORMAL` -> `MAXIMIZED_BOTH`). If my memory does not fail me we use that approach from the very beginning.

We perform two state-transitions subsequently and don't care of real state of the frame between them. It used to work till macOS 13 where the transition from one state to another takes a bit longer. 
In other words we do `ICONIFIED` -> `NORMAL` and then immediately `NORMAL` -> `MAXIMIZED_BOTH` but the frame is NOT in `NORMAL` state yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1591957725


From aivanov at openjdk.org  Wed Jun 14 21:10:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Jun 2023 21:10:57 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <FfVvDRqwanRzHM-44jaI8KuqrVb8YkyTwkgkIva725I=.8c5de64b-f702-4a2c-8ac7-7864eea060af@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>
 <FfVvDRqwanRzHM-44jaI8KuqrVb8YkyTwkgkIva725I=.8c5de64b-f702-4a2c-8ac7-7864eea060af@github.com>
Message-ID: <nnBNE4z0lZmMF-5-O_zOxHIxDBdXP5A-epcUH79yffo=.08ae7405-4c95-4087-aa01-bdbb83d23a0c@github.com>

On Wed, 14 Jun 2023 15:50:29 GMT, Tejesh R <tr at openjdk.org> wrote:

> Although this might be a bug in insets but for this issue, I guess in native filechooser, "Size" is left aligned which is what we follow.. I think in Java Windows L&F too, it is right aligned which I think we should rectify otherwise it can come as another bug that we are not following native look..

Java L&F may not follow what native File Explorers / Navigators do ? after all, it's a Java Look-and-Feel.

On Windows, Explorer displays the Size header left-aligned as all other headers, yet the values in the Size column are right-aligned. If Swing doesn't allow different alignment for the header cell and data cells in a column, then we should preserve right-alignment.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1591988020


From aivanov at openjdk.org  Wed Jun 14 21:17:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Jun 2023 21:17:59 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
Message-ID: <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>

On Wed, 14 Jun 2023 09:38:54 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This method is not called at any place, can it be removed?

This and following `find`-methods are from an automated test, they should be removed unless it's possible to automate the test.

Is it possible? It could be. You have to determine the coordinates of the header cell, then take a MRI screenshot, verify the 2*scale right-most pixels are filled with header background color only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230177774


From aivanov at openjdk.org  Wed Jun 14 21:33:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Jun 2023 21:33:59 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
Message-ID: <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>

On Wed, 14 Jun 2023 12:43:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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.

src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 550:

> 548:         if (t.isBlock()) {
> 549:             // TBD
> 550:             return null;

This doesn't look right to me. The comment suggests the implementation of something like `BlockIterator` is missing.

I would expect that iterator for `HTML.Tag.HEAD` returns all elements inside `<head>` element. Yet the comment for the `next` method

https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L1993-L1997

suggests, the iterator goes over all instances of the specified tag in the document.

What does the iterator return if you pass it `HTML.Tag.HEAD` or `HTML.Tag.P`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14466#discussion_r1230191266


From psadhukhan at openjdk.org  Thu Jun 15 03:53:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Jun 2023 03:53:58 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
 <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>
Message-ID: <5WiP9hIJOGk9XlFjE050ERL6rWBUZHYXg6VrPwbZKAk=.7af12729-7fe3-478b-bf5d-6a60ec262d62@github.com>

On Wed, 14 Jun 2023 21:30:43 GMT, Alexey Ivanov <aivanov at openjdk.org> 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.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 550:
> 
>> 548:         if (t.isBlock()) {
>> 549:             // TBD
>> 550:             return null;
> 
> This doesn't look right to me. The comment suggests the implementation of something like `BlockIterator` is missing.
> 
> I would expect that iterator for `HTML.Tag.HEAD` returns all elements inside `<head>` element. Yet the comment for the `next` method
> 
> https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L1993-L1997
> 
> suggests, the iterator goes over all instances of the specified tag in the document.
> 
> What does the iterator return if you pass it `HTML.Tag.HEAD` or `HTML.Tag.P`?

It returns a LeafIterator object with HEAD or P tag respectively

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14466#discussion_r1230390783


From tr at openjdk.org  Thu Jun 15 04:20:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Jun 2023 04:20:12 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v3]
In-Reply-To: <WxGtU5Bm32PKgzW4B8uoQJP2mr71vW5YYokaZNZII_Q=.4986226c-58fd-4ab9-be4b-6223bd2ea373@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <0U4o0wDAMN2XQi-fGvnSmjT9r2iQ_OZgOXLHbSDrig0=.a35a7c74-dcad-4670-8de6-775455529f30@github.com>
 <WxGtU5Bm32PKgzW4B8uoQJP2mr71vW5YYokaZNZII_Q=.4986226c-58fd-4ab9-be4b-6223bd2ea373@github.com>
Message-ID: <AR2c_phzROMb1_t3_LbBfhBg3OKyJoaDH3jH0-A4txk=.85323ac0-829d-45d3-9a47-f9d420a64b93@github.com>

On Thu, 8 Jun 2023 01:26:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> I assume that the pre-integration testing is green.

@azvegint @DamonGuy Can you please re-review the PR and let me know if the updated fix is fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1592327289


From tr at openjdk.org  Thu Jun 15 04:22:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Jun 2023 04:22:56 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
 <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
Message-ID: <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>

On Wed, 14 Jun 2023 21:15:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileChooserSizeLabelCutOffTest.java line 118:
>> 
>>> 116:     }
>>> 117: 
>>> 118:     private static JTable findTable(final Container container) {
>> 
>> This method is not called at any place, can it be removed?
>
>> This method is not called at any place, can it be removed?
> 
> This and following `find`-methods are from an automated test, they should be removed unless it's possible to automate the test.
> 
> Is it possible? It could be. You have to determine the coordinates of the header cell, then take a MRI screenshot, verify the 2*scale right-most pixels are filled with header background color only.

Yeah, was actually trying to do that but couldn't get exact coordinates of header cell. Later on forgot to remove the unused methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230405238


From tr at openjdk.org  Thu Jun 15 05:40:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Jun 2023 05:40:56 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <nnBNE4z0lZmMF-5-O_zOxHIxDBdXP5A-epcUH79yffo=.08ae7405-4c95-4087-aa01-bdbb83d23a0c@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>
 <FfVvDRqwanRzHM-44jaI8KuqrVb8YkyTwkgkIva725I=.8c5de64b-f702-4a2c-8ac7-7864eea060af@github.com>
 <nnBNE4z0lZmMF-5-O_zOxHIxDBdXP5A-epcUH79yffo=.08ae7405-4c95-4087-aa01-bdbb83d23a0c@github.com>
Message-ID: <EyGTAbTE4wP9ob85XFzsMc_oO_cr335n1fkPwnjwpcU=.3a3e63da-c800-468d-a1d9-aad0661a5d8d@github.com>

On Wed, 14 Jun 2023 21:08:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Although this might be a bug in insets but for this issue, I guess in native filechooser, "Size" is left aligned which is what we follow.. I think in Java Windows L&F too, it is right aligned which I think we should rectify otherwise it can come as another bug that we are not following native look..
> 
> Java L&F may not follow what native File Explorers / Navigators do ? after all, it's a Java Look-and-Feel.
> 
> On Windows, Explorer displays the Size header left-aligned as all other headers, yet the values in the Size column are right-aligned. If Swing doesn't allow different alignment for the header cell and data cells in a column, then we should preserve right-alignment.

Hmm, I do have a fix if we are planning to make it similar to native (Window, Linux and MacOS). And FYI, windows native API [getdetailsof](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder2-getdetailsof) gives the alignment for columns irrespective of header/data, which is RIGHT alignment for `Size` column. If it is still debatable, then will it be better to open a new bug on Size alignment issue and handle it there?

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1592396004


From tr at openjdk.org  Thu Jun 15 05:40:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Jun 2023 05:40:57 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
 <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
 <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>
Message-ID: <DLgKr1IKuN4oBqk7yNs4QntHCn_uiiPNQ73ytxLb4i8=.02eca269-1d12-4a50-b2fb-80f38f7b4b1f@github.com>

On Thu, 15 Jun 2023 04:19:45 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> This method is not called at any place, can it be removed?
>> 
>> This and following `find`-methods are from an automated test, they should be removed unless it's possible to automate the test.
>> 
>> Is it possible? It could be. You have to determine the coordinates of the header cell, then take a MRI screenshot, verify the 2*scale right-most pixels are filled with header background color only.
>
> Yeah, was actually trying to do that but couldn't get exact coordinates of header cell. Later on forgot to remove the unused methods.

And also it's not possible to verify with background color because anti-aliasing, I guess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230456769


From jwaters at openjdk.org  Thu Jun 15 06:04:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 06:04:59 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <oXroh-ZQ9Vi9soyH4FRvoOrAvfLdFgW_OPu4TuRrdJM=.431e64a6-321e-49dc-9796-0ee38eedfcf2@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1592418574


From jwaters at openjdk.org  Thu Jun 15 06:04:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 06:04:59 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <TthdpHmF-DkthSUcBR_6n3lr-hlNFQqBXJW9_KxyGdU=.8aa774b2-4379-4720-aaaa-9c5a52a9562a@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1592419125


From aivanov at openjdk.org  Thu Jun 15 07:46:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 07:46:59 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <5WiP9hIJOGk9XlFjE050ERL6rWBUZHYXg6VrPwbZKAk=.7af12729-7fe3-478b-bf5d-6a60ec262d62@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
 <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>
 <5WiP9hIJOGk9XlFjE050ERL6rWBUZHYXg6VrPwbZKAk=.7af12729-7fe3-478b-bf5d-6a60ec262d62@github.com>
Message-ID: <9ownzd5dqdKEiGg0IlnVVOAPVHPT6R4T7sRIc38GGnQ=.b36b77de-12e5-4323-a27a-d2055ce0f593@github.com>

On Thu, 15 Jun 2023 03:50:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 550:
>> 
>>> 548:         if (t.isBlock()) {
>>> 549:             // TBD
>>> 550:             return null;
>> 
>> This doesn't look right to me. The comment suggests the implementation of something like `BlockIterator` is missing.
>> 
>> I would expect that iterator for `HTML.Tag.HEAD` returns all elements inside `<head>` element. Yet the comment for the `next` method
>> 
>> https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L1993-L1997
>> 
>> suggests, the iterator goes over all instances of the specified tag in the document.
>> 
>> What does the iterator return if you pass it `HTML.Tag.HEAD` or `HTML.Tag.P`?
>
> It returns a LeafIterator object with HEAD or P tag respectively

Obviously. :)

Does it do what the `getIterator` method promise to do? It doesn't because it iterates over `LeafElement`-s only:

https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L1993-L1998

So, the `next` method moves the iterator to the next leaf element:

https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L2037-L2044

Note that it uses `isLeaf` to stop the generic `ElementIterator`.

---

It looks as if `HTMLDocument.getIterator` is public as an implementation detail: it's used to iterate over `HTML.Tag.A` to scroll the text component to the anchor and to determine whether the document is a frame set or not.

Removing the `if` condition removes the NPE but the method doesn't support Block Elements.

Should we update the javadoc to state the method shouldn't be used by apps? And to throw `UnsupportedOperationException` if a block tag is passed instead of returning null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14466#discussion_r1230580722


From aivanov at openjdk.org  Thu Jun 15 07:50:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 07:50:00 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
Message-ID: <OjMmxulbpRXauxtpFXb1MPE-q8W5pKyND16A4phH1Go=.e6ab7327-5933-4993-9048-f36b75334b7d@github.com>

On Wed, 14 Jun 2023 12:43:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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.

I've edited the JBS subject to ?HTMLDocument.getIterator throws NPE for Block Tag? ? it's more specific: `getIterator` throws NPE.

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

PR Comment: https://git.openjdk.org/jdk/pull/14466#issuecomment-1592533160


From aivanov at openjdk.org  Thu Jun 15 08:13:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 08:13:58 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <EyGTAbTE4wP9ob85XFzsMc_oO_cr335n1fkPwnjwpcU=.3a3e63da-c800-468d-a1d9-aad0661a5d8d@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <_669yDjP2seWJ1E3__xPcbFo6nqAom_ZljKE73ICdtE=.f76e43e8-d88e-4e12-ba4c-7d7dde10b9fe@github.com>
 <FfVvDRqwanRzHM-44jaI8KuqrVb8YkyTwkgkIva725I=.8c5de64b-f702-4a2c-8ac7-7864eea060af@github.com>
 <nnBNE4z0lZmMF-5-O_zOxHIxDBdXP5A-epcUH79yffo=.08ae7405-4c95-4087-aa01-bdbb83d23a0c@github.com>
 <EyGTAbTE4wP9ob85XFzsMc_oO_cr335n1fkPwnjwpcU=.3a3e63da-c800-468d-a1d9-aad0661a5d8d@github.com>
Message-ID: <cnhoSSnb1wGZ3qDfyTi4tDJOMPyCqTLuD3UFkQX1mh0=.87f9460a-4fff-445a-82bf-fb572cc2342a@github.com>

On Thu, 15 Jun 2023 05:35:42 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > Although this might be a bug in insets but for this issue, I guess in native filechooser, "Size" is left aligned which is what we follow.. I think in Java Windows L&F too, it is right aligned which I think we should rectify otherwise it can come as another bug that we are not following native look..
> > 
> > 
> > Java L&F may not follow what native File Explorers / Navigators do ? after all, it's a Java Look-and-Feel.
> > On Windows, Explorer displays the Size header left-aligned as all other headers, yet the values in the Size column are right-aligned. If Swing doesn't allow different alignment for the header cell and data cells in a column, then we should preserve right-alignment.
> 
> Hmm, I do have a fix if we are planning to make it similar to native (Window, Linux and MacOS). And FYI, windows native API [getdetailsof](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder2-getdetailsof) gives the alignment for columns irrespective of header/data, which is RIGHT alignment for `Size` column. If it is still debatable, then will it be better to open a new bug on Size alignment issue and handle it there?

Here's a screenshot of Windows File Explorer:

![Windows File Explorer: Size column is right-aligned, its header is left-aligned](https://github.com/openjdk/jdk/assets/70774172/5b2c13c5-fc7a-47d6-9804-4b5dace0c1d6)

As you can see, the Size column values are right-aligned, its header remains left-aligned as other headers.

In [this comment](https://github.com/openjdk/jdk/pull/9327#issuecomment-1204836731), @kumarabhi006 attached a screenshot of a File Navigator in Oracle Linux: it shows left-aligned for the Size column.

If it's decided to change the alignment of the Size column in Metal L&F, it must be done separately in its own bug. But I don't think we should change it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1592572844


From aivanov at openjdk.org  Thu Jun 15 08:18:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 08:18:59 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <DLgKr1IKuN4oBqk7yNs4QntHCn_uiiPNQ73ytxLb4i8=.02eca269-1d12-4a50-b2fb-80f38f7b4b1f@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
 <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
 <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>
 <DLgKr1IKuN4oBqk7yNs4QntHCn_uiiPNQ73ytxLb4i8=.02eca269-1d12-4a50-b2fb-80f38f7b4b1f@github.com>
Message-ID: <6Ura-GwYnId8LYpXubZEhqgP--a1EOnWJjmMMPBh6xM=.6484bb7d-6a70-40ba-98c1-665832527dd0@github.com>

On Thu, 15 Jun 2023 05:38:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> And also it's not possible to verify with background color because anti-aliasing, I guess.

Why is it? There's no background anti-aliasing, the background is filled with solid color.

You need to use [Robot.createMultiResolutionScreenCapture](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to get the real screen pixels rather than scaled down image as if uiScale=1.0.

You may need to tweak the position of the capture and the area where you sample the pixels.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230623034


From aivanov at openjdk.org  Thu Jun 15 09:02:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 09:02:57 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <6Ura-GwYnId8LYpXubZEhqgP--a1EOnWJjmMMPBh6xM=.6484bb7d-6a70-40ba-98c1-665832527dd0@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
 <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
 <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>
 <DLgKr1IKuN4oBqk7yNs4QntHCn_uiiPNQ73ytxLb4i8=.02eca269-1d12-4a50-b2fb-80f38f7b4b1f@github.com>
 <6Ura-GwYnId8LYpXubZEhqgP--a1EOnWJjmMMPBh6xM=.6484bb7d-6a70-40ba-98c1-665832527dd0@github.com>
Message-ID: <QdeiUOA9SW_MCtS6PGOl9RZ3oXtq51En8q0cin8FxFw=.1a997f74-80da-4c24-8000-4d242adfde7f@github.com>

On Thu, 15 Jun 2023 08:15:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> And also it's not possible to verify with background color because anti-aliasing, I guess.
>
>> And also it's not possible to verify with background color because anti-aliasing, I guess.
> 
> Why is it? There's no background anti-aliasing, the background is filled with solid color.
> 
> You need to use [Robot.createMultiResolutionScreenCapture](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to get the real screen pixels rather than scaled down image as if uiScale=1.0.
> 
> You may need to tweak the position of the capture and the area where you sample the pixels.

It is even simpler. The bug is not `JFileChooser`-specific, it affects each and every `JTable` which has a right-aligned column. Write the test for `JTable` instead. You can have a single right-aligned column with the header text that you control (a lower case letter ?l? will do it greatly). You can render the table into a `BufferedImage` with the scale you need (2.25) and then analyse the pixels in the image.

As simple as that. It's not necessary to create real UI for this kind of test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230684004


From prappo at openjdk.org  Thu Jun 15 09:22:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 09:22:32 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v10]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <RTK5UMJBqQsB7k4QpgCptUAEC16Mu_K4D-zPYyAghNI=.cf02b6f1-dc02-44fe-a880-a4b2635eff90@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo 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 17 additional commits since the last revision:

 - Merge branch 'master' into 8285368
 - Update @since tags
 - Add a test
 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5a217d2b...5b6af244

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/563a8761..5b6af244

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

  Stats: 8391 lines in 228 files changed: 1225 ins; 6803 del; 363 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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


From psadhukhan at openjdk.org  Thu Jun 15 09:27:03 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Jun 2023 09:27:03 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <9ownzd5dqdKEiGg0IlnVVOAPVHPT6R4T7sRIc38GGnQ=.b36b77de-12e5-4323-a27a-d2055ce0f593@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
 <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>
 <5WiP9hIJOGk9XlFjE050ERL6rWBUZHYXg6VrPwbZKAk=.7af12729-7fe3-478b-bf5d-6a60ec262d62@github.com>
 <9ownzd5dqdKEiGg0IlnVVOAPVHPT6R4T7sRIc38GGnQ=.b36b77de-12e5-4323-a27a-d2055ce0f593@github.com>
Message-ID: <T0KHcX-ycz7oYXDG0kXy9aE-uokHsrXgsrHCtYFDByA=.f1ba251b-1c7f-4e2e-a092-71b009ddf1fa@github.com>

On Thu, 15 Jun 2023 07:43:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does it do what the `getIterator` method promise to do? It doesn't because it iterates over `LeafElement`-s only:

As per the spec wordings,
`The [getIterator(HTML.Tag t)](https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/javax/swing/text/html/HTMLDocument.html#getIterator(javax.swing.text.html.HTML.Tag)) method can also be used for finding all occurrences of the specified HTML tag in the document.`

which I think is what we get with the fix an Iterator object with next block tag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14466#discussion_r1230719224


From tr at openjdk.org  Thu Jun 15 09:39:58 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Jun 2023 09:39:58 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <QdeiUOA9SW_MCtS6PGOl9RZ3oXtq51En8q0cin8FxFw=.1a997f74-80da-4c24-8000-4d242adfde7f@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <9_fN5iolVPvcwlCEUhP5Duw4o-wXFynRgzj16B4_5VI=.da588a24-330a-4b66-9237-655cb1b98736@github.com>
 <D2cQM84TwraVLjXzWcCuYMDppg3N6BH4SGJynEbPfps=.0167d79b-6bcc-4194-bdfa-688ea844e6ea@github.com>
 <Pdxr4uSS1WPwPheRnv8BQvpIN9_tP12S2mvML1t9c6I=.1e1eb4fc-d0c5-4e96-afc3-1386991f6dd9@github.com>
 <DLgKr1IKuN4oBqk7yNs4QntHCn_uiiPNQ73ytxLb4i8=.02eca269-1d12-4a50-b2fb-80f38f7b4b1f@github.com>
 <6Ura-GwYnId8LYpXubZEhqgP--a1EOnWJjmMMPBh6xM=.6484bb7d-6a70-40ba-98c1-665832527dd0@github.com>
 <QdeiUOA9SW_MCtS6PGOl9RZ3oXtq51En8q0cin8FxFw=.1a997f74-80da-4c24-8000-4d242adfde7f@github.com>
Message-ID: <qIvOQ9Fg4uaW_IztnlFyWsLeFST3w-q-CINzLlFQDTg=.43b8bad3-f535-4abe-a2ca-8c576b811fc7@github.com>

On Thu, 15 Jun 2023 09:00:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> And also it's not possible to verify with background color because anti-aliasing, I guess.
>> 
>> Why is it? There's no background anti-aliasing, the background is filled with solid color.
>> 
>> You need to use [Robot.createMultiResolutionScreenCapture](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to get the real screen pixels rather than scaled down image as if uiScale=1.0.
>> 
>> You may need to tweak the position of the capture and the area where you sample the pixels.
>
> It is even simpler. The bug is not `JFileChooser`-specific, it affects each and every `JTable` which has a right-aligned column. Write the test for `JTable` instead. You can have a single right-aligned column with the header text that you control (a lower case letter ?l? will do it greatly). You can render the table into a `BufferedImage` with the scale you need (2.25) and then analyse the pixels in the image.
> 
> As simple as that. It's not necessary to create real UI for this kind of test.

Yeah, verifying with JTable will be better idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14464#discussion_r1230737158


From aivanov at openjdk.org  Thu Jun 15 11:17:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 11:17:07 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <T0KHcX-ycz7oYXDG0kXy9aE-uokHsrXgsrHCtYFDByA=.f1ba251b-1c7f-4e2e-a092-71b009ddf1fa@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
 <fPFy38jDw0lLMcQHhqPY81K8aorCV7ld_YvylnNKIh8=.58f3e8d0-850c-46ed-8c81-d5645f199520@github.com>
 <5WiP9hIJOGk9XlFjE050ERL6rWBUZHYXg6VrPwbZKAk=.7af12729-7fe3-478b-bf5d-6a60ec262d62@github.com>
 <9ownzd5dqdKEiGg0IlnVVOAPVHPT6R4T7sRIc38GGnQ=.b36b77de-12e5-4323-a27a-d2055ce0f593@github.com>
 <T0KHcX-ycz7oYXDG0kXy9aE-uokHsrXgsrHCtYFDByA=.f1ba251b-1c7f-4e2e-a092-71b009ddf1fa@github.com>
Message-ID: <5s1ReKp1XmABDnHaaspwtIImuVLuUTAKcaY5oTgTbYg=.c807c0fe-c152-4541-b6d2-09d5fd4edba6@github.com>

On Thu, 15 Jun 2023 09:23:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Obviously. :)
>> 
>> Does it do what the `getIterator` method promise to do? It doesn't because it iterates over `LeafElement`-s only:
>> 
>> https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L1993-L1998
>> 
>> So, the `next` method moves the iterator to the next leaf element:
>> 
>> https://github.com/openjdk/jdk/blob/931625a9304ec2761ca9035d69fd33f6beadb124/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L2037-L2044
>> 
>> Note that it uses `isLeaf` to stop the generic `ElementIterator`.
>> 
>> ---
>> 
>> It looks as if `HTMLDocument.getIterator` is public as an implementation detail: it's used to iterate over `HTML.Tag.A` to scroll the text component to the anchor and to determine whether the document is a frame set or not.
>> 
>> Removing the `if` condition removes the NPE but the method doesn't support Block Elements.
>> 
>> Should we update the javadoc to state the method shouldn't be used by apps? And to throw `UnsupportedOperationException` if a block tag is passed instead of returning null?
>
>> Does it do what the `getIterator` method promise to do? It doesn't because it iterates over `LeafElement`-s only:
> 
> As per the spec wordings,
> `The [getIterator(HTML.Tag t)](https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/javax/swing/text/html/HTMLDocument.html#getIterator(javax.swing.text.html.HTML.Tag)) method can also be used for finding all occurrences of the specified HTML tag in the document.`
> 
> which I think is what we get with the fix an Iterator object with next block tag

> > Does it do what the `getIterator` method promise to do? It doesn't because it iterates over `LeafElement`-s only:
> 
> As per the spec wordings, _The [getIterator(HTML.Tag t)](https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/javax/swing/text/html/HTMLDocument.html#getIterator(javax.swing.text.html.HTML.Tag)) method can also be used for finding all occurrences of the specified HTML tag in the document._
> 
> which I think is what we get with the fix an Iterator object with next block tag

Really? All the evidence I provided above shows the current implementation *skips* block tags because it takes into account only elements for which [`isLeaf`](https://github.com/openjdk/jdk/blob/83d92672d4c2637fc37ddd873533c85a9b083904/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2636) method returns `true`, that is `LeafElement`s. Block tags are represented with `BranchElement`, its [`isLeaf`](https://github.com/openjdk/jdk/blob/83d92672d4c2637fc37ddd873533c85a9b083904/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2481) method returns `false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14466#discussion_r1230852394


From aivanov at openjdk.org  Thu Jun 15 15:08:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 15:08:01 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <U3ga5oLvRxpQ4JEld_sLm1FVCbSbsFo7MF93uWUfhUg=.5774d0ac-4b20-4c56-b17e-58a1e481e398@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <6CIO56TQgxgXbhgY7ae6etk1PsfrI2RrnABvrm5WTi8=.3f4d13c5-89b8-45e9-8a53-fefc3a76a0b1@github.com>
 <U3ga5oLvRxpQ4JEld_sLm1FVCbSbsFo7MF93uWUfhUg=.5774d0ac-4b20-4c56-b17e-58a1e481e398@github.com>
Message-ID: <TczHYuxMpk0I2LQKhI786PHsmL-AR13IM03Zx0o0pqM=.b70a1056-b50f-4aa2-b420-25019b08c559@github.com>

On Wed, 3 May 2023 13:12:51 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

> > These don't seem to be part of the public API, so this is probably deliberate and not a bug.
> > https://docs.oracle.com/javase/accessbridge/2.0.2/api.htm#jab-api-specification
> 
> @prrace should non-public API methods be removed from .DEF then?

I think it's the best solution. These four functions are not part of the public API to AccessBridge, they're missing from [`AccessBridgeCalls.c`](https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c) and [`AccessBridgeCalls.h`](https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h).

They should not be exported. If the functions aren't loaded by its name, which is implemented in `AccessBridgeCalls.c`, or otherwise linked to from other modules (`.exe` or `.dll`), they don't need to be exported. These functions are part of the `WinAccessBridge` class, none of them cannot be called directly.

Did you try removing them from the `.def` file? Does anything break?

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1593248335


From abhiscxk at openjdk.org  Thu Jun 15 16:12:31 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Jun 2023 16:12:31 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
Message-ID: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@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.

This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  

CI link is posted in JBS.

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

Commit messages:
 - JComboBox selected item  screen magnifier fix

Changes: https://git.openjdk.org/jdk/pull/14497/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283214
  Stats: 124 lines in 3 files changed: 103 ins; 5 del; 16 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 azvegint at openjdk.org  Thu Jun 15 16:32:08 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 15 Jun 2023 16:32:08 GMT
Subject: RFR: 8309756: Occasional crashes with pipewire screen capture on
 Wayland
In-Reply-To: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
References: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
Message-ID: <P1sDZBJRSvwFXqlwCiTtptCNlTXI7Z6udcSMSG86bpU=.c0dedb68-16a9-4834-acb5-698e0ca1a3a9@github.com>

On Mon, 12 Jun 2023 21:24:16 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix seems to resolve some occasional crashes in our usage of pipewire for Wayland screen capture.
> See the bug report for more information.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14428#pullrequestreview-1481997084


From jwaters at openjdk.org  Thu Jun 15 17:54:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 17:54:02 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <TczHYuxMpk0I2LQKhI786PHsmL-AR13IM03Zx0o0pqM=.b70a1056-b50f-4aa2-b420-25019b08c559@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <6CIO56TQgxgXbhgY7ae6etk1PsfrI2RrnABvrm5WTi8=.3f4d13c5-89b8-45e9-8a53-fefc3a76a0b1@github.com>
 <U3ga5oLvRxpQ4JEld_sLm1FVCbSbsFo7MF93uWUfhUg=.5774d0ac-4b20-4c56-b17e-58a1e481e398@github.com>
 <TczHYuxMpk0I2LQKhI786PHsmL-AR13IM03Zx0o0pqM=.b70a1056-b50f-4aa2-b420-25019b08c559@github.com>
Message-ID: <PEmcilUGz8X4Nc6plwQbQEdrWHNQLXGmkxAVkj7S2Ao=.08a212b4-a5f8-41a1-b072-cbc7798fa4fc@github.com>

On Thu, 15 Jun 2023 15:04:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> These don't seem to be part of the public API, so this is probably deliberate and not a bug.
>>> https://docs.oracle.com/javase/accessbridge/2.0.2/api.htm#jab-api-specification
>> 
>> @prrace should non-public API methods be removed from .DEF then?
>
>> > These don't seem to be part of the public API, so this is probably deliberate and not a bug.
>> > https://docs.oracle.com/javase/accessbridge/2.0.2/api.htm#jab-api-specification
>> 
>> @prrace should non-public API methods be removed from .DEF then?
> 
> I think it's the best solution. These four functions are not part of the public API to AccessBridge, they're missing from [`AccessBridgeCalls.c`](https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c) and [`AccessBridgeCalls.h`](https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h).
> 
> They should not be exported. If the functions aren't loaded by its name, which is implemented in `AccessBridgeCalls.c`, or otherwise linked to from other modules (`.exe` or `.dll`), they don't need to be exported. These functions are part of the `WinAccessBridge` class, none of them cannot be called directly.
> 
> Did you try removing them from the `.def` file? Does anything break?

@aivanov-jdk Compiles and works fine without the exports in .def

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1593492047


From jwaters at openjdk.org  Thu Jun 15 17:54:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 17:54:19 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <CQtawPztoRit65n2rpRIZV_p6kyqqRFf9989uTvdtzc=.2e4eb65a-7c78-46d5-8773-43533a8cd930@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

I don't know about the more extensive test suite Phil alludes to, though

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1593492595


From prappo at openjdk.org  Thu Jun 15 17:58:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 17:58:25 GMT
Subject: Integrated: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <kmzmr-8-gt-5ci-p2iA9RDGNokxRQBmVXqBIfjvc_4M=.45624b22-f898-4fc2-b244-a97279663743@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

This pull request has now been integrated.

Changeset: 3e0bbd29
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e0bbd290c534b0f9729c54cd45308d505907797
Stats:     1768 lines in 32 files changed: 1634 ins; 32 del; 102 mod

8285368: Overhaul doc-comment inheritance
6376959: Algorithm for Inheriting Method Comments seems to go not as documented
6934301: Support directed inheriting of class comments with @inheritDoc

Reviewed-by: jjg, rriggs, aivanov, smarks, martin

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

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


From prr at openjdk.org  Thu Jun 15 19:36:09 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 19:36:09 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

Hmm, I did ask during the previous review if there was any reason to block with
_SetScrollPos or "the case below" - ie  _SetSpans... but perhaps it is more complex than that.

I need some clarification
Before any changes, using SyncCall , _SetSpans was called synchronously.
After the first change to use InvokeFunctionLater,  _SetSpans was called asynchronously .
Now with InvokeFunction,  _SetSpans is again called synchronously

So why do you also need the change to set it in native ?

The difference I can see is that although it is synchronous it now requires jumping on to the Toolkit thread
and so other pending processing on the Toolkit thread will run first.

But I'm not sure that's relevant here.

So can you expand on why you also had to move the call to setInsets() to native ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593613477


From jlu at openjdk.org  Thu Jun 15 19:45:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:45:52 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <wHemDob1LcBUGrp94CGVymYmeivv2G9ccgjfngb7m84=.a4d37dbb-54fd-4920-8734-dd2080aeaf32@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: 81bfd789
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto

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

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


From kcr at openjdk.org  Thu Jun 15 20:05:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 20:05:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <lk-HQVh3RGdNHbBiHftYiYZQzEq5Hp6CCtCXPjSbAPs=.ae8c0707-7daf-4142-8147-1ea24323364a@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

I was 

> @kevinrushforth Thanks for the reminder, will make the change in ML first.

Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435


From duke at openjdk.org  Thu Jun 15 20:05:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 15 Jun 2023 20:05:31 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <j-x2Vg89HAUcCaDz51mqofqhoX932hkfEGlaF-FvKIo=.8473b365-250a-47c3-b052-9d78947374de@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

(Review comment moved to mainline PR)

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

PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139


From kcr at openjdk.org  Thu Jun 15 21:09:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 21:09:09 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465


From jlu at openjdk.org  Thu Jun 15 21:13:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 21:13:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com>

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784


From honkar at openjdk.org  Thu Jun 15 21:16:59 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 Jun 2023 21:16:59 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <fLMdR1weEE_enSfal4RThWHKeXRZBb6it9YZDHelX-U=.f3144576-e924-4170-b0ae-6763f92e002b@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

@aivanov-jdk If just the `_SetSpans()` on native is changed to run as  `InvokeFunction` instead of `InvokeFunctionLater` both the tests - ScrollPaneLeakTest.java & ScrollPaneExtraScrollBar.java pass without additional code changes to WScrollPanePeer.java.childResized and _setInsets.

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

PR Review: https://git.openjdk.org/jdk/pull/14478#pullrequestreview-1482395782


From prr at openjdk.org  Thu Jun 15 22:35:03 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 22:35:03 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
Message-ID: <EAwhySt8vzdCBWTm3k8354SM-I6k0agvTSm03sGTnEM=.a0b96c3b-d6a1-406b-8e64-fd3f410f3c94@github.com>

On Wed, 14 Jun 2023 12:43:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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.

I'm inclined to agree this looks like unfinished work.
The original author seems to have thought block tags needed to be handled differently.
I don't see any evidence this was never intended to be used by apps any more than much of the rest of the API.

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

PR Comment: https://git.openjdk.org/jdk/pull/14466#issuecomment-1593805372


From prr at openjdk.org  Thu Jun 15 22:49:00 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 22:49:00 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
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: <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>

On Wed, 14 Jun 2023 09:17:06 GMT, Tejesh R <tr at openjdk.org> 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)

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.

SwingUtilities2.stringWidth()  ought to be using the correct FontMetrics here for the scale.
Or perhaps its not being used at all.
So go find the code that does the measurement and then positions the text and understand why it is wrong.
Perhaps its rounding the x location incorrectly for the right aligned text ?

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14464#pullrequestreview-1482487004


From prr at openjdk.org  Thu Jun 15 22:51:26 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 22:51:26 GMT
Subject: Integrated: 8309756: Occasional crashes with pipewire screen capture
 on Wayland
In-Reply-To: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
References: <ah-g7w0DU-txyLXWP8wxs1EhXALKv_UoFJ4iD-OqW30=.7e63fc23-309a-415a-bcf9-d861dc74737a@github.com>
Message-ID: <fNp0jhrY_38HgOf1Z1YO06T-9A-P4J6TI6ac3Cg_qis=.89f0cfd1-0578-47ac-b6d6-4c1e0c7a73d6@github.com>

On Mon, 12 Jun 2023 21:24:16 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix seems to resolve some occasional crashes in our usage of pipewire for Wayland screen capture.
> See the bug report for more information.

This pull request has now been integrated.

Changeset: d3d0dbc3
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3d0dbc36369da0c17a66f8b633e73a150ab8c4f
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8309756: Occasional crashes with pipewire screen capture on Wayland

Reviewed-by: avu, azvegint

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

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


From aivanov at openjdk.org  Thu Jun 15 22:53:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 22:53:58 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <fLMdR1weEE_enSfal4RThWHKeXRZBb6it9YZDHelX-U=.f3144576-e924-4170-b0ae-6763f92e002b@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <fLMdR1weEE_enSfal4RThWHKeXRZBb6it9YZDHelX-U=.f3144576-e924-4170-b0ae-6763f92e002b@github.com>
Message-ID: <nZhlINrym-xrVbL7jifUH01fu6kE29UNwucPjOaW3Wo=.60f55a31-c3b5-4e0f-9bdd-b338e321e1a0@github.com>

On Thu, 15 Jun 2023 21:14:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> @aivanov-jdk If just the `_SetSpans()` on native is changed to run as `InvokeFunction` instead of `InvokeFunctionLater` both the tests - ScrollPaneLeakTest.java & ScrollPaneExtraScrollBar.java pass without additional code changes to WScrollPanePeer.java.childResized and _setInsets.

I know it. But I think it's bad. If both `_SetSpans` and `_SetInsets` are synchronous by using `InvokeFunction`, you block EDT to run some code on the toolkit thread twice:

1. EDT calls `_SetSpans`, it gets blocked until `SetSpans` completes on the toolkit thread;
2. EDT calls `_SetInsets`, it gets blocked until `SetInsets` completes on the toolkit thread.

I think blocking is bad. I coalesced these two calls into one asynchronous call. There's no EDT blocking with the same result.

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593817579


From prr at openjdk.org  Thu Jun 15 23:00:00 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:00:00 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>

On Wed, 7 Jun 2023 12:54:54 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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

I still quibble with the premise of this bug.
No exceptions or any nasty stuff will happen if you don't use the EDT to call getSize().
It is more a case of you may get stale results.

And nothing in the AWT docs say you need to do this.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 171:

> 169:      */
> 170:     public void clickMouse() {
> 171:         clickMouse(InputEvent.BUTTON1_DOWN_MASK);

Note that this is a different int value than the old MASK constant so it is important that you ran all tests (which you say you did) in case some test is not consistently using the Robot API and will end up mixing old and new which will likely cause failures.

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

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1482490422
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1231606693


From prr at openjdk.org  Thu Jun 15 23:00:03 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:00:03 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <jrBykZtTpiTIN8R8J-prFZgb6bpYOaJOcKJllf6J6Pc=.d1a8f7b2-5db8-4481-82da-085d8959d2e6@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <n3zdhDO2-cMn6Y7lGDcCY6M2SAtN2z3PD89u9cIYAbU=.1b40426f-8b7a-475e-abe1-cca19e47adfc@github.com>
 <jrBykZtTpiTIN8R8J-prFZgb6bpYOaJOcKJllf6J6Pc=.d1a8f7b2-5db8-4481-82da-085d8959d2e6@github.com>
Message-ID: <uxk31Gx9My1_gXEM9MnR2-i7YJxc5Afl-avJ2c7m-ao=.0e7c2437-bf82-40ce-b5f6-3e85160b78e7@github.com>

On Thu, 8 Jun 2023 03:21:18 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

>> test/jdk/javax/swing/regtesthelpers/JRobot.java line 260:
>> 
>>> 258:      */
>>> 259:     public void convertRectToScreen(Rectangle r, Component c) {
>>> 260:         AtomicReference<Point> p = new AtomicReference<>();
>> 
>> So this change must be documented on all affected entry points, so that people understand
>> what it does.
>> Also touching Robot means you need to run ALL tests that use this utility and make sure you didn't break any. 
>> Have you done that ?
>
> Thanks @prrace for the reviews, 
> I have added EDT support for 'getCenterPoint' and 'convertRectToScreen' functions, executed all the tests which are using this function and confirmed its working.

But you seem to have ignored my comment about documenting it on 'all entry points' meaning EVERY exported API from this class which can end up here should say something like
"This method will invoke code on the Event Dispatch Thread".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1231607943


From honkar at openjdk.org  Thu Jun 15 23:16:00 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 Jun 2023 23:16:00 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
 <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
Message-ID: <T0I4bDpcV4xSZb-wkwKioNo8zesMIf2K87mA9Q1MyUo=.e6e6c952-b7d7-4860-b028-0fda3c1ca0d2@github.com>

On Thu, 15 Jun 2023 23:13:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Hmm, I did ask during the previous review if there was any reason to block with
>> _SetScrollPos or "the case below" - ie  _SetSpans... but perhaps it is more complex than that.
>> 
>> I need some clarification
>> Before any changes, using SyncCall , _SetSpans was called synchronously.
>> After the first change to use InvokeFunctionLater,  _SetSpans was called asynchronously .
>> Now with InvokeFunction,  _SetSpans is again called synchronously
>> 
>> So why do you also need the change to set it in native ?
>> 
>> The difference I can see is that although it is synchronous it now requires jumping on to the Toolkit thread
>> and so other pending processing on the Toolkit thread will run first.
>> 
>> But I'm not sure that's relevant here.
>> 
>> So can you expand on why you also had to move the call to setInsets() to native ?
>
>> Hmm, I did ask during the previous review if there was any reason to block with _SetScrollPos or "the case below" - ie _SetSpans... but perhaps it is more complex than that.
> 
> I didn't find any reason to block either.
> 
> I considered `_SetInsets` for using `InvokeFunction` or `InvokeFunctionLater`. I deliberately decided not to.
> 
> But I eventually missed the case where `SetInsets` *depends* on the results of `SetSpans` when they're called together in `WScrollPanePeer.childResized`.
> 
> (In my initial approach, I used `InvokeFunction` because I overlooked `InvokeFunctionLater` at first; they're not close in the header file and in the implementation files. Yet I was bothered by blocking EDT where it wasn't needed. I found `InvokeFunctionLater` and used it ? the result was the same.)
> 
>> I need some clarification Before any changes, using SyncCall , _SetSpans was called synchronously. After the first change to use InvokeFunctionLater, _SetSpans was called asynchronously .
> 
> Yes, when using `SyncCall` both `_SetSpans` and `_SetInsets` were called synchronously, so `_SetInsets` could use the updated spans.
> 
>> Now with InvokeFunction, _SetSpans is again called synchronously
> 
> No, it's still called *asynchronously*. 
> 
>> So why do you also need the change to set it in native ?
> 
> It is the reason why I moved `setInsets` from Java into native implementation.
> 
> Without moving SetInsets into the native, both `_SetSpans` and `_SetInsets` need to blocking calls that follow each other. In my opinion, it's not a good approach. I elaborated on it in [my reply to Harshitha's comment](https://github.com/openjdk/jdk/pull/14478#issuecomment-1593817579).
> 
>  
>> The difference I can see is that although it is synchronous it now requires jumping on to the Toolkit thread and so other pending processing on the Toolkit thread will run first.
>> 
>> But I'm not sure that's relevant here.
>> 
>> So can you expand on why you also had to move the call to setInsets() to native ?
> 
> To avoid making both `_SetSpans` and `_SetInsets` synchronous calls;
> To avoid another JNI call when both actions could be easily coalesced.
> 
> `SetInsets` must always be called after `SetSpans`. Why do we need to call both from Java side, where native implementation for `SetSpans` can as easily call it directly?

> > @aivanov-jdk If just the `_SetSpans()` on native is changed to run as `InvokeFunction` instead of `InvokeFunctionLater` both the tests - ScrollPaneLeakTest.java & ScrollPaneExtraScrollBar.java pass without additional code changes to WScrollPanePeer.java.childResized and _setInsets.
> 
> I know it. But I think it's bad. If both `_SetSpans` and `_SetInsets` are synchronous by using `InvokeFunction`, you block EDT to run some code on the toolkit thread twice:
> 
> 1. EDT calls `_SetSpans`, it gets blocked until `SetSpans` completes on the toolkit thread;
> 2. EDT calls `_SetInsets`, it gets blocked until `SetInsets` completes on the toolkit thread.
> 
> I think blocking is bad. I coalesced these two calls into one asynchronous call. There's no EDT blocking with the same result.

Thank you for the details. I'll play around with the 2 tests, trace out the calls and check if we are hitting any other corner cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593833418


From aivanov at openjdk.org  Thu Jun 15 23:15:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 23:15:59 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
Message-ID: <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>

On Thu, 15 Jun 2023 19:33:08 GMT, Phil Race <prr at openjdk.org> wrote:

> Hmm, I did ask during the previous review if there was any reason to block with _SetScrollPos or "the case below" - ie _SetSpans... but perhaps it is more complex than that.

I didn't find any reason to block either.

I considered `_SetInsets` for using `InvokeFunction` or `InvokeFunctionLater`. I deliberately decided not to.

But I eventually missed the case where `SetInsets` *depends* on the results of `SetSpans` when they're called together in `WScrollPanePeer.childResized`.

(In my initial approach, I used `InvokeFunction` because I overlooked `InvokeFunctionLater` at first; they're not close in the header file and in the implementation files. Yet I was bothered by blocking EDT where it wasn't needed. I found `InvokeFunctionLater` and used it ? the result was the same.)

> I need some clarification Before any changes, using SyncCall , _SetSpans was called synchronously. After the first change to use InvokeFunctionLater, _SetSpans was called asynchronously .

Yes, when using `SyncCall` both `_SetSpans` and `_SetInsets` were called synchronously, so `_SetInsets` could use the updated spans.

> Now with InvokeFunction, _SetSpans is again called synchronously

No, it's still called *asynchronously*. 

> So why do you also need the change to set it in native ?

It is the reason why I moved `setInsets` from Java into native implementation.

Without moving SetInsets into the native, both `_SetSpans` and `_SetInsets` need to blocking calls that follow each other. In my opinion, it's not a good approach. I elaborated on it in [my reply to Harshitha's comment](https://github.com/openjdk/jdk/pull/14478#issuecomment-1593817579).

 
> The difference I can see is that although it is synchronous it now requires jumping on to the Toolkit thread and so other pending processing on the Toolkit thread will run first.
> 
> But I'm not sure that's relevant here.
> 
> So can you expand on why you also had to move the call to setInsets() to native ?

To avoid making both `_SetSpans` and `_SetInsets` synchronous calls;
To avoid another JNI call when both actions could be easily coalesced.

`SetInsets` must always be called after `SetSpans`. Why do we need to call both from Java side, where native implementation for `SetSpans` can as easily call it directly?

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593833346


From aivanov at openjdk.org  Thu Jun 15 23:24:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Jun 2023 23:24:08 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <GZnTV_xx8VIod5-0fvr4pEaQq5l1Efjy9y_Gc6Jme7w=.273afc31-eed7-4567-b458-5c35c28acce1@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

Following the same way of thought, I'd like to coalesce `setInsets`, `getInsets` followed by `setScrollPosition` in `WScrollPanePeer.initialize` into one native call as well. I believe this would be more efficient. I've already submitted [JDK-8310056](https://bugs.openjdk.org/browse/JDK-8310056) for it.

That change is related to this but I'd rather keep them separate: it's safer to make small changes. Moreover they're independent.

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593838351


From prr at openjdk.org  Thu Jun 15 23:26:01 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:26:01 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:

> 1087:                 entry_point();
> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, colorBits, &bmi, DIB_RGB_COLORS);

I just can't tell if the updates you are making as a result of the jni_md.h change are really the right ones and some of them don't look that way

You wrote
"As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints,"

Per the windows docs for GetDIBits()  it takes an LPVOID for the parameter these are used for.
For the cases above if takes an LPVOID which is really just a void*, and using jint in the malloc is just weird since jint doesn't mean anything to GDI

And  clearly this change requires running a whole load of client tests on windows [*]
but I have no idea what your reply to my question about that means. What is "-permissive" ?

[*] and I have no idea what VM etc tests need to be run just for the JNI change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1231621441


From prr at openjdk.org  Thu Jun 15 23:31:59 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:31:59 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
 <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
Message-ID: <8rBA7gNXEDwMJccPhSa2QFIDGkwusU_H4QtKJSwTE9c=.840fb4b7-05e0-42a6-baab-d3da865cd476@github.com>

On Thu, 15 Jun 2023 23:13:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Now with InvokeFunction, _SetSpans is again called synchronously
No, it's still called *asynchronously*. 


=== 

  INLINE void * InvokeFunction(void*(*ftn)(void)) {
        return (void *)SendMessage(WM_AWT_INVOKE_VOID_METHOD, (WPARAM)ftn, 0);

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendmessage

Sends the specified message to a window or windows.
The SendMessage function calls the window procedure for the specified window and does not return until the window procedure has processed the message.

===

So how is that not synchronous ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593843155


From honkar at openjdk.org  Thu Jun 15 23:41:58 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 Jun 2023 23:41:58 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <8rBA7gNXEDwMJccPhSa2QFIDGkwusU_H4QtKJSwTE9c=.840fb4b7-05e0-42a6-baab-d3da865cd476@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
 <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
 <8rBA7gNXEDwMJccPhSa2QFIDGkwusU_H4QtKJSwTE9c=.840fb4b7-05e0-42a6-baab-d3da865cd476@github.com>
Message-ID: <dhoCcAA4jJ0Juhp6RkM2wpc6HWPqSFgX23ny31HYen8=.0b0d3a11-3eaa-4b2f-b394-51994d883a65@github.com>

On Thu, 15 Jun 2023 23:29:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Oh wait, that is _SetInsets you updated here. I thought I had these calls straight but I need to look again.

@prrace That is correct. It is_SetInsets which has been changed to be called as `InvokeFunction` and _SetSpans is still being called as `InvokeFunctionLater` as per @aivanov-jdk previous fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1593849091


From prr at openjdk.org  Thu Jun 15 23:45:59 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:45:59 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <BzRbU0sWoghC9H3D4vYpeQ4-loBn7ZuA5ElQUHAduPY=.f5e3c9c1-5ddf-4c92-9c1c-0dd3e4fb1578@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

I think I got it now.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14478#pullrequestreview-1482522770


From azvegint at openjdk.org  Fri Jun 16 00:29:09 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Jun 2023 00:29:09 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v5]
In-Reply-To: <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
Message-ID: <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>

On Wed, 14 Jun 2023 07:32:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java line 205:

> 203:     public GraphicsConfiguration getAppropriateGraphicsConfiguration(
> 204:             GraphicsConfiguration gc)
> 205:     {

Could you please move the brace to the line 204 to match the overall style of the file?

src/java.desktop/share/classes/java/awt/Window.java line 3223:

> 3221:                     getDefaultScreenDevice().
> 3222:                     getDefaultConfiguration();
> 3223:         }

It looks like `gc` was always not null before the fix, which is no longer true after the fix.
We need to double check that we didn't break anything in this regard.

src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 240:

> 238:             XToolkit.awtUnlock();
> 239:         }
> 240:     }

The same code is already in XCanvasPeer.

XWindowPeer is a descendant of XCanvasPeer, there is no need to repeat the code here.

src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 671:

> 669:         return gc;
> 670:     }
> 671: 

Same here, WWindowPeer is a WCanvasPeer descendant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231559438
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231650769
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231640268
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231640811


From jwaters at openjdk.org  Fri Jun 16 00:43:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 16 Jun 2023 00:43:19 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>
Message-ID: <Y9FMGwzJBhQth0ZkNl0Vi-OsK_TXSZLFNxfq55d69wc=.5e1fe26b-f9c5-40d5-9519-68696df130db@github.com>

On Thu, 15 Jun 2023 23:22:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:
> 
>> 1087:                 entry_point();
>> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
>> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, colorBits, &bmi, DIB_RGB_COLORS);
> 
> I just can't tell if the updates you are making as a result of the jni_md.h change are really the right ones and some of them don't look that way
> 
> You wrote
> "As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints,"
> 
> Per the windows docs for GetDIBits()  it takes an LPVOID for the parameter these are used for.
> For the cases above if takes an LPVOID which is really just a void*, and using jint in the malloc is just weird since jint doesn't mean anything to GDI
> 
> And  clearly this change requires running a whole load of client tests on windows [*]
> but I have no idea what your reply to my question about that means. What is "-permissive" ?
> 
> [*] and I have no idea what VM etc tests need to be run just for the JNI change

-permissive- is a compiler switch that forces the Microsoft Visual C compiler to be stricter in compiling C and C++ and makes it enforce the standard much more aggressively. It's becoming less permissive with every iteration of the Microsoft compiler and is stated to become enabled by default eventually by Microsoft. One of the consequences of this is that in the future our code cannot so loosely treat int and long as the same type on Windows (even though they are ultimately the same size in compiled code), as far as the compiler is concerned, they are semantically 2 entirely different types. That's the complication this Pull Request is trying to preempt by changing the jni.h typedef for Windows

I missed the LPVOID change in GetDIBits, but for the other changes I really only followed the existing declarations, the jint for colorBits is because the call to SetIntArrayRegion takes a jint as a parameter. Let me know if I should change the declaration regardless, though

Also, we have David for the VM reviews ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1231658403


From psadhukhan at openjdk.org  Fri Jun 16 03:10:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 16 Jun 2023 03:10:19 GMT
Subject: RFR: 8049347: HTMLDocument throws NPE for Block Tag
In-Reply-To: <EAwhySt8vzdCBWTm3k8354SM-I6k0agvTSm03sGTnEM=.a0b96c3b-d6a1-406b-8e64-fd3f410f3c94@github.com>
References: <dQSRW2mOzzQjCX-kBkcD_MG8gC6jjALIHK54em7rZE4=.52c337ec-8d93-48ec-a0e9-151daeb8f0e2@github.com>
 <EAwhySt8vzdCBWTm3k8354SM-I6k0agvTSm03sGTnEM=.a0b96c3b-d6a1-406b-8e64-fd3f410f3c94@github.com>
Message-ID: <LYc1Ho7UxSLwq1ZiqPiJhkSR6cuMolmipPojux0BJag=.51c6a953-163a-4827-ae61-3857e3852bd2@github.com>

On Thu, 15 Jun 2023 22:32:32 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm inclined to agree this looks like unfinished work. The original author seems to have thought block tags needed to be handled differently. I don't see any evidence this was never intended to be used by apps any more than much of the rest of the API.

Yes, I also think it so now that it probably will need a "BlockIterator" implementation as mentioned and calling `UnsupportedOperationException` may not be appropriate and it also does not seem right to update spec to mention the same which will cast in stone and might cause issue later on if we need to support it in future..

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

PR Comment: https://git.openjdk.org/jdk/pull/14466#issuecomment-1594025062


From martin at openjdk.org  Fri Jun 16 04:39:17 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 16 Jun 2023 04:39:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
 <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
Message-ID: <sxYo3C8Lkg2RLbg-NyOwCGOfqtA4Mud4i4ImQ8GNf1I=.a22a4573-4e06-4472-8e5b-3161bcb49d32@github.com>

On Wed, 14 Jun 2023 10:07:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:
>> 
>>> 1532: 
>>> 1533:     /**
>>> 1534:      * {@inheritDoc ConcurrentMap}
>> 
>> This clarifies the authors' intent, so is clear progress. 
>> 
>> Semantic difficulties remain:
>> - it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
>> - we never want to inherit AbstractFoo @implNotes
>> - ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
>
>> * we never want to inherit AbstractFoo @implNotes
> 
> `@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:
> 
>     @implSpec {@inheritDoc}
> 
>> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
> 
> That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

(There's nothing wrong with this PR)

Back in the 1980s there was a lot of optimism that OOP would be a big leap forward in software engineering.
But especially the "inheritance" part of OOP has been disappointing - unexpectedly brittle!
javadoc inheritance in collection classes was particularly interesting to me from this perspective.
Especially with the multiple inheritance that java was mostly reluctant to adopt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1231765877


From jlu at openjdk.org  Fri Jun 16 04:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 04:39:42 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value
 - Review: use Naoto's recommended ja values
 - Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk21/pull/11/files
  - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373

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

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11


From tr at openjdk.org  Fri Jun 16 08:15:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 Jun 2023 08:15:17 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v6]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <rEFtDqaxcVWoCLQIlguGSiVAOi6cg4VBlKZwy-e9dnk=.d1b2710b-3323-4950-a1c5-7182dad220c0@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/ff0b5ee8..7b2b2b01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=04-05

  Stats: 42 lines in 3 files changed: 0 ins; 41 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14246/head:pull/14246

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


From tr at openjdk.org  Fri Jun 16 08:15:22 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 Jun 2023 08:15:22 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v5]
In-Reply-To: <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
Message-ID: <22PF51BCP6UApD-NKeN1KSGsV9F0mKtb4q5UWljEdzY=.0cd61d0d-6c56-46e0-83ef-c828c5a7754f@github.com>

On Thu, 15 Jun 2023 21:37:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java line 205:
> 
>> 203:     public GraphicsConfiguration getAppropriateGraphicsConfiguration(
>> 204:             GraphicsConfiguration gc)
>> 205:     {
> 
> Could you please move the brace to the line 204 to match the overall style of the file?

Updated.

> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 240:
> 
>> 238:             XToolkit.awtUnlock();
>> 239:         }
>> 240:     }
> 
> The same code is already in XCanvasPeer.
> 
> XWindowPeer is a descendant of XCanvasPeer, there is no need to repeat the code here.

Updated.

> src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 671:
> 
>> 669:         return gc;
>> 670:     }
>> 671: 
> 
> Same here, WWindowPeer is a WCanvasPeer descendant.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231928415
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231928510
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231928769


From tr at openjdk.org  Fri Jun 16 08:15:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 Jun 2023 08:15:25 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v6]
In-Reply-To: <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
Message-ID: <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>

On Fri, 16 Jun 2023 00:20:08 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/java/awt/Window.java line 3223:
> 
>> 3221:                     getDefaultScreenDevice().
>> 3222:                     getDefaultConfiguration();
>> 3223:         }
> 
> It looks like `gc` was always not null before the fix, which is no longer true after the fix.
> We need to double check that we didn't break anything in this regard.

Yeah, have tested in CI multiple time and also few manual dual screen related test. No regression found with fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1231930086


From aboldtch at openjdk.org  Fri Jun 16 09:22:33 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 09:22:33 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>

The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.

The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.

If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.

If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.

If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.

And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.

This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.

This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 

The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`

To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.

`vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
- `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
- `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  

`test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change is isolated in 5c0c0bdab9012a5f35dd4ab3a2847374578c8b9f . It seems more appropriate to actually test the MXBeans by default with no explicit gc, but I am open reverting this part.

The plan is to also backport this to 21 to improve the testing until release. The changes here should fall under `P1?P5 doc/test changes`

Running tests in Oracle CI. (tier1-tier5)
Verified that both `ZGenerational` and `ZSinglegen` tests get run in GHA.
Running tests in builds with `--disable-jvm-feature-zgc` to verify no regression.

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

Commit messages:
 - MemoryTest.java run when not explicit
 - Add vm.gc.{ZGenerational,ZSinglegen} to jtreg

Changes: https://git.openjdk.org/jdk/pull/14509/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 618 lines in 70 files changed: 447 ins; 5 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

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


From asemenov at openjdk.org  Fri Jun 16 10:26:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 16 Jun 2023 10:26:05 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>

On Thu, 15 Jun 2023 15:58:18 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
> 
> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
> 
> CI link is posted in JBS.

@azuev-java @NikitkoCent please review.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 162:

> 160:             AccessibleContext ac = this.getAccessibleContext();
> 161:             if (ac != null && (comboBox.getSelectedItem() != null)) {
> 162:                 ac.setAccessibleName(comboBox.getSelectedItem().toString());

Why are you using the currently selected element for the button name and not a specific name? Whether it will sound right when using a screen reader. Wouldn't this be misleading to a blind user? Especially since it will only change when this method is called.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 162:

> 160:             AccessibleContext ac = this.getAccessibleContext();
> 161:             if (ac != null && (comboBox.getSelectedItem() != null)) {
> 162:                 ac.setAccessibleName(comboBox.getSelectedItem().toString());

Are you sure that the toString() method always provides a valid string, and not a descriptive JSON or some other character set that is useless for a blind user?

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

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1483145861
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1232051887
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1232053721


From aboldtch at openjdk.org  Fri Jun 16 11:41:14 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 11:41:14 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix wrong ZGenerational flag in VectorRebracket128Test.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/5c0c0bda..e571b87f

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

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

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


From stefank at openjdk.org  Fri Jun 16 11:47:58 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 11:47:58 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <DD112bPIhXJScIUoRZ66n3fOFY0qVi17pZqs535oN3c=.ebe61b64-0869-4bfc-80dc-1e532a1be770@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483282594


From eosterlund at openjdk.org  Fri Jun 16 12:07:00 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jun 2023 12:07:00 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <G9Rk1_psrvYyebtTVJBVhAjrIyvfGwn1AiXCJZkZLxM=.5c2ef27a-7498-4f31-96e4-588c3d33b307@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483348038


From azvegint at openjdk.org  Fri Jun 16 14:37:06 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Jun 2023 14:37:06 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v6]
In-Reply-To: <rEFtDqaxcVWoCLQIlguGSiVAOi6cg4VBlKZwy-e9dnk=.d1b2710b-3323-4950-a1c5-7182dad220c0@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <rEFtDqaxcVWoCLQIlguGSiVAOi6cg4VBlKZwy-e9dnk=.d1b2710b-3323-4950-a1c5-7182dad220c0@github.com>
Message-ID: <_omqNhRpA_udzZkYeDV0K_W1r7UnNCuuDG0oHBi2Et4=.97c49f6d-462f-4708-92a6-17d5ba3c8c35@github.com>

On Fri, 16 Jun 2023 08:15:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 64:

> 62: import sun.awt.SunToolkit;
> 63: import sun.awt.X11GraphicsDevice;
> 64: import sun.awt.X11GraphicsConfig;

Looks like we don't need this anymore.

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

PR Review: https://git.openjdk.org/jdk/pull/14246#pullrequestreview-1483608674
PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1232310725


From jjg at openjdk.org  Fri Jun 16 15:09:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Jun 2023 15:09:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>

On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435


From honkar at openjdk.org  Fri Jun 16 16:28:02 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 Jun 2023 16:28:02 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <iCaGFLSoUYlG-mbgml7RX-y3epT5UvberrFe2otrjvM=.29eaf6df-17f0-4a87-a6d8-c53a783573fc@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

PR changes look good. All ScrollPane related tests work as expected with the changes.

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

Marked as reviewed by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14478#pullrequestreview-1483898507


From aivanov at openjdk.org  Fri Jun 16 16:28:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Jun 2023 16:28:04 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <8rBA7gNXEDwMJccPhSa2QFIDGkwusU_H4QtKJSwTE9c=.840fb4b7-05e0-42a6-baab-d3da865cd476@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
 <1sDKFDHQ7Bruczbpky2j6hhnTC11DtXcw2HL3MxN8yQ=.bec28470-ed46-414a-975e-4d1edeea6cbc@github.com>
 <S99UoyOqbsJ4kmWFvvGzvlWTg4VUln6KjOlrlMnjTIY=.b0233319-0ea3-46d7-954d-b0eba9985f44@github.com>
 <8rBA7gNXEDwMJccPhSa2QFIDGkwusU_H4QtKJSwTE9c=.840fb4b7-05e0-42a6-baab-d3da865cd476@github.com>
Message-ID: <i8f5BhANBet0qCQFsYAkmp6wGX-UQOt9l31HeS31d2k=.e7740443-f512-46cc-8892-db3d04eb92d6@github.com>

On Thu, 15 Jun 2023 23:29:37 GMT, Phil Race <prr at openjdk.org> wrote:

> So I think I see with the benefit of your recent comments.
> It seemed that reverting _SetSpans to synchronous would fix this and somehow I read that was what you were doing.
> But you didn't want to do that and you were forced into making _SetInsets synchronous because of the initalization usage
> and hence moving the update of insets needed by setSpans avoided that.

Yes, that's right.

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

PR Comment: https://git.openjdk.org/jdk/pull/14478#issuecomment-1594945363


From naoto at openjdk.org  Fri Jun 16 17:16:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:16:33 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
Message-ID: <mnwQXQ-yvvAdB4JlfTC3NwMpbuEENwDTX0GeETglGh0=.9054a675-049f-4dfb-a847-4e93fea5020f@github.com>

On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
>
>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
> 
> 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
> 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.
> 3. The iteration order would be undefined when resources are removed from one or more resource files

Makes sense. Thanks for the explanation @jonathan-gibbons

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086


From tr at openjdk.org  Fri Jun 16 17:19:39 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 Jun 2023 17:19:39 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v7]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <ZK-Zrub3CWwWKNwj3uSNKafzMnoCz1_b7Jow0Cn8JpA=.dbe8d7d6-be43-4290-89d9-a44ffa90303a@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

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/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/7b2b2b01..428d0dd8

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

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

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


From aivanov at openjdk.org  Fri Jun 16 17:28:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Jun 2023 17:28:54 GMT
Subject: Integrated: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <27OxC3Vh1VXk3vJqZXLV0uby88Pu5ME4gmbiqFJC9bc=.adc89a4c-836c-4794-839c-601a5c9c7253@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

This pull request has now been integrated.

Changeset: d6c2ee34
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6c2ee3448a14b3e5a392aacc11ed8e47d388f80
Stats:     13 lines in 3 files changed: 7 ins; 1 del; 5 mod

8310054: ScrollPane insets are incorrect

Reviewed-by: honkar, prr

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

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


From prr at openjdk.org  Fri Jun 16 19:31:11 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Jun 2023 19:31:11 GMT
Subject: RFR: 8310238: [test bug]
 javax/swing/JTableHeader/6889007/bug6889007.java fails
Message-ID: <60Na-NI_BW5Bb5dmHQalB6rS61twGQRLFw1kSExCDe4=.b0d0b5d2-30fd-4d7f-b6cf-2bb92c77d241@github.com>

This test fails *every* time when run as part of full set of jtreg tests and that is because it is sensitive to the initial mouse location,
and the previous test always sets it to within the location of this test's window.
The only reason it isn't problem listed is because on re-run - without that preceding test - it will pass.

More info in the bug report.

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

Commit messages:
 - 8310238

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

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


From aturbanov at openjdk.org  Fri Jun 16 20:17:11 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 16 Jun 2023 20:17:11 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v2]
In-Reply-To: <3qy9XFIxDHmPrkcCB2pFlo17z9lw0pbdut-3ASRx4cQ=.3e9aaa12-1be0-4b5a-af4e-3c2e6c70097d@github.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
 <3qy9XFIxDHmPrkcCB2pFlo17z9lw0pbdut-3ASRx4cQ=.3e9aaa12-1be0-4b5a-af4e-3c2e6c70097d@github.com>
Message-ID: <_gx1w8rBITvDk83REfubVNeyWmUefQGWIjzZRufjwVI=.53b59b3f-7b7d-4342-91a4-27471509b1b7@github.com>

On Wed, 7 Jun 2023 19:19:59 GMT, Jeremy <duke at openjdk.org> 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:
>> 
>> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
>> 
>> 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 two additional commits since the last revision:
> 
>  - 8303950: Adding "@key headful"
>    
>    Based on prrace's feedback https://github.com/openjdk/jdk/pull/14363#issuecomment-1581365662
>  - 8303950: remove call to Window#toBack()
>    
>    toBack() moves the Window behind *everything*. If it moved windows only behind other windows in the Swing app that would be great, but that's not what it does.

test/jdk/javax/swing/RepaintManager/8303950/bug8303950_legacyWindowPaintBehavior.java line 68:

> 66:                 Window w2 = createWindow( WINDOW_BACKGROUND, ROOTPANE_BACKGROUND, x + 400, y, 400, 400, false, "window 2");
> 67:                 Window w3 = createWindow( WINDOW_BACKGROUND, null, x, y + 400, 400, 400, true, "window 3");
> 68:                 Window w4 =  createWindow( WINDOW_BACKGROUND, ROOTPANE_BACKGROUND, x + 400, y + 400, 400, 400, true, "window 4");

Suggestion:

                Window w4 = createWindow( WINDOW_BACKGROUND, ROOTPANE_BACKGROUND, x + 400, y + 400, 400, 400, true, "window 4");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14363#discussion_r1232733209


From philip.race at oracle.com  Fri Jun 16 20:18:25 2023
From: philip.race at oracle.com (Philip Race)
Date: Fri, 16 Jun 2023 13:18:25 -0700
Subject: Why does Java resize a Window to 1x1 pixel when HDMI is unplugged
 (and does not resize back when HDMI is plugged)
In-Reply-To: <8b0343cc-a62c-1cbd-8632-dc7750907916@tavla.de>
References: <dd61a286-cf06-61ff-18ed-abc1c1d6602c@tavla.de>
 <d8806ba5-1d85-93c2-a9e5-fbfff468eb44@oracle.com>
 <27d44240-1592-cfe4-ae11-5af104098b85@oracle.com>
 <8b0343cc-a62c-1cbd-8632-dc7750907916@tavla.de>
Message-ID: <0e5a62ff-1581-d83c-528d-4b2f90a8cdad@oracle.com>

I'd like to re-iterate that Wayland is not a supported platform for ANY 
version of JDK.
It is known "not to work" - I suggest you use X.org, not Wayland.
And when we do get to support Wayland it will be on a VERY recent Linux 
platform.
As a minimum it will probably require Gnome 45? - which isn't even 
available for another few months and only
in distros some time after that.
We even go to the trouble in the Oracle JDK supported platform matrix of 
explicitly calling out Wayland mode as not supported.

I don't really know if Wayland is the actual problem here, I just know 
it is unsupported

If X.org cures the problems, then you have your answer
If you can reproduce your problems on X.org then that is a much more 
certain base for debugging your actual issue
which seems likely to a display configuration issue for which I can 
believe there are issues depending on h/w, video driver, JDK version etc.

But definitely JDK 11u is VERY OLD and you'll keep getting hints to 
upgrade to the latest (JDK20).

So that's my gentle hint as to what direction you should take - but be 
informed that these lists are not a support forum.
They are lists exclusively for people contributing fixes to the JDK 
itself, so you can't expect everyone to jump on finding a solution for you,
especially on an old and relatively obscure configuration.

-phil

On 6/9/23 10:18 AM, Martin Petzold wrote:
> Am 09.06.23 um 15:47 schrieb Aleksei Ivanov:
>> If it is a full-screen JFrame, you can exit full-screen mode and 
>> enter it again. It may help.
>>
> Thanks, I can restore the size with your suggestion: I'm now using a 
> scheduled executor service to check size and if it is not full screen 
> remove full screen and set full screen window again. However, the 
> Window does not show - it is not rendered. I tried setVisible(true) 
> again, but no effect.
>
> Martin
>



From dcubed at openjdk.org  Fri Jun 16 20:34:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 20:34:08 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might
want to fix the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1595274922


From duke at openjdk.org  Fri Jun 16 20:37:10 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 16 Jun 2023 20:37:10 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>

On Thu, 15 Jun 2023 15:58:18 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
> 
> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
> 
> CI link is posted in JBS.

Changes requested by NikitkoCent at github.com (no known OpenJDK username).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1121:

> 1119:     @Override
> 1120:     public int getAccessibleChildrenCount(JComponent c) {
> 1121:         return 2;

I think the logic here has to be equal to the logic in `getAccessibleChild `, otherwise `getAccessibleChildrenCount` returns 2 even when `getAccessibleChild(..., 1)` returns null.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1128:

> 1126:     public Accessible getAccessibleChild(JComponent c, int i) {
> 1127:         // 0 = the popup
> 1128:         // 1 = the editor

The comment here needs to be updated

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1146:

> 1144:                         && (arrowButton instanceof Accessible)) {
> 1145:                     return (Accessible) arrowButton;
> 1146:                 }

How about to idiomatize the code a bit by using Java 14's enhanced `instanceof`?

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

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1484328290
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1232746895
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1232741613
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1232750667


From prr at openjdk.org  Fri Jun 16 20:41:24 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Jun 2023 20:41:24 GMT
Subject: RFR: 8309756: Occasional crashes with pipewire screen capture on
 Wayland
Message-ID: <Bocwn4hB6FXDLl0XozPWi31_DfIOhvnwY--JTaoEmGc=.5de25838-f35f-41a6-b481-262f42049ce7@github.com>

I'd like to backport the fix for this crash to the JDK 21 stabilisation repo.
The fix is in code that is only used by AWT Robot on Wayland desktops so is quite isolated and unlikely to affect anything else.

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

Commit messages:
 - Backport d3d0dbc36369da0c17a66f8b633e73a150ab8c4f

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

PR: https://git.openjdk.org/jdk21/pull/25


From jiangli at openjdk.org  Fri Jun 16 20:43:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 20:43:27 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
Message-ID: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>

8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

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

Commit messages:
 - Backport 45414fc2dfa41cbbfc6de7fec15eb47f41cf8986

Changes: https://git.openjdk.org/jdk21/pull/26/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=26&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307858
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk21/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/26/head:pull/26

PR: https://git.openjdk.org/jdk21/pull/26


From azvegint at openjdk.org  Fri Jun 16 20:53:13 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Jun 2023 20:53:13 GMT
Subject: RFR: 8309756: Occasional crashes with pipewire screen capture on
 Wayland
In-Reply-To: <Bocwn4hB6FXDLl0XozPWi31_DfIOhvnwY--JTaoEmGc=.5de25838-f35f-41a6-b481-262f42049ce7@github.com>
References: <Bocwn4hB6FXDLl0XozPWi31_DfIOhvnwY--JTaoEmGc=.5de25838-f35f-41a6-b481-262f42049ce7@github.com>
Message-ID: <q307yyHDqxGd7Ldmm4V2jqmqBeTrsg4JLQpVkbjpjnU=.08d6ba7e-5b3e-4968-99ce-1bbbe3b80364@github.com>

On Fri, 16 Jun 2023 20:33:32 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd like to backport the fix for this crash to the JDK 21 stabilisation repo.
> The fix is in code that is only used by AWT Robot on Wayland desktops so is quite isolated and unlikely to affect anything else.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/25#pullrequestreview-1484369707


From kcr at openjdk.org  Fri Jun 16 20:55:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Jun 2023 20:55:16 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21 during [Rampdown Phase 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You could request late approval to get this enhancement in, via the process described in [JEP 3](https://openjdk.org/jeps/3).

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595304249


From naoto at openjdk.org  Fri Jun 16 21:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 21:02:17 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
Message-ID: <Jfrbn9kav_htg9Xsi2K0qX_DMxUTs4QAEzMKI77gj-4=.089cfa89-dcf3-4441-817b-f6a575cb4d9c@github.com>

On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value
>  - Review: use Naoto's recommended ja values
>  - Revert 'main.help.opt.any.file' value for _de

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340


From jiangli at openjdk.org  Fri Jun 16 21:08:06 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 21:08:06 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>
Message-ID: <v7kUZ2bMVlJxgc74Ylo_HMRN1FwoLXSZX3CnM-JnLYU=.f5457210-61e9-4c85-9453-c0c402d79e30@github.com>

On Fri, 16 Jun 2023 20:52:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21 during [Rampdown Phase 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You could request late approval to get this enhancement in, via the process described in [JEP 3](https://openjdk.org/jeps/3).

Thanks for the pointer, @kevinrushforth. Will follow the process.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595318981


From jlu at openjdk.org  Fri Jun 16 21:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 21:14:20 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <yxBFAdo-tYodL8exo3y2xbRz6pYcTIvYVJ8Tnbzp1WM=.80ad659c-02ea-476d-8e2a-ed80b3187880@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: a1c1d97a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto
Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a

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

PR: https://git.openjdk.org/jdk21/pull/11


From dcubed at openjdk.org  Fri Jun 16 22:13:14 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 22:13:14 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

GHA is failing on windows; is this related to this PR or something else?

@erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you
have plans to redo that testing for the JDK21 backport?

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595371284
PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595373061


From jiangli at openjdk.org  Fri Jun 16 22:35:12 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 22:35:12 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
Message-ID: <jFn301dnjkPcyS64jHoEVVdUTL8qjCRHo4SJ31XdASo=.6f5cf120-64b4-474b-a802-d1274487d7c3@github.com>

On Fri, 16 Jun 2023 22:08:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> GHA is failing on windows; is this related to this PR or something else?

The windows build failures occur with other PRs as well, e.g. https://github.com/openjdk/jdk21/pull/24/checks?check_run_id=14317258603. They should be unrelated.


make: *** [jtdiff.gmk:36: D:/a/jdk21/jdk21/jtreg/src/build/classes.com.sun.javatest.diff.ok] Error 126
Error: Process completed with exit code 2.


I noticed these presubmit failures with `jdk` started since last week or so.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595395385


From prr at openjdk.org  Fri Jun 16 22:48:14 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Jun 2023 22:48:14 GMT
Subject: Integrated: 8309756: Occasional crashes with pipewire screen capture
 on Wayland
In-Reply-To: <Bocwn4hB6FXDLl0XozPWi31_DfIOhvnwY--JTaoEmGc=.5de25838-f35f-41a6-b481-262f42049ce7@github.com>
References: <Bocwn4hB6FXDLl0XozPWi31_DfIOhvnwY--JTaoEmGc=.5de25838-f35f-41a6-b481-262f42049ce7@github.com>
Message-ID: <O1s4dwYhY-My2fcGLQQhwLA--esDFSYeNsyJb_OPfNk=.5ba77edb-aa95-43fb-8ad3-17242eb3bd0c@github.com>

On Fri, 16 Jun 2023 20:33:32 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd like to backport the fix for this crash to the JDK 21 stabilisation repo.
> The fix is in code that is only used by AWT Robot on Wayland desktops so is quite isolated and unlikely to affect anything else.

This pull request has now been integrated.

Changeset: 3698a022
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/3698a022ff53dbe9832c832f8aca1c042e3ac54c
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8309756: Occasional crashes with pipewire screen capture on Wayland

Reviewed-by: azvegint
Backport-of: d3d0dbc36369da0c17a66f8b633e73a150ab8c4f

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

PR: https://git.openjdk.org/jdk21/pull/25


From duke at openjdk.org  Fri Jun 16 23:16:53 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 16 Jun 2023 23:16:53 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v3]
In-Reply-To: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
References: <1rA84rf1wIPIOVRjBWMZpPcRf9FE2rMSZ0hu0xla1i0=.0ac7cdf8-42d8-4bcd-b521-f386d46fa107@github.com>
Message-ID: <VGdQ8l5YEoWfCQaM4PZzoLSPTDI7ILWz4olOIc5XbbY=.02e8d915-f481-4366-b865-904d11889d5e@github.com>

> # 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:
> 
> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
> 
> 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. (In this case: that's the opaque green top two windows.) T...

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14363/files
  - new: https://git.openjdk.org/jdk/pull/14363/files/2c093210..12d8950d

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

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

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


From alanb at openjdk.org  Sat Jun 17 13:27:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 13:27:07 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233062199


From tr at openjdk.org  Mon Jun 19 06:12:16 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Jun 2023 06:12:16 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen
In-Reply-To: <psAMQ5IJxw_0rp9NYXmrKbffrEPiCFNzUXN_OPslbRQ=.050f3966-4e9b-485c-8531-eba05c0b82af@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <oJrXeei1CZNmWgu5P1shuWXPBhBLNFfHD3LiHLi-WXA=.1c033f15-679e-40bd-85e0-7a88a0dc434c@github.com>
 <rE5R1VJj3B4FpPOAWYUQjg6v_jhCYNULB962KUoLcUA=.e35bf819-7f6a-4fa2-9c5e-d080330b913e@github.com>
 <pCPbpmHZ2YephQlTbCKQO7YKOksCbiw7sfMjU7WB5YM=.bba6d0f2-d12c-49be-9fd0-63f428c6d4d0@github.com>
 <91YmklXwW4bz7tewafm_c6juRiaaETUySAnrtiVMiIk=.3188b04a-90e0-4ca3-b0a1-657d74188e23@github.com>
 <XOODD7ytxjUlQgRQtzvtoUp76swp07Oqm4NgtN6rQp4=.fff1d79c-c3c0-43af-97d0-af8510e6e2e5@github.com>
 <n0JoCpPTHEOyCsRerU2PwyfuX6Yi91CLTLJTQB6a3c0=.599f207a-90ce-4d3d-8385-d0823f150100@github.com>
 <psAMQ5IJxw_0rp9NYXmrKbffrEPiCFNzUXN_OPslbRQ=.050f3966-4e9b-485c-8531-eba05c0b82af@github.com>
Message-ID: <qUOBXhu2i890mgEXDbxFWF-0V5VnDCTxfUp5RsEuCyI=.495c1513-7806-4e40-bad0-06479c8db7e9@github.com>

On Thu, 8 Jun 2023 21:35:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > > > > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
>>> > > > 
>>> > > > 
>>> > > > We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.
>>> > > 
>>> > > 
>>> > > If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?
>>> > 
>>> > 
>>> > In Window, GC is set when during initialization, i.e., `initGC()` is called, also there is separate `setGraphicsConfiguration() ` method. But unlike `Canvas.setGraphicsConfiguration()`, in window `getAppropriateGraphicsConfiguration()` is not used. So with Window, unlike Canvas setting a GC is quite different and doesn't involve `getAppropriateGraphicsConfiguration()` I hope.
>>> 
>>> So this bug is not reproduced for Canvas? Then probably we should use the code similar to Canvas.setGraphicsConfiguration in the WIndow class?
>> 
>> Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.
>
>> Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.
> 
> The patch which added the getAppropriateGraphicsConfiguration was supposed to fix the same bug but looks like it was implemented for the Canvas only, I think we can do the same thing for the Window class as well. Note that getAppropriateGraphicsConfiguration on all other platforms is noop so it should not affected.

@mrserb I have updated the PR with Canvas Patch with @azvegint as reviewer. Please let me know if you have anything else about this PR? (CI testing is green).

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

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1596565644


From aboldtch at openjdk.org  Mon Jun 19 06:55:52 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 06:55:52 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add explicit id to all Skynet.java @test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/e571b87f..b262d48b

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

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

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


From aboldtch at openjdk.org  Mon Jun 19 07:03:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:03:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
Message-ID: <GBrJ84po6uCENIHrklbo2U9V89wEkmsL08bJIqPa4Ho=.120247b1-d582-4dbc-b6e7-264a3fb4b463@github.com>

On Sat, 17 Jun 2023 13:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong ZGenerational flag in VectorRebracket128Test.java
>
> test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

Done. 

I tried to reduce changes to other ids as much as possible as they may be used for problemlisting etc. The first run would have been `#id0` before and after this patch. However does not seem to be any exclusion filters in the repo for Skynet so added a default id. 

Because this patch adds extra `@test` some `#idX` will change. I've tried to double check that there are no problemlistings that depend on this, and I can find none. 

Ideally all multi `@test` tests should use explicit ids so changing that updating existing tests is less fragile with respect to exclusions. However I know that there are more gotchas here with how problemlisting works. Not sure I remember the exact details but I believe that under certain circumstances the id will be ignored, and if a problemlisting includes it, it will not filter it out. 

For now updating tests will always require going through all relevant problemlisting files and check that the exclusions are still valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233609799


From aboldtch at openjdk.org  Mon Jun 19 07:09:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:09:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
Message-ID: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>

On Fri, 16 Jun 2023 20:31:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.

What part are you worried about? When would `vm.gc.ZSingelgen` be invalid? 

Also what part of the PR requires fixing?

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596626922


From tr at openjdk.org  Mon Jun 19 07:21:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Jun 2023 07:21:10 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing [v2]
In-Reply-To: <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
 <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>
Message-ID: <M8W6gaBSqaUU78_TIoNcNr-4KMb6kJYx_cchRbMX_kQ=.a4e9c2ef-655f-48a1-afd3-48e2f67f95e8@github.com>

On Wed, 14 Jun 2023 09:45:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
>> This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
>> I could not find any JBS which did that code change.
>> 
>> Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14444#pullrequestreview-1485561608


From alanb at openjdk.org  Mon Jun 19 07:23:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Jun 2023 07:23:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
 <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
Message-ID: <06Ia9w1yf91JRYaIMQAdbwKymzljIA_6mdAO22L9OYo=.f70ab943-832e-4018-ab2b-973f90f6d2b9@github.com>

On Mon, 19 Jun 2023 07:06:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.
> 
> What part are you worried about? When would `vm.gc.ZSingelgen` be invalid?
> 
> Also what part of the PR requires fixing?

I assume Dan is pointing out the typo in the PR description ("e" and "l" have been transposed).

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596645899


From abhiscxk at openjdk.org  Mon Jun 19 08:44:08 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 08:44:08 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
Message-ID: <rnBh_hyNhnLD28NHwRt6IL7_HLIyNK8h7V2U4lEGvz4=.3daaf06a-db43-4ab4-b9ab-381a12b0cb45@github.com>

On Fri, 16 Jun 2023 10:04:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Why are you using the currently selected element for the button name and not a specific name?

As it is required to show the magnified text for the selected item in JComboBox. Setting it to some specific name always results into that name irrespective of selected item in JCombobox.

> Whether it will sound right when using a screen reader. Wouldn't this be misleading to a blind user?

I checked with VO announcement with or without this chunk of code, it is same in both case. 

> Especially since it will only change when this method is called.

This method is called whenever the current selection is changed so accessible name is set to correct item.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233723009


From abhiscxk at openjdk.org  Mon Jun 19 08:52:07 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 08:52:07 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
Message-ID: <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>

On Fri, 16 Jun 2023 10:06:42 GMT, Artem Semenov <asemenov at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 162:
> 
>> 160:             AccessibleContext ac = this.getAccessibleContext();
>> 161:             if (ac != null && (comboBox.getSelectedItem() != null)) {
>> 162:                 ac.setAccessibleName(comboBox.getSelectedItem().toString());
> 
> Are you sure that the toString() method always provides a valid string, and not a descriptive JSON or some other character set that is useless for a blind user?

I tested several times, didn't get such kind of result and as per java docs toString method returns `a string representation of the object.` So, I think it will be a valid string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233732120


From abhiscxk at openjdk.org  Mon Jun 19 08:52:09 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 08:52:09 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
Message-ID: <qQ0Sbv0l5VYSDiEpn9leiw3oOgAjbOUZPoaIMj-qjCg=.0c31bdd7-f27b-4a88-88f6-508d7be18f7e@github.com>

On Fri, 16 Jun 2023 20:22:48 GMT, Nikita Provotorov <duke at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1128:
> 
>> 1126:     public Accessible getAccessibleChild(JComponent c, int i) {
>> 1127:         // 0 = the popup
>> 1128:         // 1 = the editor
> 
> The comment here needs to be updated

Sure, I will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233732323


From psadhukhan at openjdk.org  Mon Jun 19 08:55:34 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 19 Jun 2023 08:55:34 GMT
Subject: Integrated: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode()
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <cLjXv-P4pzrh2hEyltvMN_umsGR4ukpaI2Lgli0TN4g=.7dba5846-ff1b-4242-a6e8-5f3efa0bc261@github.com>

On Mon, 10 Apr 2023 12:44:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses.
> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails.
> Fixed by implementing the equality and hashCode method for CSS.FontSize class.
> 
> All jtreg/jck tests are ok

This pull request has now been integrated.

Changeset: d2a858e1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2a858e173ae10c577d7a3d14eb87ab5c3f60062
Stats:     264 lines in 2 files changed: 264 ins; 0 del; 0 mod

7083187: Class CSS.CssValue is missing implementations of equals() and hashCode()

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: aivanov, prr

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

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


From abhiscxk at openjdk.org  Mon Jun 19 09:01:10 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 09:01:10 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox
In-Reply-To: <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
Message-ID: <o1wJgosBd6MqqsI2D_q7bVadH04FRIsUCV7WZWPV1GA=.53dbe234-5af1-44ba-bbac-7d9d67df4352@github.com>

On Fri, 16 Jun 2023 20:29:53 GMT, Nikita Provotorov <duke at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1121:
> 
>> 1119:     @Override
>> 1120:     public int getAccessibleChildrenCount(JComponent c) {
>> 1121:         return 2;
> 
> I think the logic here has to be equal to the logic in `getAccessibleChild `, otherwise `getAccessibleChildrenCount` returns 2 even when `getAccessibleChild(..., 1)` returns null.

Can you please elaborate more or what logic can be added here?

> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1146:
> 
>> 1144:                         && (arrowButton instanceof Accessible)) {
>> 1145:                     return (Accessible) arrowButton;
>> 1146:                 }
> 
> How about to idiomatize the code a bit by using Java 14's enhanced `instanceof`?

Yeah it can be done to use enhanced `instanceOf`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233740734
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233743694


From stuefe at openjdk.org  Mon Jun 19 09:07:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 09:07:11 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I'm not the most qualified for ZGC, but I looked this over with a mind on the planned 21 backport. I wanted to check if any of the existing legacy ZGC tests had been changed, either accidentally or deliberately. This seems not be the case.

The remarks are small nits, feel free to ignore them.

How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

Cheers, Thomas

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 298:

> 296:         if (selectedGCMode != null) {
> 297:             args.add(selectedGCMode);
> 298:         }

just to be sure, maybe add a "must not be Z" assert in the else path?

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 58:

> 56:     public final static String ERR_MSG = "The saved state of UseCompressedOops and UseCompressedClassPointers is different from runtime, CDS will be disabled.";
> 57:     public static void main(String... args) throws Exception {
> 58:          String zGenerational = args[0];

assert not null?

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1485730970
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233738199
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233740188


From abhiscxk at openjdk.org  Mon Jun 19 09:27:01 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 09:27:01 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@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.
> 
> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
> 
> CI link is posted in JBS.

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

  Review comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14497/files
  - new: https://git.openjdk.org/jdk/pull/14497/files/11e39ea0..db0a35b7

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

  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 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  Mon Jun 19 09:27:05 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Jun 2023 09:27:05 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <qQ0Sbv0l5VYSDiEpn9leiw3oOgAjbOUZPoaIMj-qjCg=.0c31bdd7-f27b-4a88-88f6-508d7be18f7e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
 <qQ0Sbv0l5VYSDiEpn9leiw3oOgAjbOUZPoaIMj-qjCg=.0c31bdd7-f27b-4a88-88f6-508d7be18f7e@github.com>
Message-ID: <s8tkjZh0Fxum0Cjk5OU0tn5xaZrEg8SxuQ9hYNHrheY=.837a1e17-0b37-44d9-99a5-2ce7c94a5886@github.com>

On Mon, 19 Jun 2023 08:49:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1128:
>> 
>>> 1126:     public Accessible getAccessibleChild(JComponent c, int i) {
>>> 1127:         // 0 = the popup
>>> 1128:         // 1 = the editor
>> 
>> The comment here needs to be updated
>
> Sure, I will update.

Updated.

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1146:
>> 
>>> 1144:                         && (arrowButton instanceof Accessible)) {
>>> 1145:                     return (Accessible) arrowButton;
>>> 1146:                 }
>> 
>> How about to idiomatize the code a bit by using Java 14's enhanced `instanceof`?
>
> Yeah it can be done to use enhanced `instanceOf`.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233771736
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233771503


From mkartashev at openjdk.org  Mon Jun 19 12:06:17 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 19 Jun 2023 12:06:17 GMT
Subject: RFR: 8308875:
 java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed
 with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device"
 is null'
In-Reply-To: <4KHBZohzquVZ8NQINYdbwjZMzsG1dEI_zHhPyK5gplM=.725be181-1642-4302-9da8-c41ea863491c@github.com>
References: <aDzVyJIIKoungDJcYA7JG0DPa4zsr_Qkcr2A1wYiP_0=.b30b30bf-9756-428c-8598-1f42d360aa11@github.com>
 <4KHBZohzquVZ8NQINYdbwjZMzsG1dEI_zHhPyK5gplM=.725be181-1642-4302-9da8-c41ea863491c@github.com>
Message-ID: <QJ71432Vo5TwkC6ylxivcIdoM_Hp7xjOYvcw40mG_co=.c7e70cd5-737c-4dd3-a225-048dda01683f@github.com>

On Mon, 5 Jun 2023 17:51:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573).
>> 
>> This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file.
>
> I note that the previous fix "undid" similar code on windows and mac as well.
> Any explanation why it only causes a problem for Linux ?

@prrace 
> I note that the previous fix "undid" similar code on windows and mac as well.
> Any explanation why it only causes a problem for Linux ?

Now that I've looked at the code, I don't understand the statement "the previous fix "undid" similar code on windows and mac as well". If by "the previous fix" you mean the fix for 8305578, then it did *not* introduce the same problem on MacOS/Windows as it did for Linux. Compare the relevant parts of `getScreenInsets()` before this one has been integrated:

Linux:
        final X11GraphicsDevice device = (X11GraphicsDevice) gc.getDevice();
        Insets insets = device.getInsets();

MacOS:
        if (!(gd instanceof CGraphicsDevice)) {
            return super.getScreenInsets(gc);
        }

Windows:
        if (!(gd instanceof Win32GraphicsDevice)) {
            return super.getScreenInsets(gc);
        }


Only Linux will fail in case of a "custom" `GraphicsConfiguration`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14170#issuecomment-1597060568


From duke at openjdk.org  Mon Jun 19 12:39:09 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Mon, 19 Jun 2023 12:39:09 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <o1wJgosBd6MqqsI2D_q7bVadH04FRIsUCV7WZWPV1GA=.53dbe234-5af1-44ba-bbac-7d9d67df4352@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
 <o1wJgosBd6MqqsI2D_q7bVadH04FRIsUCV7WZWPV1GA=.53dbe234-5af1-44ba-bbac-7d9d67df4352@github.com>
Message-ID: <CxO8LYLfchSjsd94DipVXzLW_Np8CtTE9_QCwreTWc0=.695f3aad-651b-4b8d-ae0f-a05af403219d@github.com>

On Mon, 19 Jun 2023 08:56:04 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1121:
>> 
>>> 1119:     @Override
>>> 1120:     public int getAccessibleChildrenCount(JComponent c) {
>>> 1121:         return 2;
>> 
>> I think the logic here has to be equal to the logic in `getAccessibleChild `, otherwise `getAccessibleChildrenCount` returns 2 even when `getAccessibleChild(..., 1)` returns null.
>
> Can you please elaborate more or what logic can be added here?

I mean `getAccessibleChild(..., 1)` can still return null (when both `if`s of `case 1` resolve to false). Let's consider the following code:

public void doSmthWith(JComponent component, BasicComboBoxUI ui) {
    if (ui.getAccessibleChildrenCount(component) > 1) {
        // well, we have at least 2 components, so we can expect to get a valid object below
        final var ac = ui.getAccessibleChild(component, 1)
                                  .getAccessibleContext(); // <= possible NPE
        // ...
    }
}


I think we have to return 1 from `getAccessibleChildrenCount(...)` for the cases when `getAccessibleChild(..., 1)` returns `null`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1233996986


From mik3hall at gmail.com  Mon Jun 19 13:24:34 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 19 Jun 2023 08:24:34 -0500
Subject: JVM hang with Swing and macOS
In-Reply-To: <W8KVLir28mK4IZPvtqC9EFScsvIeg1xuoxLWyBYT613xyjf9XvJvudzB6Tt0E0Glqyi9CdEcS22M4B3k3_TgRZFTwYGuW6IPLsmKet0M0_4=@protonmail.com>
References: <FYSMEs2Hs62JS_uHzH29FHYQXRfds-Yo-KNgIOwkarsN4wP1gl2lMkleZj8MnMT2lW3nxWqM-_768qpa57RD6ibcVjTRXkSruNbkizozkMY=@protonmail.com>
 <da55189b-556a-9fa7-5d91-064a90c26c5b@amazon.com>
 <W8KVLir28mK4IZPvtqC9EFScsvIeg1xuoxLWyBYT613xyjf9XvJvudzB6Tt0E0Glqyi9CdEcS22M4B3k3_TgRZFTwYGuW6IPLsmKet0M0_4=@protonmail.com>
Message-ID: <1A5D00DE-0237-4A18-9914-3F72C8E4682F@gmail.com>



> On Mar 15, 2023, at 3:37 AM, Martin Pernollet <martin.pernollet at protonmail.com> wrote:
> 
> Hi Sergey,
> 
> We access OpenGL through native bindings generated by JExtract, from project Panama. These bindings are packaged as a library visible here (https://gitlab.com/jzy3d/panama-gl).
> 
> The -XstartOnFirstThread option is needed by OpenGL on macOS as OpenGL invocation MUST be performed from macOS main thread. 
> 

This is possible with your Panama related in a somewhat limited way. I have an application that does it at SwingGL-1.0.dmg[1]. This an x86 built app. This application bundles the native executables for an offscreen Mesa[2] build and freeglut[3]. freeglut appears to have a dependency on XQuartz[4]. The application doesn?t provide this dependency. XQuartz would need to be pre-installed. This renders the Teapot image offscreen and then copies it to a Swing JPanel. It does not require the -XstartOnFirstThread switch.

It is limited in how it provides access to the native libraries. java.library.path isn?t sufficient. I think this is because there is still  Apple OpenGL related floating around that gets found first. Although I don?t think the Apple provided is adequate to provide what is actually needed to support OpenGL So you have to use the DYLD_LIBRARY_PATH environment variable. This is problematic for a java application since you can?t use relative paths. The solution this application uses is to start a different ?java? process.

	private static final String[] procArgs = new String[] {
			System.getProperty("java.home")+"/bin/java",
			"-cp",System.getProperty("java.class.path"),
			"--enable-preview",
			"--enable-native-access=ALL-UNNAMED",
			"-Djava.library.path="+System.getProperty("java.library.path"),
			"us.hall.gl.GLProcess"
	};

And give it the DYLD_LIBRARY_PATH environment variable.
environment.put("DYLD_LIBRARY_PATH",System.getProperty("java.library.path"));

Which can just be java.library.path which jpackage automatically sets to the application internal ?app? directory. Making sure that all the executables end up being put in that directory.

Another limitation is that besides the need for a absolute path DYLD_LIBRARY_PATH, you can?t use the system path native ?java? command. This is due to Apple security protections.[5][6]. 

So DYLD_LIBRARY_PATH or any other DYLD environment variable can?t be used with the installed native ?java? command in /Library/Java/JavaVirtualMachines. 

The application needs to provide its own java command using its own jlink parameters that don?t strip native commands. Something like?
--jlink-options '--strip-debug --no-man-pages --no-header-files?

An additional limitation here is that including the java command precludes that application from getting into the Mac App Store as a resolution to JDK-8286122[7]. 

I?ve thought this resolution was unfortunate and there might possibly be some other approach that would allow developer applications to include native apps in the App Store. Maybe the SIP issue provides a little more incentive to revisit this issue at some point?

For some reason you get an extra window when this runs. I think this comes out of freeglut/XQuartz initialization and will try to figure out how to get rid of it. I plan to look a little more at what is possible with this approach for macOS applications to use OpenGL ongoing. But I think this does show it isn?t necessarily completely impossible to have such support. Maybe just a little limited.

[1] http://mikehall.pairserver..com/SwingGL-1.0.dmg
[2] https://www.mesa3d.org/
[3] https://freeglut.sourceforge.net/
[4] https://www.xquartz.org/
[5] https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html
[6] https://developer.apple.com/forums/thread/703757
[7] https://bugs.openjdk.org/browse/JDK-8286122










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230619/9c514f24/attachment.htm>

From aivanov at openjdk.org  Mon Jun 19 14:25:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Jun 2023 14:25:15 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
Message-ID: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>

This pull request contains a backport of commit [d6c2ee34](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d6c2ee3448a14b3e5a392aacc11ed8e47d388f80__;!!ACWV5N9M2RV99hQ!OD7LAhsqxyc5YNrxjKmpLYJCCngVm706aY3NMRMXyihGIzSIbP4H6H2INaanHemHbj9dHTsmhmOUJZhPmeXAa5_r8Rsx$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

It fixes the regression introduced by [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).

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

Commit messages:
 - Backport d6c2ee3448a14b3e5a392aacc11ed8e47d388f80

Changes: https://git.openjdk.org/jdk21/pull/33/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=33&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310054
  Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk21/pull/33.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/33/head:pull/33

PR: https://git.openjdk.org/jdk21/pull/33


From azvegint at openjdk.org  Mon Jun 19 17:09:06 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 Jun 2023 17:09:06 GMT
Subject: RFR: 8310238: [test bug]
 javax/swing/JTableHeader/6889007/bug6889007.java fails
In-Reply-To: <60Na-NI_BW5Bb5dmHQalB6rS61twGQRLFw1kSExCDe4=.b0d0b5d2-30fd-4d7f-b6cf-2bb92c77d241@github.com>
References: <60Na-NI_BW5Bb5dmHQalB6rS61twGQRLFw1kSExCDe4=.b0d0b5d2-30fd-4d7f-b6cf-2bb92c77d241@github.com>
Message-ID: <DeLU7E6Av8IfvHgLfebHnA5JrIe8IXs3btUdIv3p-fw=.554a53ad-3975-4adf-ad12-55b06461803a@github.com>

On Fri, 16 Jun 2023 19:25:14 GMT, Phil Race <prr at openjdk.org> wrote:

> This test fails *every* time when run as part of full set of jtreg tests and that is because it is sensitive to the initial mouse location,
> and the previous test always sets it to within the location of this test's window.
> The only reason it isn't problem listed is because on re-run - without that preceding test - it will pass.
> 
> More info in the bug report.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14527#pullrequestreview-1486592434


From duke at openjdk.org  Tue Jun 20 06:32:05 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 20 Jun 2023 06:32:05 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <uxk31Gx9My1_gXEM9MnR2-i7YJxc5Afl-avJ2c7m-ao=.0e7c2437-bf82-40ce-b5f6-3e85160b78e7@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <n3zdhDO2-cMn6Y7lGDcCY6M2SAtN2z3PD89u9cIYAbU=.1b40426f-8b7a-475e-abe1-cca19e47adfc@github.com>
 <jrBykZtTpiTIN8R8J-prFZgb6bpYOaJOcKJllf6J6Pc=.d1a8f7b2-5db8-4481-82da-085d8959d2e6@github.com>
 <uxk31Gx9My1_gXEM9MnR2-i7YJxc5Afl-avJ2c7m-ao=.0e7c2437-bf82-40ce-b5f6-3e85160b78e7@github.com>
Message-ID: <qJiCwGfYj50aMw8UNZ_LSkRJRMxSXY0nrSRGPDrW4jQ=.0c389d55-21ca-40d0-8e87-255e02f9a6de@github.com>

On Thu, 15 Jun 2023 22:53:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Thanks @prrace for the reviews, 
>> I have added EDT support for 'getCenterPoint' and 'convertRectToScreen' functions, executed all the tests which are using this function and confirmed its working.
>
> But you seem to have ignored my comment about documenting it on 'all entry points' meaning EVERY exported API from this class which can end up here should say something like
> "This method will invoke code on the Event Dispatch Thread".

Sorry I didn't ignored your valuable comment regarding documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1234794697


From jwaters at openjdk.org  Tue Jun 20 07:14:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:14:11 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <yl1ID4d9tj697Ub8zJ2V6kp8mRNl0K8H8ui2mGMVffs=.9f975a37-df57-468c-bf7b-0076fe3488a7@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1598234398


From jwaters at openjdk.org  Tue Jun 20 07:14:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:14:11 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <eXWg-1t8z1WQcinhlvMTAmAuyXiNFHy0Tac_7J8CkEc=.1f90cba7-75c1-4d30-92be-d39d31ec42f7@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1598234667


From aboldtch at openjdk.org  Tue Jun 20 10:11:15 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
 <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
Message-ID: <VDW3BGJ096WIM-W4o8iASPVBxgFZUODEGU7-jMzvcxk=.e6ab6339-bf00-487c-afdd-2ef09b9d5b08@github.com>

On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

This adds around 40 more tests per platform. The runtime of GHA seems to have a lot of run to run variance. Most new tests are in the `hs/tier1 gc` which has a lower runtime than a few other jobs. So until the heavies jobs gets split into multiple jobs,   this should have a negligible affect the overall GHA runtime

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598488556


From aboldtch at openjdk.org  Tue Jun 20 10:11:18 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:18 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <_wzHFl48ZJqPvYFTwOtY4ughHH3EvHSH9-JtsJiAiXg=.c0e787e7-7797-4a50-a6d3-1b4ef9dfd39e@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

Thanks for all the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598489642


From aboldtch at openjdk.org  Tue Jun 20 10:11:19 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:19 GMT
Subject: Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XBb9N9mM3eUuzE3Hn7dEBfENSBizoTw539Co_-H_ngs=.898b8ddf-b6dd-42e0-9e6c-986800b61005@github.com>

On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

This pull request has now been integrated.

Changeset: a0595761
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: stefank, eosterlund, stuefe

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

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


From psadhukhan at openjdk.org  Tue Jun 20 10:26:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Jun 2023 10:26:12 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width
Message-ID: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>

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 for Classic and forces title buttons to be square and to fit the frame title in height.

Before fix
![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)

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

Commit messages:
 - Test fix
 - 8140527: JInternalFrame has incorrect title button width
 - 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/14555/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8140527
  Stats: 114 lines in 3 files changed: 113 ins; 0 del; 1 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 aboldtch at openjdk.org  Tue Jun 20 11:24:22 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 11:24:22 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>

Hi all,

This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.

Thanks!

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

Commit messages:
 - Backport a0595761ef35c4eec8cb84326a869b9473cd5bba

Changes: https://git.openjdk.org/jdk21/pull/37/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=37&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 619 lines in 70 files changed: 447 ins; 5 del; 167 mod
  Patch: https://git.openjdk.org/jdk21/pull/37.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/37/head:pull/37

PR: https://git.openjdk.org/jdk21/pull/37


From eosterlund at openjdk.org  Tue Jun 20 11:28:10 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Jun 2023 11:28:10 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <4_7pKKc53x4JitLz3mqqGPROusebWNzImc2QiYeNOLw=.bfba6681-1a22-4e5b-8669-d6261cc129e3@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/37#pullrequestreview-1487924209


From honkar at openjdk.org  Tue Jun 20 17:09:11 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 Jun 2023 17:09:11 GMT
Subject: [jdk21] RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
References: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
Message-ID: <IF5Aspb5ECtZeZjasm_sHxPlvR4GNgC1e1FHSz9jReI=.0b9623d9-5713-49fd-8aaf-f6ff22596fa7@github.com>

On Mon, 19 Jun 2023 14:18:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This pull request contains a backport of commit [d6c2ee34](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d6c2ee3448a14b3e5a392aacc11ed8e47d388f80__;!!ACWV5N9M2RV99hQ!OD7LAhsqxyc5YNrxjKmpLYJCCngVm706aY3NMRMXyihGIzSIbP4H6H2INaanHemHbj9dHTsmhmOUJZhPmeXAa5_r8Rsx$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It fixes the regression introduced by [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).

Clean backport. Changes look good.

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

Marked as reviewed by honkar (Committer).

PR Review: https://git.openjdk.org/jdk21/pull/33#pullrequestreview-1488616288


From prr at openjdk.org  Tue Jun 20 17:16:06 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 17:16:06 GMT
Subject: [jdk21] RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
References: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
Message-ID: <Fk8OdWWGS79rHBOrOxXtRw1hoi1ShML3_F1hARHutjs=.09d093f7-7100-46cd-89da-81fd2d94d2cb@github.com>

On Mon, 19 Jun 2023 14:18:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This pull request contains a backport of commit [d6c2ee34](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d6c2ee3448a14b3e5a392aacc11ed8e47d388f80__;!!ACWV5N9M2RV99hQ!OD7LAhsqxyc5YNrxjKmpLYJCCngVm706aY3NMRMXyihGIzSIbP4H6H2INaanHemHbj9dHTsmhmOUJZhPmeXAa5_r8Rsx$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It fixes the regression introduced by [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/33#pullrequestreview-1488628299


From nikita.provotorov at jetbrains.com  Tue Jun 20 17:27:44 2023
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Tue, 20 Jun 2023 20:27:44 +0300
Subject: When don't MOUSE_DRAGGED events have pressed mouse buttons?
Message-ID: <CAMTdVeq3zm92DaW_pAx43E8Ou4iscPGnOu46MUQ-6aKpDaddXA@mail.gmail.com>

Hello! I?m looking into the dispatching routine in AWT/Swing and stumbled
upon the following piece of code in
*java.awt.LightweightDispatcher#processMouseEvent*
<https://github.com/openjdk/jdk/blob/4a9cc8a000cafb3ad77a33710054b567e8553652/src/java.desktop/share/classes/java/awt/Container.java#L4591>
:

case MouseEvent.MOUSE_DRAGGED:
>     if (isMouseGrab(e)) {
>         retargetMouseEvent(met, id, e);
>     }
>     break;


In case of *MOUSE_DRAGGED* events, *isMouseGrab* basically checks if the
event has any pressed mouse buttons (in modifiers). I wonder why it has
been handled explicitly? AFAIU *MOUSE_DRAGGED* events always have some
pressed mouse buttons, otherwise that?s not possible to drag, don?t they?

Best regards,
Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230620/7bdc2deb/attachment.htm>

From erikj at openjdk.org  Tue Jun 20 17:28:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jun 2023 17:28:09 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

The changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/26#pullrequestreview-1488653545


From erikj at openjdk.org  Tue Jun 20 17:28:10 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jun 2023 17:28:10 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
Message-ID: <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>

On Fri, 16 Jun 2023 22:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you have plans to redo that testing for the JDK21 backport?

I have done testing of the JDK 21 version of the patch and it's running cleanly.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599212967


From jiangli at openjdk.org  Tue Jun 20 17:57:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 17:57:04 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
 <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>
Message-ID: <lYF3jKOwLHcmw5IC91M5v7mt9wAgBMhjlvGqAtq43x4=.78cab790-3f86-4f90-ad2e-a6219be671b0@github.com>

On Tue, 20 Jun 2023 17:24:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you have plans to redo that testing for the JDK21 backport?
> 
> I have done testing of the JDK 21 version of the patch and it's running cleanly.

Thanks for testing, @erikj79!

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599255419


From jiangli at openjdk.org  Tue Jun 20 17:57:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 17:57:04 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>
Message-ID: <MQkHYsLqOQ0Cyt-y0G9qx-ymh85g6bazFCTi11y_rfs=.5e0e07f9-a781-4976-8957-aac265c83dc4@github.com>

On Tue, 20 Jun 2023 17:25:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The changes look ok.

Thanks. I'll wait for approval on https://bugs.openjdk.org/browse/JDK-8307858 as well.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599256118


From aivanov at openjdk.org  Tue Jun 20 19:23:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Jun 2023 19:23:06 GMT
Subject: [jdk21] Integrated: 8310054: ScrollPane insets are incorrect
In-Reply-To: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
References: <85jEnnWGiDODuFg6YrRMvaMHcOoDLDtm4mz197vLfuQ=.002533d5-ee39-41fb-ae68-3d621437e187@github.com>
Message-ID: <NQdteLZWHrl8o6359piXLHCa0SYgJ4y4Hz5Vibv2VGs=.5bbd7c00-f1d1-4db4-aaf3-3f30729dc91f@github.com>

On Mon, 19 Jun 2023 14:18:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This pull request contains a backport of commit [d6c2ee34](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/d6c2ee3448a14b3e5a392aacc11ed8e47d388f80__;!!ACWV5N9M2RV99hQ!OD7LAhsqxyc5YNrxjKmpLYJCCngVm706aY3NMRMXyihGIzSIbP4H6H2INaanHemHbj9dHTsmhmOUJZhPmeXAa5_r8Rsx$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It fixes the regression introduced by [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).

This pull request has now been integrated.

Changeset: beb0d957
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/beb0d9579bd8ab819b5f45c91f474807a5701611
Stats:     13 lines in 3 files changed: 7 ins; 1 del; 5 mod

8310054: ScrollPane insets are incorrect

Reviewed-by: honkar, prr
Backport-of: d6c2ee3448a14b3e5a392aacc11ed8e47d388f80

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

PR: https://git.openjdk.org/jdk21/pull/33


From achung at openjdk.org  Tue Jun 20 20:01:13 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 20 Jun 2023 20:01:13 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v3]
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <i0Yj-SnBorXd1dhgKDaI8-pzr2IVTKLvVLSDqXkBSww=.f7e33357-3f01-4aa8-8772-d279970fd341@github.com>

> 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:

  wait for window state change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14226/files
  - new: https://git.openjdk.org/jdk/pull/14226/files/2f689808..e80c3dd5

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

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

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


From aivanov at openjdk.org  Tue Jun 20 20:06:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Jun 2023 20:06:05 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
Message-ID: <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>

On Thu, 15 Jun 2023 22:45:44 GMT, Phil Race <prr at openjdk.org> 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1599424117


From achung at openjdk.org  Tue Jun 20 20:08:20 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 20 Jun 2023 20:08:20 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v4]
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <HzwXL4JE7L_esl3Ns9RUsdn5u4nfY-IERIRhZ2hJ64k=.49643de7-cedd-4cf8-90c0-0f05b29962f3@github.com>

> 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:

  updated test lastFrameState variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14226/files
  - new: https://git.openjdk.org/jdk/pull/14226/files/e80c3dd5..767747a2

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

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

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


From aivanov at openjdk.org  Tue Jun 20 20:11:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Jun 2023 20:11:08 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <CQtawPztoRit65n2rpRIZV_p6kyqqRFf9989uTvdtzc=.2e4eb65a-7c78-46d5-8773-43533a8cd930@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <CQtawPztoRit65n2rpRIZV_p6kyqqRFf9989uTvdtzc=.2e4eb65a-7c78-46d5-8773-43533a8cd930@github.com>
Message-ID: <hwtgpeGgDXJD5NyjD92lMlMQOYys-4xprzJVLEEgv-4=.a27903ff-b56f-48ba-8e3f-fb208f029042@github.com>

On Thu, 15 Jun 2023 17:46:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I don't know about the more extensive test suite Phil alludes to, though

Neither do I know about more extensive testing. I presume these four entry points were not used externally. Yet _?compiles?_ may not be enough. What does your _?works?_ mean? Did you run it with an AccessBridge client?

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1599430148


From prr at openjdk.org  Tue Jun 20 20:20:06 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 20:20:06 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing [v2]
In-Reply-To: <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
 <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>
Message-ID: <h9mYpeNkMkSaPCVicDMv1lSH1nm_x1DSdPpIWV1VxxA=.a5b76e1c-fd64-460b-ac0a-2ce9d8e44d51@github.com>

On Wed, 14 Jun 2023 09:45:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
>> This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
>> I could not find any JBS which did that code change.
>> 
>> Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by prr (Reviewer).

So there's two things at play here
(1) the orientation property set on the toolbar, which governs how the components on the toolbar are laid out.
(2) the special interpretation by JToolBar of being laid out on one side of a BorderLayout.
I don't know that I really understand why
>For drag-out to work correctly, it is recommended that you add JToolBar instances to one of the four "sides"
> of a container whose layout manager is a BorderLayout, and do not add children to any of the other four "sides".

my guess is that it just has the right characteristics - the CENTER component would be free to use for the rest
of the window, and empty sides are not an issue, and you can easily make it undock from any edge, and redock
on any edge without affecting layout of the rest of the window.

I've played around with it and it seems to me that the intent of the code you are removing is that
a HORIZONTAL layout implies it was docked on a side that would be HORIZONTAL - but in that
case why NORTH and not SOUTH ?

And I've verified that its perfectly possible, if a bit weird, to have HORIZONTAL toolbar on the EAST
i.e toolbar buttons laid out left to right.

So conflating orientation of the toolbar with the edge on which it is docked is probably wrong.

BTW you should add to the bug evaluation that this code was introduced by the fix for

https://bugs.openjdk.org/browse/JDK-4700351

The reasoning there seems to be a bit back and forth and confusing as to what views won out,
but I do not agree with all the comment.
For example I don't agree that "Also, when placed in a BorderLayout, the orientation should change
to the appropriate value, even if the orientation has been set explicitly"

But PROBABLY most people putting a toolbar on the EAST will make it vertical so I expect few apps
to see an unwelcome change in behaviour here .. but there's always a risk of that.

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

PR Review: https://git.openjdk.org/jdk/pull/14444#pullrequestreview-1488953439
PR Comment: https://git.openjdk.org/jdk/pull/14444#issuecomment-1599440139


From prr at openjdk.org  Tue Jun 20 20:25:15 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 20:25:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <ELnPTmj_oP5vV_spnx855G7rHvSrglS31H2TwRQ1xwg=.8557871f-3ab2-40ed-bee4-2574c1865be9@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I have no issues with the enhanced Java 2D tests to cover both generational and original ZGC.
But I'll leave it to hotspot reviews to formally approve the fix since those tests are such a tiny part of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1599445397


From prr at openjdk.org  Tue Jun 20 20:36:04 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 20:36:04 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
Message-ID: <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>

On Tue, 20 Jun 2023 20:03:09 GMT, Alexey Ivanov <aivanov at openjdk.org> 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1599457552


From jiangli at openjdk.org  Tue Jun 20 21:16:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 21:16:18 GMT
Subject: Withdrawn: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <zzEzkcZuHQXoB4FrJrtnm3Cd9zgE4D8a4zYdpggZtjE=.32f8630c-67a9-4eee-8b0d-53ffd3a640f2@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/Nativ...

This pull request has been closed without being integrated.

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

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


From tr at openjdk.org  Wed Jun 21 03:30:03 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 Jun 2023 03:30:03 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
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>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
 <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>
Message-ID: <tuMkHCx_BBZVajoykPiIGMsGDjRHqIy2OQhAdTkm6RM=.78c10f06-f810-422e-bab3-93cf1445958d@github.com>

On Tue, 20 Jun 2023 20:33:32 GMT, Phil Race <prr at openjdk.org> 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.

I have been spending some time in analyzing the String width and position, they seems to be fine. And what I have observed is the border of JTableHeader seems to be having an offset (from 100% to 225%), i.e., it is varying w.r.t scaling, maybe a rounding factor too. Since the border is moved to left slightly (maybe 1pixel), so we are seeing that the string is "cut off". I guess if we work on correcting the JTableMetal Border along with adding a margin space (Right), the issue will be fixed? (Screen shot added - Maybe have to zoom-in to see the difference in border w.r.t data cell border)

<img width="554" alt="JTableSizeHeaderScalingComparision" src="https://github.com/openjdk/jdk/assets/94159358/f683bf9a-6b4a-4249-b8ec-41e0925c057d">

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1600017858


From psadhukhan at openjdk.org  Wed Jun 21 05:06:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2023 05:06:17 GMT
Subject: RFR: 6664309: Docking point of a floating toolbar changes after
 closing [v2]
In-Reply-To: <h9mYpeNkMkSaPCVicDMv1lSH1nm_x1DSdPpIWV1VxxA=.a5b76e1c-fd64-460b-ac0a-2ce9d8e44d51@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
 <putAmlleqDv3jLMTDxWkOU7TCChYma28LpB5Y3J4whc=.66297f0a-55bf-4baa-9ef5-f735afdbf839@github.com>
 <h9mYpeNkMkSaPCVicDMv1lSH1nm_x1DSdPpIWV1VxxA=.a5b76e1c-fd64-460b-ac0a-2ce9d8e44d51@github.com>
Message-ID: <Qpp6M4UUTXM4N8Sev6CEwrB9sFcDEL4LTp1usf_IAZY=.20cc23fc-da27-479a-8874-bbd1270cc2cf@github.com>

On Tue, 20 Jun 2023 20:17:04 GMT, Phil Race <prr at openjdk.org> wrote:

> But PROBABLY most people putting a toolbar on the EAST will make it vertical so I expect few apps
> to see an unwelcome change in behaviour here .. but there's always a risk of that.

I am not sure on this point being "unwelcome change"....I think even if there is a change in behaviour, it is as per expectation as 
If a user docks a "horizontal" toolbar in EAST and then it is dragged and floated and then closed, I think it should be expected to dock the toolbar as it is ie HORIZONTAL in EAST side, that is what it was before docking. If orientation is changed to VERTICAL while in floating state and then closed, then the toolbar should be docked at EAST in VERTICAL state

As you correctly pointed out it is not correct that `"the orientation should change to the appropriate value, even if the orientation has been set explicitly"` so orientation and docking point should not be changed by the implementation.
Also, it was mentioned in that bug that `"The documentation should be changed to clarify this. "` which was not done even though the implementation was done so it seems prudent to rectify the implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/14444#issuecomment-1600076628


From jwaters at openjdk.org  Wed Jun 21 05:32:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 05:32:46 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API [v2]
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Revert AccessBridgeWindowsEntryPoints.h
 - Remove from WinAccessBridge.DEF
 - Revert AccessBridgeWindowsEntryPoints.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13734/files
  - new: https://git.openjdk.org/jdk/pull/13734/files/ef810f7f..835513ce

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

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

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


From jwaters at openjdk.org  Wed Jun 21 05:32:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 05:32:47 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API
In-Reply-To: <hwtgpeGgDXJD5NyjD92lMlMQOYys-4xprzJVLEEgv-4=.a27903ff-b56f-48ba-8e3f-fb208f029042@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <CQtawPztoRit65n2rpRIZV_p6kyqqRFf9989uTvdtzc=.2e4eb65a-7c78-46d5-8773-43533a8cd930@github.com>
 <hwtgpeGgDXJD5NyjD92lMlMQOYys-4xprzJVLEEgv-4=.a27903ff-b56f-48ba-8e3f-fb208f029042@github.com>
Message-ID: <TvoPM8nEBsvo8ftf0XuSwCeDOQmCPP89H581NoDZ-jo=.3dda2bf7-a519-4ff6-ad19-4aaa70c49559@github.com>

On Tue, 20 Jun 2023 20:08:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I don't know about the more extensive test suite Phil alludes to, though
>
>> I don't know about the more extensive test suite Phil alludes to, though
> 
> Neither do I know about more extensive testing. I presume these four entry points were not used externally. Yet _?compiles?_ may not be enough. What does your _?works?_ mean? Did you run it with an AccessBridge client?

@aivanov-jdk The client does indeed function on my end without issue, but I don't know whether it will do so on other devices as well

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600098202


From jwaters at openjdk.org  Wed Jun 21 05:50:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 05:50:07 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API [v2]
In-Reply-To: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
Message-ID: <-0ngILYxMZtzPMpBkdJzx7AEXuStrJ1qDPQnRBav9uA=.3ccaf6ac-7ac6-48ec-ac5c-3c0866a3ac83@github.com>

On Wed, 21 Jun 2023 05:32:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
>> 
>> addJavaEventNotification
>> removeJavaEventNotification
>> addAccessibilityEventNotification
>> removeAccessibilityEventNotification
>> 
>> 
>> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert AccessBridgeWindowsEntryPoints.h
>  - Remove from WinAccessBridge.DEF
>  - Revert AccessBridgeWindowsEntryPoints.cpp

JTReg sure does have a sense of humour, immediately crashing and leaving that ugly cross on the tests the moment I say that

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600170971


From djelinski at openjdk.org  Wed Jun 21 06:34:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 06:34:10 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical
 methods in its C API [v2]
In-Reply-To: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
Message-ID: <tOZBd1LqvM1XcORs6TOXRtveLvK3mCaw8ZN4-aJSQBA=.de375a78-6a7c-4237-bf86-18f778d7c0da@github.com>

On Wed, 21 Jun 2023 05:32:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
>> 
>> addJavaEventNotification
>> removeJavaEventNotification
>> addAccessibilityEventNotification
>> removeAccessibilityEventNotification
>> 
>> 
>> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert AccessBridgeWindowsEntryPoints.h
>  - Remove from WinAccessBridge.DEF
>  - Revert AccessBridgeWindowsEntryPoints.cpp

LGTM. These methods are not usable outside of the windowsaccessbridge dll. Caller would need a working instance of WinAccessBridge class to pass in `this` parameter, and there's no way to get one outside of the DLL.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13734#pullrequestreview-1489858272


From jwaters at openjdk.org  Wed Jun 21 06:40:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:40:07 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll erroneously includes private
 methods in its C API [v2]
In-Reply-To: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
Message-ID: <ZR5R2nFpTumZKKBqasfLmlRu0JDuHvxqyxJRPZVgvEQ=.f4adf002-9931-4747-8647-5d1cd75e4974@github.com>

On Wed, 21 Jun 2023 05:32:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
>> 
>> addJavaEventNotification
>> removeJavaEventNotification
>> addAccessibilityEventNotification
>> removeAccessibilityEventNotification
>> 
>> 
>> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert AccessBridgeWindowsEntryPoints.h
>  - Remove from WinAccessBridge.DEF
>  - Revert AccessBridgeWindowsEntryPoints.cpp

Right, thanks Daniel

I will change the title of the PR first

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600265379
PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600265640


From jwaters at openjdk.org  Wed Jun 21 06:46:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:46:12 GMT
Subject: Integrated: 8307145: windowsaccessbridge.dll erroneously includes
 private methods in its C API
In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
Message-ID: <t9qIgcxPwVISgCpbuBbT6QlJ7udy9TLBRZWtXNM56Xw=.3d81ae85-70e7-4633-b69c-2e8c0cf36d1d@github.com>

On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
> 
> addJavaEventNotification
> removeJavaEventNotification
> addAccessibilityEventNotification
> removeAccessibilityEventNotification
> 
> 
> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

This pull request has now been integrated.

Changeset: 3faba07a
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3faba07ae3f961c3b97434d59512d32519cb7a27
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8307145: windowsaccessbridge.dll erroneously includes private methods in its C API

Reviewed-by: djelinski

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

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


From jwaters at openjdk.org  Wed Jun 21 06:46:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:46:11 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll erroneously includes private
 methods in its C API [v2]
In-Reply-To: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
Message-ID: <808n1kahBdtnhzoZ4CTD39oZdnIszwkHlCyDg3vWTAc=.30e413ab-a6ae-44b9-b0c5-59b68079dc14@github.com>

On Wed, 21 Jun 2023 05:32:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
>> 
>> addJavaEventNotification
>> removeJavaEventNotification
>> addAccessibilityEventNotification
>> removeAccessibilityEventNotification
>> 
>> 
>> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert AccessBridgeWindowsEntryPoints.h
>  - Remove from WinAccessBridge.DEF
>  - Revert AccessBridgeWindowsEntryPoints.cpp

Thanks all for reviewing this change!

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600269893


From jwaters at openjdk.org  Wed Jun 21 06:47:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:47:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <0zdhhpte62afwO6bR4wuM19NtaZ9tIUudr4f4S2sXdQ=.7ee922ac-8e24-45e5-8148-423cbbc348ee@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600271647


From chen.j.patrick at gmail.com  Wed Jun 21 06:50:16 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Wed, 21 Jun 2023 08:50:16 +0200
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <0zdhhpte62afwO6bR4wuM19NtaZ9tIUudr4f4S2sXdQ=.7ee922ac-8e24-45e5-8148-423cbbc348ee@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <0zdhhpte62afwO6bR4wuM19NtaZ9tIUudr4f4S2sXdQ=.7ee922ac-8e24-45e5-8148-423cbbc348ee@github.com>
Message-ID: <CANmuJ8vMcNt-nUPQgadLaJ5+WV_U_X73FzWVdOSJJHUjoWnOOg@mail.gmail.com>

No rejected

Le mer. 21 juin 2023, 08:47, Julian Waters <jwaters at openjdk.org> a ?crit :

> On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org>
> wrote:
>
> >> On Windows, the basic Java Integer types are defined as long and
> __int64 respectively. In particular, the former is rather problematic since
> it breaks compilation as the Visual C++ becomes stricter and more compliant
> with every release, which means the way Windows code treats long as a
> typedef for int is no longer correct, especially with -permissive- enabled.
> Instead of changing every piece of broken code to match the jint = long
> typedef, which is far too time consuming, we can instead change jint to an
> int (which is still the same 32 bit number type as long), as there are far
> fewer problems caused by this definition. It's better to get this over and
> done with sooner than later when a future version of Visual C++ finally
> starts to break on existing code
> >
> > Julian Waters has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Fix the code that is actually warning
>
> Bumping
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600271647
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230621/9855c0aa/attachment.htm>

From djelinski at openjdk.org  Wed Jun 21 07:48:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 07:48:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Please update copyright years where they aren't at 2023 yet.

I verified these changes on Ubuntu 20.04 + clang 10; they are both necessary and sufficient to make the build pass with warnings as errors. I saw one more warning:

clang: warning: argument unused during compilation: '-static-libstdc++' [-Wunused-command-line-argument]

in `BUILD_SYSLOOKUPLIB_link.log`, but that one does not break the build.

I'm going to approve this once you fix the mentioned issues. Thanks for working on this!

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:

> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \

please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

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

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1489972241
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1236510850


From jwaters at openjdk.org  Wed Jun 21 08:22:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 08:22:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <8mSr3SYUR0t4eP-T6eJxu4EM4jhnz-2YMO8RBtrAoIQ=.99c452b4-dc5c-4579-a89b-d46d744a6579@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

...

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600400436


From dmarkov at openjdk.org  Wed Jun 21 08:29:08 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 21 Jun 2023 08:29:08 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v4]
In-Reply-To: <HzwXL4JE7L_esl3Ns9RUsdn5u4nfY-IERIRhZ2hJ64k=.49643de7-cedd-4cf8-90c0-0f05b29962f3@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <HzwXL4JE7L_esl3Ns9RUsdn5u4nfY-IERIRhZ2hJ64k=.49643de7-cedd-4cf8-90c0-0f05b29962f3@github.com>
Message-ID: <JUngJ0utHcqD6wMlN8OsS-PVRxu5-b9stAU2vFjOpzw=.ff444610-ac82-45cf-a5d1-9e93449f85c6@github.com>

On Tue, 20 Jun 2023 20:08:20 GMT, Alisen Chung <achung at openjdk.org> 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:
> 
>   updated test lastFrameState variable

Changes requested by dmarkov (Reviewer).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 969:

> 967:     }
> 968: 
> 969:     private void waitForWindowState(int state) {

It would be wise to check the state of the peer in the beginning to avoid unnecessary usage of WindowStateListener and wait-notify mechanism if we are already in the state which is required.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 971:

> 969:     private void waitForWindowState(int state) {
> 970:         Object lock = new Object();
> 971:         target.addWindowStateListener(new WindowStateListener() {

I think WindoweStateListener should be removed once we are done

test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java line 48:

> 46: public class MaximizedToIconified
> 47: {
> 48:     static volatile int lastFrameState;

What is the purpose of test change? Can you elaborate, please?

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

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1490108322
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1236601686
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1236603661
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1236605943


From abhiscxk at openjdk.org  Wed Jun 21 08:59:06 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 Jun 2023 08:59:06 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <CxO8LYLfchSjsd94DipVXzLW_Np8CtTE9_QCwreTWc0=.695f3aad-651b-4b8d-ae0f-a05af403219d@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
 <o1wJgosBd6MqqsI2D_q7bVadH04FRIsUCV7WZWPV1GA=.53dbe234-5af1-44ba-bbac-7d9d67df4352@github.com>
 <CxO8LYLfchSjsd94DipVXzLW_Np8CtTE9_QCwreTWc0=.695f3aad-651b-4b8d-ae0f-a05af403219d@github.com>
Message-ID: <zO9NicVkHfVsksIMle1Q4rEtEe5c-IKkSgltXrC5meQ=.b5352b96-f354-4ff8-9036-34aebb2908ef@github.com>

On Mon, 19 Jun 2023 12:36:31 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> Can you please elaborate more or what logic can be added here?
>
> I mean `getAccessibleChild(..., 1)` can still return null (when both `if`s of `case 1` resolve to false). Let's consider the following code:
> 
> public void doSmthWith(JComponent component, BasicComboBoxUI ui) {
>     if (ui.getAccessibleChildrenCount(component) > 1) {
>         // well, we have at least 2 components, so we can expect to get a valid object below
>         final var ac = ui.getAccessibleChild(component, 1)
>                                   .getAccessibleContext(); // <= possible NPE
>         // ...
>     }
> }
> 
> 
> I think we have to return 1 from `getAccessibleChildrenCount(...)` for the cases when `getAccessibleChild(..., 1)` returns `null`

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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1236653059


From djelinski at openjdk.org  Wed Jun 21 09:27:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 09:27:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <R47GRCPHRK2m8lVzMN5eoW773ZqoCidoSBKImdqwTTk=.9c7be02e-cc55-44e7-928d-5b39420a5371@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 475:

> 473:         topLevelWindow = hwnd;
> 474:     } else {
> 475:         EnumChildWindows(hwnd, (WNDENUMPROC) EnumChildProc, nullptr);

Did you try to compile this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1236688830


From duke at openjdk.org  Wed Jun 21 10:04:18 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 21 Jun 2023 10:04:18 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
Message-ID: <gcKNZy2FjWuGOLEkhu0r9QTkdUYqr9owLHCW3Y2wa5o=.e92ca8ae-99b6-4932-8a46-2698f03ca12d@github.com>

On Thu, 15 Jun 2023 22:51:16 GMT, Phil Race <prr at openjdk.org> 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
>
> test/jdk/javax/swing/regtesthelpers/JRobot.java line 171:
> 
>> 169:      */
>> 170:     public void clickMouse() {
>> 171:         clickMouse(InputEvent.BUTTON1_DOWN_MASK);
> 
> Note that this is a different int value than the old MASK constant so it is important that you ran all tests (which you say you did) in case some test is not consistently using the Robot API and will end up mixing old and new which will likely cause failures.

In this case presses and release happening inside clickMouse overloaded function, this will not mix old and new key     
 ```
public void clickMouse(int buttons) {
        mousePress(buttons);
        mouseRelease(buttons);
        delay();
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1236737071


From aivanov at openjdk.org  Wed Jun 21 10:11:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Jun 2023 10:11:20 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll erroneously includes private
 methods in its C API
In-Reply-To: <hwtgpeGgDXJD5NyjD92lMlMQOYys-4xprzJVLEEgv-4=.a27903ff-b56f-48ba-8e3f-fb208f029042@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <CQtawPztoRit65n2rpRIZV_p6kyqqRFf9989uTvdtzc=.2e4eb65a-7c78-46d5-8773-43533a8cd930@github.com>
 <hwtgpeGgDXJD5NyjD92lMlMQOYys-4xprzJVLEEgv-4=.a27903ff-b56f-48ba-8e3f-fb208f029042@github.com>
Message-ID: <R-_z8vfBxWLr4YCNRvI4eUiWRTgcijCi12Wzyx1CsDw=.70c42150-a9d5-420b-a0d1-500d02d4cbd2@github.com>

On Tue, 20 Jun 2023 20:08:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I don't know about the more extensive test suite Phil alludes to, though
>
>> I don't know about the more extensive test suite Phil alludes to, though
> 
> Neither do I know about more extensive testing. I presume these four entry points were not used externally. Yet _?compiles?_ may not be enough. What does your _?works?_ mean? Did you run it with an AccessBridge client?

> @aivanov-jdk The client does indeed function on my end without issue, but I don't know whether it will do so on other devices as well

That's good to know.

I would've approved it, if I'd had a slightest chance to read your reply.

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600561897


From aivanov at openjdk.org  Wed Jun 21 10:39:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Jun 2023 10:39:16 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT
In-Reply-To: <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
Message-ID: <xghKrtFGjLMyXJ8fZNLeG_pdh2xoOTckMEhxLfKhMr8=.fbcdff8d-d6ab-4ab2-b3f7-419f5f5fd02c@github.com>

On Thu, 15 Jun 2023 22:57:25 GMT, Phil Race <prr at openjdk.org> wrote:

> I still quibble with the premise of this bug. No exceptions or any nasty stuff will happen if you don't use the EDT to call getSize(). It is more a case of you may get stale results.

Stale result may lead to a test failure because robot moved mouse to an incorrect location.

I submitted this bug after I noticed it in a code review. It might have been the reason why that test failed intermittently. That test was rewritten without using `JRobot` if my memory serves me right.

> And nothing in the AWT docs say you need to do this.

AWT docs don't say AWT is thread-safe either, at least explicitly.

Yet this case is for Swing components where the docs always say Swing is not thread-safe. The `JRobot` class is `test/jdk/javax/swing/regtesthelpers/` which implies it's used for testing Swing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14354#issuecomment-1600597862


From jwaters at openjdk.org  Wed Jun 21 10:51:20 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 10:51:20 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll erroneously includes private
 methods in its C API [v2]
In-Reply-To: <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>
 <YzLhV_rP8nbYYbY-zacOmWaw3e-S8tYXys3oSQ6EkZs=.44edec50-bf63-49a4-9fa8-ec4238933ec2@github.com>
Message-ID: <ZpknDRY4S6n0ew44rwTQ_udjuytc56jMLDSCNCCqkd0=.17f28722-1650-4bd2-987b-cd8c81cf0346@github.com>

On Wed, 21 Jun 2023 05:32:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:
>> 
>> addJavaEventNotification
>> removeJavaEventNotification
>> addAccessibilityEventNotification
>> removeAccessibilityEventNotification
>> 
>> 
>> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert AccessBridgeWindowsEntryPoints.h
>  - Remove from WinAccessBridge.DEF
>  - Revert AccessBridgeWindowsEntryPoints.cpp

Ah, sorry about that. I've had several changes starved of reviews recently and lying around for almost a month, and was feeling fairly frustrated and impatient :(

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

PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1600612951


From djelinski at openjdk.org  Wed Jun 21 12:07:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 12:07:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <lGA7o7ITfyNyU_WFY_Yz48yh32hIZn_JtEBNkdXsX7w=.ff33e800-c509-48e6-b3d9-2739a88dace4@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Compilation should be a good enough test for the `long` -> `jint` changes. These changes are supposed to address [this difference](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments) between MSVC behavior and the C++ standard. When compiled with `-permissive-` or with a compiler that puts more emphasis on standards conformance (like clang), the current code fails to compile.

I verified some of the generated binaries by comparing the results of `dumpbin /all` before and after the change. Most of the time the changes were limited to timestamp, UUID and mangled function names. `Jaccesswalker.exe` had a few more changes because of a changed format string. None of the changed function names in client libs area are externally visible, but there are some observable changes to `c2v` functions exported from jvm.dll.

I had to revert some of the `NULL`->`nullptr` changes to get this to compile; I assume this will be addressed before this PR is merged. Judging by the PR title, these changes don't belong here anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600710570


From jwaters at openjdk.org  Wed Jun 21 12:13:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 12:13:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <IzXWSLSA_0wc-cCWzaQ63uRX8-IzeIpMXOndG3R9wPY=.910d85fe-8ab7-4d4c-8588-863cc67468c8@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Yeah, those were code cleanups I thought I could do out of convenience, I'll revert them all before this goes in

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600719023


From aturbanov at openjdk.org  Wed Jun 21 12:34:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Jun 2023 12:34:06 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <Ri64Ry2eSmmb5nshmuc8Fl7WMyBr-vyEmQkNWYHK7lM=.ff035ccd-e77a-42b5-8689-0c6b25dc7967@github.com>

On Tue, 20 Jun 2023 10:04:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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)

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 102:

> 100:                 if (c instanceof JButton) {
> 101:                     Icon icon = ((JButton) c).getIcon();
> 102:                     if( icon.getIconHeight() > height - 4 ||

Suggestion:

                    if (icon.getIconHeight() > height - 4 ||

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1236924884


From mbaesken at openjdk.org  Wed Jun 21 15:26:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 15:26:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
Message-ID: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@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.

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

Commit messages:
 - JDK-8310550

Changes: https://git.openjdk.org/jdk/pull/14593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310550
  Stats: 14 lines in 12 files changed: 0 ins; 7 del; 7 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 psadhukhan at openjdk.org  Wed Jun 21 15:44:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2023 15:44:15 GMT
Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus
Message-ID: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>

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)

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

Commit messages:
 - 6875229:  Wrong placement of icons in JTabbedPane in Nimbus
 - 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/14596/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14596&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6875229
  Stats: 128 lines in 2 files changed: 126 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14596/head:pull/14596

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


From aivanov at openjdk.org  Wed Jun 21 15:50:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Jun 2023 15:50:10 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>

On Tue, 20 Jun 2023 10:04:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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)

Does Windows classic theme has its own set UIManager settings?

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 88:

> 86:             }
> 87:         } else {
> 88:             buttonWidth = buttonHeight;

This means line 71 can be removed because `buttonWidth` is never read from `UIManager`.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 89:

> 87:         } else {
> 88:             buttonWidth = buttonHeight;
> 89:             buttonWidth += 2;

Shouldn't the buttons be square in the classic theme?

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 105:

> 103:                         icon.getIconWidth() > height - 2) {
> 104:                         throw
> 105:                            new RuntimeException("Wrong title icon size");

Suggestion:

                        throw new RuntimeException("Wrong title icon size");

The line without wrapping is still within 80-column limit, isn't it?

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

PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1491081284
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1237221766
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1237202986
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1237207281


From aivanov at openjdk.org  Wed Jun 21 16:01:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Jun 2023 16:01:03 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width
In-Reply-To: <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
Message-ID: <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>

On Wed, 21 Jun 2023 15:47:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does Windows classic theme has its own set UIManager settings?

However, it may still not help: the Windows desktop properties would return the size for the current theme in Windows, which is never a classic theme in Windows 10 and later. Therefore the size would be different.

I wonder if the values stored in the UI Manager should have this trick applied rather tweaking the values on the fly. If a programmer gets the values from `UIManager` directly, they will get the incorrect value.

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

PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1601106370


From honkar at openjdk.org  Wed Jun 21 16:16:08 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Jun 2023 16:16:08 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v4]
In-Reply-To: <JUngJ0utHcqD6wMlN8OsS-PVRxu5-b9stAU2vFjOpzw=.ff444610-ac82-45cf-a5d1-9e93449f85c6@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <HzwXL4JE7L_esl3Ns9RUsdn5u4nfY-IERIRhZ2hJ64k=.49643de7-cedd-4cf8-90c0-0f05b29962f3@github.com>
 <JUngJ0utHcqD6wMlN8OsS-PVRxu5-b9stAU2vFjOpzw=.ff444610-ac82-45cf-a5d1-9e93449f85c6@github.com>
Message-ID: <njPnGoqqh8XY143jLv09UqpxkMcCDar6UnhvpUvVwFQ=.36148766-9dc7-49c8-85b8-de8fe3e6dd8b@github.com>

On Wed, 21 Jun 2023 08:26:12 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated test lastFrameState variable
>
> test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java line 48:
> 
>> 46: public class MaximizedToIconified
>> 47: {
>> 48:     static volatile int lastFrameState;
> 
> What is the purpose of test change? Can you elaborate, please?

@dmarkov20 Although the test does not explicitly test the cases mentioned below, it fails for the following two cases because the lastFrameState is changed as we progress through the states and should be reassigned when testing a new set of states. @alisenchung  is assigning this var within examineStates now.

> @alisenchung
> 
> The current fix works for the cases listed in the test but fails for the following scenarios. To make the test more stable it is better to reassign the static variable `lastFrameState = Frame.NORMAL` in examineStates after creating a new Frame [here ](https://github.com/openjdk/jdk/blob/57b8251241e2044d5039ce162bf4637a9b2e5466/test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java#L78), so that each time a new case is run it sets lastFrameState to default state.
> 
> ```
> // CASE 1:
> examineStates(new int[] {Frame.NORMAL, Frame.MAXIMIZED_BOTH, Frame.ICONIFIED});
> // CASE 2:
> examineStates(new int[] {Frame.NORMAL, Frame.ICONIFIED, Frame.MAXIMIZED_BOTH});
> ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1237259547


From erikj at openjdk.org  Wed Jun 21 17:01:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jun 2023 17:01:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <wNaBmeQdT388fGPZljNxxG_k4sROzgMRPxAN90lq4_Q=.c3057546-4179-4745-b99b-73d740091d5b@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

The update to Java.gmk is good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491263836


From kcr at openjdk.org  Wed Jun 21 17:13:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Jun 2023 17:13:09 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

Since this Enhancement was rejected for JDK 21, this PR should be closed.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601253343


From jiangli at openjdk.org  Wed Jun 21 17:19:06 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 Jun 2023 17:19:06 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>
Message-ID: <B5qoJt6AwrzqfvIK_DckqutqvD9PcfV-6St1jm1mkkg=.9b0ace3c-2f48-43ed-8a63-b8d22d36ee09@github.com>

On Wed, 21 Jun 2023 17:09:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Since this Enhancement was rejected for JDK 21, this PR should be closed.

Closing without integration accordingly, thanks.

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

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601273074


From jiangli at openjdk.org  Wed Jun 21 17:19:07 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 Jun 2023 17:19:07 GMT
Subject: [jdk21] Withdrawn: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <Fkl5WrrIC4tFAP3ThQCibl1ckqrEfW7I6dCGBFWyCsQ=.7e6eae76-9409-4726-9d67-077b2e82732f@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk21/pull/26


From dmarkov at openjdk.org  Wed Jun 21 19:16:06 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 21 Jun 2023 19:16:06 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v4]
In-Reply-To: <njPnGoqqh8XY143jLv09UqpxkMcCDar6UnhvpUvVwFQ=.36148766-9dc7-49c8-85b8-de8fe3e6dd8b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <HzwXL4JE7L_esl3Ns9RUsdn5u4nfY-IERIRhZ2hJ64k=.49643de7-cedd-4cf8-90c0-0f05b29962f3@github.com>
 <JUngJ0utHcqD6wMlN8OsS-PVRxu5-b9stAU2vFjOpzw=.ff444610-ac82-45cf-a5d1-9e93449f85c6@github.com>
 <njPnGoqqh8XY143jLv09UqpxkMcCDar6UnhvpUvVwFQ=.36148766-9dc7-49c8-85b8-de8fe3e6dd8b@github.com>
Message-ID: <ky0JbBQFsNf371-G3wimo_x3bOCl_yb9sK-GTpylkT8=.df2a6182-7401-4a41-819e-1a5d10c0cf75@github.com>

On Wed, 21 Jun 2023 16:12:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java line 48:
>> 
>>> 46: public class MaximizedToIconified
>>> 47: {
>>> 48:     static volatile int lastFrameState;
>> 
>> What is the purpose of test change? Can you elaborate, please?
>
> @dmarkov20 Although the test does not explicitly test the cases mentioned below, it fails for the following two cases because the lastFrameState is changed as we progress through the states and should be reassigned when testing a new set of states. @alisenchung  is assigning this var within examineStates now. Though, I would prefer to keep the initial assignment as-is and have the reassignment in examineStates.
> 
>> @alisenchung
>> 
>> The current fix works for the cases listed in the test but fails for the following scenarios. To make the test more stable it is better to reassign the static variable `lastFrameState = Frame.NORMAL` in examineStates after creating a new Frame [here ](https://github.com/openjdk/jdk/blob/57b8251241e2044d5039ce162bf4637a9b2e5466/test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java#L78), so that each time a new case is run it sets lastFrameState to default state.
>> 
>> ```
>> // CASE 1:
>> examineStates(new int[] {Frame.NORMAL, Frame.MAXIMIZED_BOTH, Frame.ICONIFIED});
>> // CASE 2:
>> examineStates(new int[] {Frame.NORMAL, Frame.ICONIFIED, Frame.MAXIMIZED_BOTH});
>> ```

Ah, I see now. I would suggest including that cases into the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1237543790


From duke at openjdk.org  Wed Jun 21 19:30:21 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 21 Jun 2023 19:30:21 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <XFcWzIb-rshjZJkrJ5FICx_48HP9ntCuHAEuxF_GHCs=.7fcf2b4f-5ec1-47ce-87e4-52255961866d@github.com>
References: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
 <XFcWzIb-rshjZJkrJ5FICx_48HP9ntCuHAEuxF_GHCs=.7fcf2b4f-5ec1-47ce-87e4-52255961866d@github.com>
Message-ID: <liMrI2QrDFI4nf_UInpTX3q6Vr8DhAkM5eEuW0OKyKs=.e6af4e72-0a2c-4d7c-b5bd-ab021a58be91@github.com>

On Mon, 17 Oct 2022 23:36:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi there!
>> JetBrains has faced with a bug on Apple M2 MacBooks when tapping (_not_ pressing) with two fingers on a trackpad generates wrong mouse modifiers (which are returned by [MouseEvent.getModifiersEx](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx())).
>> 
>> <s>As far as I see, OpenJDK bug tracker still doesn't contain such a bug and I don't have rights to create a new one, so the PR doesn't refer any id</s> UPD: fixed. Here is the bug link from the JetBrains own tracker: [JBR-4765](https://youtrack.jetbrains.com/issue/JBR-4765/Cannot-invoke-context-menu-by-two-fingers-tapping-on-MacBook-with-M2-chip).
>> 
>> The bug is 100% reproducible on M2 MacBooks (at least under macOS 12.5). It's also reproducible on M1 MacBooks, but much more rarely (about 10-15% of reproducibility).
>> 
>> ## Steps to reproduce
>> 1. Enable `System Preferences` -> `Trackpad` -> `Tap to click`
>> 2. Tap with two fingers in the following app:
>> 
>> import javax.swing.*;
>> import java.awt.event.MouseAdapter;
>> import java.awt.event.MouseEvent;
>> 
>> class MouseWindow {
>>     final JFrame frame;
>> 
>>     MouseWindow() {
>>         frame = new JFrame();
>>         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
>> 
>>         frame.setTitle("Mouse window");
>> 
>>         frame.addMouseListener(new MouseAdapter() {
>>             @Override
>>             public void mousePressed(MouseEvent e) {
>>                 System.out.println(e);
>>             }
>>         });
>> 
>>         frame.pack();
>> 
>>         frame.setSize(300, 300);
>> 
>>         frame.setVisible(true);
>>     }
>> 
>>     public static void main(String[] args) {
>>         SwingUtilities.invokeLater(MouseWindow::new);
>>     }
>> }
>> 
>> 
>> ### Expected
>> Printed mouse event has `modifiersEx` is `4096` (which is `InputEvent.BUTTON3_DOWN_MASK`)
>> 
>> ### Actual
>> Printed mouse event has `modifiersEx` is `4352` (which is `InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`)
>> 
>> ## Evaluation
>> The following happens when a native mouse event reaches Java:
>> 1. `NSEvent.nsToJavaModifiers(0)` called inside [CPlatformResponder.handleMouseEvent():81](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L81) returns `0`. Earlier it always returned `4096` (`InputEvent.BUTTON3_DOWN_MASK`) but not in the cases of M2 tapping. For a trackpad press (not a tap) it still return...
>
> Can we report this behaviour change to Apple for investigation?

@mrserb,
> Can we report this behaviour change to Apple for investigation?

I think this is our problem here - we ask for the _currently pressed modifiers_ only after the event has happened (and dispatched to us), so there is no guarantee that a user doesn't manage to release the mouse button before the press event is dispatched to us.

Do you agree?

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

PR Comment: https://git.openjdk.org/jdk/pull/10429#issuecomment-1601552204


From kizune at openjdk.org  Wed Jun 21 20:43:03 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Jun 2023 20:43:03 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
Message-ID: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>

Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
Also updating the copyright year.

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

Commit messages:
 - 8309733: [macOS, Accessibility] VoiceOver: Incorrect announcements of JRadioButton

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

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


From aivanov at openjdk.org  Wed Jun 21 20:57:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Jun 2023 20:57:02 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <tuMkHCx_BBZVajoykPiIGMsGDjRHqIy2OQhAdTkm6RM=.78c10f06-f810-422e-bab3-93cf1445958d@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
 <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>
 <tuMkHCx_BBZVajoykPiIGMsGDjRHqIy2OQhAdTkm6RM=.78c10f06-f810-422e-bab3-93cf1445958d@github.com>
Message-ID: <g35E8PfTmdoRIpgDlTuK_oasTO37ZuyN6Ry0j1ygRbU=.03460775-b14f-4637-b1db-0b97dc82c956@github.com>

On Wed, 21 Jun 2023 03:25:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Since the border is moved to left slightly (maybe 1pixel), so we are seeing that the string is "cut off". I guess if we work on correcting the JTableMetal Border along with adding a margin space (Right), the issue will be fixed? (Screen shot added - Maybe have to zoom-in to see the difference in border w.r.t data cell border)

It's very likely the reason why. We saw that borders may render inconsistently: 1-, 2- or 3-pixel lines (for 225%).

I zoomed in your screenshot. The 100%-scale case has 1-pixel shadow and 1-pixel highlight. It seems the text is cut off by 1 pixel, the black pixels of ?e? are at the very edge of the shadow pixels. I'd expect to see blue-ish pixels of text antialiasing to the right of the black text pixels.

In 225%-scale case, the first separator looks better. It consists of 2-pixel shadow, 1-pixel background, 1-pixel highlight for the next header. On the background-colored pixel, I see pixels of text, blue-ish pixels of antialiasing. So the position of the text is still a bit off. It's no wonder if you take into account that it's 1-pixel off even for 100% case.

The second separator has more issues: 2-pixel shadow, 2-pixel background, 1-pixel highlight. There should be no background pixels between the shadow and highlight but there are? It's an inherent problem of scaled graphics. That background pixels also have parts of the text, 2 pixels.

In short, it seems there's still a text positioning issue? as if it doesn't account for antialiasing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1601660246


From dholmes at openjdk.org  Wed Jun 21 21:51:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 21:51:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Mostly seems okay - a couple of things need further adjusting I think.

Thanks.

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.

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?

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491961660
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237747922
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237749197


From rmahajan at openjdk.org  Thu Jun 22 00:01:16 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 22 Jun 2023 00:01:16 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v15]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <NKazWvpfjteBuUtWX0jjxLEohbIPYtzBHbTawMcQQeg=.5d52351a-8494-46bb-8ae2-2f60f0d7b23d@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

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

  get DPI based part size for widgets and parts that need it. This ensures that all parts and widgets get rendered correctly. I ensured this by running the SwingSet2 tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/36bec863..517b1243

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=13-14

  Stats: 34 lines in 2 files changed: 24 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From jwaters at openjdk.org  Thu Jun 22 02:55:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 02:55:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v5]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <puZ5zP_vpuAUhgolvMXTnk4BR4mSfe0w4eXhbTYkz98=.008a0d4b-8e8a-421c-904a-15be855f378f@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert NULL to nullptr changes in jaccesswalker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/5fa2d3eb..9a8a9158

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From jwaters at openjdk.org  Thu Jun 22 03:00:16 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 03:00:16 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Revert NULL to nullptr changes in jaccesswalker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/9a8a9158..a31e52e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From psadhukhan at openjdk.org  Thu Jun 22 03:44:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Jun 2023 03:44:19 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <3wO7IHa33io5uuqXst2Rh1j1Dr-F7SMk_JTtyScJT6Q=.dd397bba-28a6-49a4-9763-edcfacdd92c1@github.com>

> 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/04e8e888..f8467953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=00-01

  Stats: 9 lines in 3 files changed: 6 ins; 0 del; 3 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  Thu Jun 22 03:44:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Jun 2023 03:44:21 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>
Message-ID: <OF96hbG6CbEnCFCshbeEyZ06flhhp4su8PcHDIdXUn8=.36974c6f-10e7-480a-9cde-38d26db11163@github.com>

On Wed, 21 Jun 2023 15:58:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I wonder if the values stored in the UI Manager should have this trick applied rather tweaking the values on the fly. If a programmer gets the values from `UIManager` directly, they will get the incorrect value.

OK. UIManager is also updated with updated width so values will be identical

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1601968785


From psadhukhan at openjdk.org  Thu Jun 22 03:44:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Jun 2023 03:44:23 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
Message-ID: <91ouxxaBSGiyRjhEgiYi5R7UzCg0DW7KAWd9ba0LgSc=.668aaab0-6b4f-49f4-b13a-1f7949f572ab@github.com>

On Wed, 21 Jun 2023 15:44:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 88:
> 
>> 86:             }
>> 87:         } else {
>> 88:             buttonWidth = buttonHeight;
> 
> This means line 71 can be removed because `buttonWidth` is never read from `UIManager`.

It can be removed in the strict sense but we need something to initialise it to so kept it as it is, as it will do no harm

> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 89:
> 
>> 87:         } else {
>> 88:             buttonWidth = buttonHeight;
>> 89:             buttonWidth += 2;
> 
> Shouldn't the buttons be square in the classic theme?

If we make it exactly square, it results in some loss of aesthetics as can be seen here where icon is too close to right edge, so kept it as it is

![image](https://github.com/openjdk/jdk/assets/43534309/73a54d2d-308c-47e3-9809-420e278a9c6d)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1237952859
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1237953531


From duke at openjdk.org  Thu Jun 22 04:40:05 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Thu, 22 Jun 2023 04:40:05 GMT
Subject: RFR: 8307325: Verify the focus owner when non focused windows
 requesting focus [v2]
In-Reply-To: <GvPoYjKB48bcJGyqDVpIavie-xf1BIiIZ_csxYCZNIw=.d107a1aa-12b4-43f6-ba79-0e96a36c50be@github.com>
References: <tYKi1dYUhO_JjPfOi2jV0RMD2SfIpu5soQNbkKtdQS0=.5cceb380-71d7-4da8-8f17-b3d6f5bf98e5@github.com>
 <GvPoYjKB48bcJGyqDVpIavie-xf1BIiIZ_csxYCZNIw=.d107a1aa-12b4-43f6-ba79-0e96a36c50be@github.com>
Message-ID: <ySzVh6i-qVMthax4d9PnF_C0OI25Jx0slQ0-i6hjeCo=.235908a0-a7ab-4dfe-bcde-a4597c50cbbf@github.com>

On Tue, 16 May 2023 05:04:51 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following
>> 
>> 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus
>> across Windows.
>> 2.The request is remembered and  be granted when the Window is later focused If the platform does not support requesting focus
>> across Windows.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307325: Review comments fixed

Any volunteers for a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13790#issuecomment-1601998727


From duke at openjdk.org  Thu Jun 22 04:40:06 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Thu, 22 Jun 2023 04:40:06 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v5]
In-Reply-To: <oodhO-t4FiVs57TnqVz33f7Fg8fXIJf2T8lV7QmzA6k=.5fe52446-5e29-4193-aebd-ce3f4139d980@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
 <oodhO-t4FiVs57TnqVz33f7Fg8fXIJf2T8lV7QmzA6k=.5fe52446-5e29-4193-aebd-ce3f4139d980@github.com>
Message-ID: <Q6SRZo5puGOBeDlhLNih1uw9bassC181vW8_0GqPBtw=.394f22bd-09c6-4900-b6a4-364a4735ef58@github.com>

On Thu, 4 May 2023 09:56:18 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code modified

Any volunteers for a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13293#issuecomment-1601998652


From tr at openjdk.org  Thu Jun 22 04:56:03 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 Jun 2023 04:56:03 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <g35E8PfTmdoRIpgDlTuK_oasTO37ZuyN6Ry0j1ygRbU=.03460775-b14f-4637-b1db-0b97dc82c956@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
 <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>
 <tuMkHCx_BBZVajoykPiIGMsGDjRHqIy2OQhAdTkm6RM=.78c10f06-f810-422e-bab3-93cf1445958d@github.com>
 <g35E8PfTmdoRIpgDlTuK_oasTO37ZuyN6Ry0j1ygRbU=.03460775-b14f-4637-b1db-0b97dc82c956@github.com>
Message-ID: <VBgN2UNYWYD1VoUqcP3ot8S9GfieeBoY8mcZ6Eb-CXg=.05b520dc-2117-4f80-b8b3-1b7fb1dd3d01@github.com>

On Wed, 21 Jun 2023 20:54:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Since the border is moved to left slightly (maybe 1pixel), so we are seeing that the string is "cut off". I guess if we work on correcting the JTableMetal Border along with adding a margin space (Right), the issue will be fixed? (Screen shot added - Maybe have to zoom-in to see the difference in border w.r.t data cell border)
> 
> It's very likely the reason why. We saw that borders may render inconsistently: 1-, 2- or 3-pixel lines (for 225%).
> 
> I zoomed in your screenshot. The 100%-scale case has 1-pixel shadow and 1-pixel highlight. It seems the text is cut off by 1 pixel, the black pixels of ?e? are at the very edge of the shadow pixels. I'd expect to see blue-ish pixels of text antialiasing to the right of the black text pixels.
> 
> In 225%-scale case, the first separator looks better. It consists of 2-pixel shadow, 1-pixel background, 1-pixel highlight for the next header. On the background-colored pixel, I see pixels of text, blue-ish pixels of antialiasing. So the position of the text is still a bit off. It's no wonder if you take into account that it's 1-pixel off even for 100% case.
> 
> The second separator has more issues: 2-pixel shadow, 2-pixel background, 1-pixel highlight. There should be no background pixels between the shadow and highlight but there are? It's an inherent problem of scaled graphics. That background pixels also have parts of the text, 2 pixels.
> 
> In short, it seems there's still a text positioning issue? as if it doesn't account for antialiasing.

Ok, in summary there exists 2 major issues:
1. The text should positioned till the blue-ish pixels is just behind the header border for each header cell.
2. The header border to be aligned with data grid lines.
Right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1602007556


From abhiscxk at openjdk.org  Thu Jun 22 05:30:02 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Jun 2023 05:30:02 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <G430rhVa2s6Kkv0JfvlWW-1FK74OQoNS2qHPVzF16g8=.8ed91d89-a2fe-40eb-add0-5f5568e1779f@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

Verified the fix and it behaves as expected.

`Expected announcement: "Radio Two, radio button, 2 of 3. ..." `
As mentioned in JBS, should VO announce radiobutton's position also?

There is an another bug [JDK-8309732](https://bugs.openjdk.org/browse/JDK-8309732) for position issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14605#issuecomment-1602031731


From aboldtch at openjdk.org  Thu Jun 22 08:47:11 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 08:47:11 GMT
Subject: [jdk21] Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <-l-PUtkHpuka6haLkl2dJ7vfY0xRZuphvpoT8tGv7ZA=.d3088503-3528-4190-9579-893355eb91af@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6317249b
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6317249b50e039474f67c15507134bfc65a0fa79
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: eosterlund
Backport-of: a0595761ef35c4eec8cb84326a869b9473cd5bba

-------------

PR: https://git.openjdk.org/jdk21/pull/37


From asemenov at openjdk.org  Thu Jun 22 09:13:21 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:21 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/101bf062..842d33d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04-05

  Stats: 26 lines in 5 files changed: 11 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033


From asemenov at openjdk.org  Thu Jun 22 09:13:24 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:24 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
 <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
Message-ID: <1uzHyJeBll4YnB4uuKYWFX8e7z66iWHoYK4Ksu8T3Ic=.c2a86584-ea77-48f9-8306-368edb33d0af@github.com>

On Wed, 21 Jun 2023 07:35:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - 8308286 Fix clang warnings in linux code
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:
> 
>> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
>> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
>> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \
> 
> please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238236415


From mbaesken at openjdk.org  Thu Jun 22 09:26:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:26:06 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
Message-ID: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>

On Wed, 21 Jun 2023 21:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> 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 ?

> 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 .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238252196
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238254149


From djelinski at openjdk.org  Thu Jun 22 10:02:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 10:02:09 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
Message-ID: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>

On Thu, 22 Jun 2023 09:13:21 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:

> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Suggestion:

        DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
        DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
        DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
        DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
        DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:

> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \

move this one closer to the other clang (non-aix) suppressions

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238296391
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238297332


From djelinski at openjdk.org  Thu Jun 22 10:40:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 10:40:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
Message-ID: <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>

On Thu, 22 Jun 2023 03:00:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Revert NULL to nullptr changes in jaccesswalker

src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:

> 545:         snprintf( s, sizeof(s),
> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );

do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238338713


From aivanov at openjdk.org  Thu Jun 22 12:18:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 12:18:03 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
In-Reply-To: <VBgN2UNYWYD1VoUqcP3ot8S9GfieeBoY8mcZ6Eb-CXg=.05b520dc-2117-4f80-b8b3-1b7fb1dd3d01@github.com>
References: <3-275hTI8nq-hYCRojvLO_Wb9y49G0bfxr4aF8tYpfU=.cdabb0ca-e0a5-4fa7-9362-1ff75de6821d@github.com>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
 <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>
 <tuMkHCx_BBZVajoykPiIGMsGDjRHqIy2OQhAdTkm6RM=.78c10f06-f810-422e-bab3-93cf1445958d@github.com>
 <g35E8PfTmdoRIpgDlTuK_oasTO37ZuyN6Ry0j1ygRbU=.03460775-b14f-4637-b1db-0b97dc82c956@github.com>
 <VBgN2UNYWYD1VoUqcP3ot8S9GfieeBoY8mcZ6Eb-CXg=.05b520dc-2117-4f80-b8b3-1b7fb1dd3d01@github.com>
Message-ID: <M3MClvagid7CRa4PgHoXurDBJaRfaMe9LAiy0sFOvwg=.afff0cb1-a201-469f-93bd-b5d20b0f5cc2@github.com>

On Thu, 22 Jun 2023 04:53:21 GMT, Tejesh R <tr at openjdk.org> wrote:

> Ok, in summary there exists 2 major issues:

Yes.

> 1. The text should positioned till the blue-ish pixels is just behind the header border for each header cell.

Let's focus on this one here. Position the text so that it touches the shadow line of the header, the add the 2-pixel margin on the right just like it's done for other sides.

> 2. The header border to be aligned with data grid lines.

There have been a few instances where border rendering is fixed by removing the scale transform. The same can be done here. If we go for it, it's better to do it separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1602534514


From jwaters at openjdk.org  Thu Jun 22 13:52:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 13:52:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
Message-ID: <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>

On Thu, 22 Jun 2023 10:37:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Revert NULL to nullptr changes in jaccesswalker
>
> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:
> 
>> 545:         snprintf( s, sizeof(s),
>> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
>> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );
> 
> do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.

gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238560245


From psadhukhan at openjdk.org  Thu Jun 22 14:01:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Jun 2023 14:01:31 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.
Message-ID: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>

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.

-------------

Commit messages:
 - Test fix
 - 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.
 - 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/14614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8166900
  Stats: 105 lines in 2 files changed: 104 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14614/head:pull/14614

PR: https://git.openjdk.org/jdk/pull/14614


From djelinski at openjdk.org  Thu Jun 22 14:08:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:08:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
Message-ID: <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>

On Thu, 22 Jun 2023 13:48:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:
>> 
>>> 545:         snprintf( s, sizeof(s),
>>> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
>>> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );
>> 
>> do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.
>
> gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately

Which gcc? This code compiles without warnings:

#include <stdio.h>
int main() {
	unsigned long i = 1;
	long j = 2;
	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
	return 0;
}


# gcc -Wall -Wextra -Wformat=2 test.c
# gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238581381


From jwaters at openjdk.org  Thu Jun 22 14:08:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:08:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
Message-ID: <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>

On Thu, 22 Jun 2023 14:03:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately
>
> Which gcc? This code compiles without warnings:
> 
> #include <stdio.h>
> int main() {
> 	unsigned long i = 1;
> 	long j = 2;
> 	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
> 	return 0;
> }
> 
> 
> # gcc -Wall -Wextra -Wformat=2 test.c
> # gcc --version
> gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm currently running version 13.1, win32 threads

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238583171


From jwaters at openjdk.org  Thu Jun 22 14:08:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:08:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
 <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
Message-ID: <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>

On Thu, 22 Jun 2023 14:04:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Which gcc? This code compiles without warnings:
>> 
>> #include <stdio.h>
>> int main() {
>> 	unsigned long i = 1;
>> 	long j = 2;
>> 	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
>> 	return 0;
>> }
>> 
>> 
>> # gcc -Wall -Wextra -Wformat=2 test.c
>> # gcc --version
>> gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
>> Copyright (C) 2019 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I'm currently running version 13.1, win32 threads

I'll retry again, maybe the warning has changed now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238583800


From jwaters at openjdk.org  Thu Jun 22 14:16:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:16:28 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v7]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert Cast

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/a31e52e9..775a3b05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From jwaters at openjdk.org  Thu Jun 22 14:16:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:16:29 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
 <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
 <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>
Message-ID: <SnWV2q5q5U2G1iTIwBbr3r35BiGG-8fR9Q1uS_SE2vg=.c222531c-9c48-424b-8ecc-ebb023fcb904@github.com>

On Thu, 22 Jun 2023 14:05:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm currently running version 13.1, win32 threads
>
> I'll retry again, maybe the warning has changed now

Seems like it doesn't trigger any longer, I'll revert the cast. Thanks for catching this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238589176


From alanb at openjdk.org  Thu Jun 22 14:23:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:23:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

src/java.sql/share/classes/java/sql/DriverManager.java line 658:

> 656:          * (which is invoking this class indirectly)
> 657:          * classloader, so that the JDBC driver class outside the image
> 658:          * can be loaded from here.

This code should probably be changed to use VM.isSystemDomainLoader(callerCL).

I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:

"If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238604300


From jwaters at openjdk.org  Thu Jun 22 14:23:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:23:25 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v8]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  GetDIBits should take an LPVOID

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/775a3b05..7dbe5dea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From jwaters at openjdk.org  Thu Jun 22 14:23:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:23:27 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v7]
In-Reply-To: <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>
Message-ID: <hMZxQx2zyEyh5uT7Na5_ooQMJ_TSvyIy0MRQH8h-rGM=.1e352c44-f11d-4e18-984c-cf5725b20daf@github.com>

On Thu, 22 Jun 2023 14:16:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Cast

Alright, I've addressed the issues brought up by the reviews, including the GetDIBits cast. In general I left everything that passes into a Java call at least once as a jint, and everything else as a native type

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1602725175


From djelinski at openjdk.org  Thu Jun 22 14:32:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:32:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v8]
In-Reply-To: <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>
Message-ID: <XXA-qyko6Oj0RyHl-zp3zJodEfFZn8WZW8t2_g1aVRg=.96b142e9-cada-434b-98ee-076c7589fd07@github.com>

On Thu, 22 Jun 2023 14:23:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GetDIBits should take an LPVOID

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:

> 1087:                 entry_point();
> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, (LPVOID) colorBits, &bmi, DIB_RGB_COLORS);

I don't believe casting to LPVOID was what @prrace was asking here.
The function takes a void* parameter because any other pointer type is implicitly convertible to that. We are using long/int/jint because we're asking for 32 bits per pixel (see biBitCount above); if we asked for 24/16/8/any other number of bits per pixel, we would have used a different pointer type.
Please revert these casts. They don't add any value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238616005


From jwaters at openjdk.org  Thu Jun 22 14:40:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:40:23 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert "GetDIBits should take an LPVOID"
  
  This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/7dbe5dea..84f8e08c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From djelinski at openjdk.org  Thu Jun 22 14:53:05 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:53:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <wL5gSu6BhEJorAIL9VTMsCTXIaenQPD51DI4pIZ_7SY=.5af8adb8-ffd1-4742-ab40-cbe933b19311@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Thanks. The code changes look good to me now. Some of the files have old copyright, please update them to 2023 before integrating.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1493384042


From jwaters at openjdk.org  Thu Jun 22 15:12:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 15:12:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <WpbJshChwxooyzyQykysrl0zQGDPT5TuylUn8N4gCB8=.d792b7f7-2632-4bfd-a221-e08e250a5d50@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Will do, thanks Daniel
@prrace @dholmes-ora Are both of you happy with the changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1602811926


From kizune at openjdk.org  Thu Jun 22 15:45:02 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 Jun 2023 15:45:02 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <G430rhVa2s6Kkv0JfvlWW-1FK74OQoNS2qHPVzF16g8=.8ed91d89-a2fe-40eb-add0-5f5568e1779f@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
 <G430rhVa2s6Kkv0JfvlWW-1FK74OQoNS2qHPVzF16g8=.8ed91d89-a2fe-40eb-add0-5f5568e1779f@github.com>
Message-ID: <KFpm_KL-1dUjuCkw54ZH3ZtTqPhca2D_X8yI_jFQxMg=.c38ed619-b047-4feb-bbf5-728373d7a5cb@github.com>

On Thu, 22 Jun 2023 05:27:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Should VO announce radiobutton's position also?

That is beyond the scope of this bug but overall i would look at the native applications with the same type of controls. If native controls do not demonstrate the same behavior then i would say that it is not a problem on our side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14605#issuecomment-1602867619


From abhiscxk at openjdk.org  Thu Jun 22 16:04:03 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Jun 2023 16:04:03 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <YrrjpWlMfrVyO48iSs98faNc6OqCHNkFH53KnW7F130=.63a540a0-fa09-4959-aeb1-0cb5fc97b1f3@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

Marked as reviewed by abhiscxk (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14605#pullrequestreview-1493554726


From abhiscxk at openjdk.org  Thu Jun 22 16:04:04 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Jun 2023 16:04:04 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <KFpm_KL-1dUjuCkw54ZH3ZtTqPhca2D_X8yI_jFQxMg=.c38ed619-b047-4feb-bbf5-728373d7a5cb@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
 <G430rhVa2s6Kkv0JfvlWW-1FK74OQoNS2qHPVzF16g8=.8ed91d89-a2fe-40eb-add0-5f5568e1779f@github.com>
 <KFpm_KL-1dUjuCkw54ZH3ZtTqPhca2D_X8yI_jFQxMg=.c38ed619-b047-4feb-bbf5-728373d7a5cb@github.com>
Message-ID: <AcALNr3yJzjoB76OXdZYmngmxg7FiN_cBPIekTcijhY=.cf4aee8a-3353-483c-9d22-23a961d7b3ed@github.com>

On Thu, 22 Jun 2023 15:41:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Should VO announce radiobutton's position also?
> 
> That is beyond the scope of this bug but overall i would look at the native applications with the same type of controls. If native controls do not demonstrate the same behavior then i would say that it is not a problem on our side.

I checked in native application (i.e. system settings -> appearance) where radio buttons are announced with it's position along with label.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14605#issuecomment-1602920535


From asemenov at openjdk.org  Thu Jun 22 17:25:10 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <e_CKdXAilBPQu8gZ3d6XcuvG-5B7XGl6fb5gSevUjlw=.d286a23d-f504-454d-9611-7c6eb8c64084@github.com>

On Thu, 22 Jun 2023 09:58:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:
> 
>> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
>> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \
> 
> move this one closer to the other clang (non-aix) suppressions

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238824459


From asemenov at openjdk.org  Thu Jun 22 17:25:08 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:08 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v7]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <YFU72ByH9nRD1kcivWlr-gj7NifaytNn1zaYiCPJ7w4=.f751154b-aedc-4dfa-98b9-3c07b3027bf2@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/842d33d8..c4ca2205

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033


From serb at openjdk.org  Thu Jun 22 18:39:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Jun 2023 18:39:10 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v7]
In-Reply-To: <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
 <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>
Message-ID: <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>

On Fri, 16 Jun 2023 08:09:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Window.java line 3223:
>> 
>>> 3221:                     getDefaultScreenDevice().
>>> 3222:                     getDefaultConfiguration();
>>> 3223:         }
>> 
>> It looks like `gc` was always not null before the fix, which is no longer true after the fix.
>> We need to double check that we didn't break anything in this regard.
>
> Yeah, have tested in CI multiple time and also few manual dual screen related test. No regression found with fix.

We have a couple of places where we call "setGraphicsConfiguration(null)", previously that sets the default GC, now it will set the null, can we try to trigger that codepath and check how it will work?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1238899212


From asemenov at openjdk.org  Thu Jun 22 18:50:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 18:50:04 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <EsL2_7-hiitJ2Lg5uyOnl6gZCTLMwuCxbRBBndmjZP4=.2a29f721-c88a-4d70-b077-e8922bc072eb@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

Is it possible to add a regression test on these components?
to ```test/jdk/java/awt/a11y```

---

@NikitkoCent please review

-------------

PR Review: https://git.openjdk.org/jdk/pull/14605#pullrequestreview-1493810756


From serb at openjdk.org  Thu Jun 22 18:50:05 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Jun 2023 18:50:05 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <eyuFn99W3ORH33YI7O49d-TZoESr6HjlLen25WmSLu0=.70c26745-e468-4175-90d7-e65072c94775@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 185:

> 183:                     // Do send check box state changes to native side
> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
> 185:                         if (newValue != null && !newValue.equals(oldValue)) {

Is it possible to have "newValue == null" and the "oldValue != null"? Do we need to update the native in this case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14605#discussion_r1238907239


From kizune at openjdk.org  Thu Jun 22 18:50:06 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 Jun 2023 18:50:06 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <eyuFn99W3ORH33YI7O49d-TZoESr6HjlLen25WmSLu0=.70c26745-e468-4175-90d7-e65072c94775@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
 <eyuFn99W3ORH33YI7O49d-TZoESr6HjlLen25WmSLu0=.70c26745-e468-4175-90d7-e65072c94775@github.com>
Message-ID: <yGyXkYIFR8fqdPq7xC0HbPpCBnNfMie-1pX_CAgt18w=.4f254696-a62b-4b01-a278-9eaffe626cb2@github.com>

On Thu, 22 Jun 2023 18:44:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
>> Also updating the copyright year.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 185:
> 
>> 183:                     // Do send check box state changes to native side
>> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
>> 185:                         if (newValue != null && !newValue.equals(oldValue)) {
> 
> Is it possible to have "newValue == null" and the "oldValue != null"? Do we need to update the native in this case?

No. Null value is not a correct value to be set for these types of control so if null is passed then it is not a real value update event.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14605#discussion_r1238908558


From asemenov at openjdk.org  Thu Jun 22 19:09:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 19:09:05 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
Message-ID: <vbh6mKOn_6zWUzytYK2x4lThvgYBSepCWSKTCZAEq9c=.431df4bc-fb53-4fe3-b7e1-648b858b68b3@github.com>

On Mon, 19 Jun 2023 09:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by asemenov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1493837264


From asemenov at openjdk.org  Thu Jun 22 19:09:07 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 19:09:07 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <rnBh_hyNhnLD28NHwRt6IL7_HLIyNK8h7V2U4lEGvz4=.3daaf06a-db43-4ab4-b9ab-381a12b0cb45@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <rnBh_hyNhnLD28NHwRt6IL7_HLIyNK8h7V2U4lEGvz4=.3daaf06a-db43-4ab4-b9ab-381a12b0cb45@github.com>
Message-ID: <FTY9awfbZGnkZBWaADnfWX63MNe0CL_LEWmVtUPFfJU=.bed40fe8-bd89-43f3-b89d-a05063a9ec62@github.com>

On Mon, 19 Jun 2023 08:41:48 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 162:
>> 
>>> 160:             AccessibleContext ac = this.getAccessibleContext();
>>> 161:             if (ac != null && (comboBox.getSelectedItem() != null)) {
>>> 162:                 ac.setAccessibleName(comboBox.getSelectedItem().toString());
>> 
>> Why are you using the currently selected element for the button name and not a specific name? Whether it will sound right when using a screen reader. Wouldn't this be misleading to a blind user? Especially since it will only change when this method is called.
>
>> Why are you using the currently selected element for the button name and not a specific name?
> 
> As it is required to show the magnified text for the selected item in JComboBox. Setting it to some specific name always results into that name irrespective of selected item in JCombobox.
> 
>> Whether it will sound right when using a screen reader. Wouldn't this be misleading to a blind user?
> 
> I checked with VO announcement with or without this chunk of code, it is same in both case. 
> 
>> Especially since it will only change when this method is called.
> 
> This method is called whenever the current selection is changed so accessible name is set to correct item.

JSON with enumeration of fields is also a text description of the object.
But if you checked that there is no garbage, then good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1238924746


From prr at openjdk.org  Thu Jun 22 20:00:05 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 Jun 2023 20:00:05 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <Q85NoXAjM62hQl-20oY9whbiu5RWNi31dxnivc-57e0=.bd51a6a2-fdc4-4322-afd2-da2205ba5086@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14605#pullrequestreview-1493905819


From aivanov at openjdk.org  Thu Jun 22 20:08:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Looks fine to me, except for a few comments.

The size of the types for `jint` and `jlong` remains the same after amending the typedef `jni_md.h`. Yet I'm still cautious about it. You should have an approval from hotspot.

Please also update the copyright year in the modified files.

src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325:

> 323:     }
> 324: 
> 325:     jint sx, sy, ex, ey;

I agree with David, these should have type `int` as accepted by the [`::Arc`](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-arc) function. However, the `AngleToCoord` function is declared with `jint` as parameters.

https://github.com/openjdk/jdk/blob/84f8e08c2ecc90ec50a13406fb99b8cd52f33b7c/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp#L52

Its declaration can be changed to `int`, it's an internal function used by `*_doDrawArc` and `*_doFillArc`.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:

> 1082: 
> 1083:             jint *colorBits = nullptr;
> 1084:             int *maskBits = nullptr;

Suggestion:

            jint *colorBits = NULL;
            int *maskBits = NULL;

I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.

src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:

> 146: }
> 147: 
> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)

What is the reason for using `jint` instead of `int`?

The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1493854643
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238938194
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238948758
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238966069


From aivanov at openjdk.org  Thu Jun 22 20:08:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
Message-ID: <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>

On Thu, 25 May 2023 01:30:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605:
> 
>> 603:         return;
>> 604:     }
>> 605:     jint sx, sy, ex, ey;
> 
> Again these don't seem to need to be Java types.

I've got the same concern.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238941743


From aivanov at openjdk.org  Thu Jun 22 20:08:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>

On Thu, 22 Jun 2023 19:33:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:
> 
>> 1082: 
>> 1083:             jint *colorBits = nullptr;
>> 1084:             int *maskBits = nullptr;
> 
> Suggestion:
> 
>             jint *colorBits = NULL;
>             int *maskBits = NULL;
> 
> I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.

The type of `colorBits` is `jint` because it's set to `iconBits` array, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238952370


From kizune at openjdk.org  Thu Jun 22 20:29:07 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 Jun 2023 20:29:07 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <EsL2_7-hiitJ2Lg5uyOnl6gZCTLMwuCxbRBBndmjZP4=.2a29f721-c88a-4d70-b077-e8922bc072eb@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
 <EsL2_7-hiitJ2Lg5uyOnl6gZCTLMwuCxbRBBndmjZP4=.2a29f721-c88a-4d70-b077-e8922bc072eb@github.com>
Message-ID: <G4dQEm_TAJUpWoCPeQuXaRTd4fZnzlFuZslMUxFY2Pw=.ed58e81a-06a6-4f8a-9f03-4508006e1514@github.com>

On Thu, 22 Jun 2023 18:46:51 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Is it possible to add a regression test on these components? to `test/jdk/java/awt/a11y`

Not within this regression type fix unless i find a way to write an automatic regression test which i don't see a way of. As of creating a comprehensive test or set of tests that covers all of these components - that might be a separate task. But again it is outside of this fix scope.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14605#issuecomment-1603271286


From aivanov at openjdk.org  Thu Jun 22 20:35:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:35:07 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <91ouxxaBSGiyRjhEgiYi5R7UzCg0DW7KAWd9ba0LgSc=.668aaab0-6b4f-49f4-b13a-1f7949f572ab@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <91ouxxaBSGiyRjhEgiYi5R7UzCg0DW7KAWd9ba0LgSc=.668aaab0-6b4f-49f4-b13a-1f7949f572ab@github.com>
Message-ID: <32HxLWkkzUx4baOp_oYbXLgsr4jKENWVv1UOOBpwIMk=.b8f8ba1a-907b-4713-8859-df5bc6812773@github.com>

On Thu, 22 Jun 2023 03:35:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It can be removed in the strict sense but we need something to initialise it to so kept it as it is, as it will do no harm

Why does it need anything to initialise? The value is now set in either `if` or `else` branch.

It does not harm, yet it's never used. Not initialising it with `"InternalFrame.titleButtonWidth"` conveys it clearer: the value is computed later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1238998191


From aivanov at openjdk.org  Thu Jun 22 20:35:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:35:05 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <3wO7IHa33io5uuqXst2Rh1j1Dr-F7SMk_JTtyScJT6Q=.dd397bba-28a6-49a4-9763-edcfacdd92c1@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <3wO7IHa33io5uuqXst2Rh1j1Dr-F7SMk_JTtyScJT6Q=.dd397bba-28a6-49a4-9763-edcfacdd92c1@github.com>
Message-ID: <nxlaajXLdMNfM1yEfDa6ladUILYAETw7ncKEnasHobw=.b3ba4f8b-c887-406c-b066-51570d2c2eb2@github.com>

On Thu, 22 Jun 2023 03:44:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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

We have exactly the same code in both `WindowsIconFactory.java` and `WindowsInternalFrameTitlePane.java`. Can it moved into a helper method to avoid duplication?

Would be enough to have it in `WindowsIconFactory.java` only?

Can `WindowsInternalFrameTitlePane.java` rely on the value set to UI Manager?

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 297:

> 295:                 }
> 296:             } else {
> 297:                 width = UIManager.getInt("InternalFrame.titleButtonHeight") - 2;

Suggestion:

                width = UIManager.getInt("InternalFrame.titleButtonHeight") -2;

I agree it looks better with the space on either side but it's consistently used without the space after `-`. So I'd rather keep the original formatting.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1493939458
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1238992267


From aivanov at openjdk.org  Thu Jun 22 20:38:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:38:02 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v2]
In-Reply-To: <OF96hbG6CbEnCFCshbeEyZ06flhhp4su8PcHDIdXUn8=.36974c6f-10e7-480a-9cde-38d26db11163@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>
 <OF96hbG6CbEnCFCshbeEyZ06flhhp4su8PcHDIdXUn8=.36974c6f-10e7-480a-9cde-38d26db11163@github.com>
Message-ID: <SwVlAuFPqsIB_YmjtXu-25NB3PjgtCEdlYrfSTvd7zs=.72f5d340-019a-4021-84d8-26fc98027c11@github.com>

On Thu, 22 Jun 2023 03:39:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > I wonder if the values stored in the UI Manager should have this trick applied rather tweaking the values on the fly. If a programmer gets the values from `UIManager` directly, they will get the incorrect value.
> 
> OK. UIManager is also updated with updated width so values will be identical

Can it be modified so that the value for `"InternalFrame.titleButtonWidth"` gets computed based on `"InternalFrame.titleButtonHeight"` using the algorithm in `WindowsIconFactory.java` and `WindowsInternalFrameTitlePane.java` when its value is requested?

This way UIManager automatically returns the value we want; the adjustment logic can be dropped from both classes above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1603282478


From aivanov at openjdk.org  Thu Jun 22 20:48:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:48:05 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <yGyXkYIFR8fqdPq7xC0HbPpCBnNfMie-1pX_CAgt18w=.4f254696-a62b-4b01-a278-9eaffe626cb2@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
 <eyuFn99W3ORH33YI7O49d-TZoESr6HjlLen25WmSLu0=.70c26745-e468-4175-90d7-e65072c94775@github.com>
 <yGyXkYIFR8fqdPq7xC0HbPpCBnNfMie-1pX_CAgt18w=.4f254696-a62b-4b01-a278-9eaffe626cb2@github.com>
Message-ID: <DUip7pgzwU13tLmv2L6RPv-F1i9GBLlMP_hweeB2T1Y=.f0f9395f-f63f-4d83-a583-d3ef17000781@github.com>

On Thu, 22 Jun 2023 18:45:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 185:
>> 
>>> 183:                     // Do send check box state changes to native side
>>> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
>>> 185:                         if (newValue != null && !newValue.equals(oldValue)) {
>> 
>> Is it possible to have "newValue == null" and the "oldValue != null"? Do we need to update the native in this case?
>
> No. Null value is not a correct value to be set for these types of control so if null is passed then it is not a real value update event.

[`Objects.equals`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Objects.html#equals(java.lang.Object,java.lang.Object)) can be used to avoid null-check, it handles `null` values gracefully.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14605#discussion_r1239014266


From serb at openjdk.org  Thu Jun 22 21:18:05 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Jun 2023 21:18:05 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <1ojBlIt9pjdn1dLozmp0sHT86zmzKu20_fju9ydf1hM=.0d0cb7a2-d4de-47db-8f55-846805425330@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14605#pullrequestreview-1494007969


From serb at openjdk.org  Thu Jun 22 21:21:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Jun 2023 21:21: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.
In-Reply-To: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
References: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
Message-ID: <IoxJ_dP6pAGnE1tpnxgYTUMfnAJXpNlReWUvggDf4Sw=.58548f38-5b8b-4fac-bbfe-5519be71b92e@github.com>

On Thu, 22 Jun 2023 13:47:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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.

test/jdk/javax/swing/JTable/JLayerTableTest.java line 57:

> 55:             @Override public int getRowCount() {return 100;}
> 56:             @Override public int getColumnCount() {return 3;}
> 57:             @Override public Object getValueAt(int row, int column) {return "(" + row + "," + column + ")";}

Please split the long lines to have 80 chars.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14614#discussion_r1239039647


From serb at openjdk.org  Thu Jun 22 21:35:13 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Jun 2023 21:35:13 GMT
Subject: RFR: 8310054: ScrollPane insets are incorrect
In-Reply-To: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
References: <U2iPttYm1enAVr5KSslNB12wIcFDtcS6ggTHPiQh5VI=.747c4644-d28a-405c-a1b9-b417ea6727a3@github.com>
Message-ID: <Rytf_H4a6Z4B4YiRopCT0DDwnI42uuT6JSEm-qWycWw=.99ada11b-a37a-439b-9b6a-25b7ab8b7ed5@github.com>

On Wed, 14 Jun 2023 20:17:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After the size of `ScrollPane` child component changes, it recalculates the size of the scroll bars and hides or shows them as necessary. This situation is handled in `WScrollPanePeer.childResized`:
> 
> https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L104-L109
> 
> After [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923), `setSpans` is run asynchronously on the toolkit thread. Thus, `setInsets` calculates the incorrect values because `setSpans` hasn't updated the sizes yet.
> 
> This is a regression from [JDK-8297923](https://bugs.openjdk.org/browse/JDK-8297923).
> 
> **Fix**
> 
> The insets are updated in the native implementation of `setSpans` directly.
> 
> The native implementation of `setInsets` method is run on the toolkit thread as a synchronous call because the insets are used in [`WScrollPanePeer.initialize`](https://github.com/openjdk/jdk/blob/ee4ab6709ebaf8a1b1e9f297a7c53205987f3eba/src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java#L62-L67).

src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp line 528:

> 526:         s->RecalcSizes(parentWidth, parentHeight, childWidth, childHeight);
> 527:         s->VerifyState();
> 528:         s->SetInsets(env);

I guess we should call "s->VerifyState();" after the "s->SetInsets(env);" similar to what we do in the "AwtScrollPane::_SetInsets"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14478#discussion_r1239049983


From jwaters at openjdk.org  Fri Jun 23 00:16:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
 <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>
Message-ID: <f4yYWXUYsev-Ftn2ESAWjF1QXnW8K2pmL204ZkFcoIo=.492c1ac4-6190-4774-afcc-6aa272534c5d@github.com>

On Thu, 22 Jun 2023 19:37:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:
>> 
>>> 1082: 
>>> 1083:             jint *colorBits = nullptr;
>>> 1084:             int *maskBits = nullptr;
>> 
>> Suggestion:
>> 
>>             jint *colorBits = NULL;
>>             int *maskBits = NULL;
>> 
>> I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.
>
> The type of `colorBits` is `jint` because it's set to `iconBits` array, right?

Yes, colorBits is a jint because of that

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239143202


From jwaters at openjdk.org  Fri Jun 23 00:16:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <SEwBNPhlLxpGAitn9_yJHWn49VLebp4u12GgCuA2nJo=.21af475d-a44a-4c54-8a50-fbfda5e8bf28@github.com>

On Thu, 22 Jun 2023 19:20:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325:
> 
>> 323:     }
>> 324: 
>> 325:     jint sx, sy, ex, ey;
> 
> I agree with David, these should have type `int` as accepted by the [`::Arc`](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-arc) function. However, the `AngleToCoord` function is declared with `jint` as parameters.
> 
> https://github.com/openjdk/jdk/blob/84f8e08c2ecc90ec50a13406fb99b8cd52f33b7c/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp#L52
> 
> Its declaration can be changed to `int`, it's an internal function used by `*_doDrawArc` and `*_doFillArc`.

Resolved, will push soon

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239142969


From jwaters at openjdk.org  Fri Jun 23 00:16:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
 <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>
Message-ID: <9RJ8-w0M5_3QeoXfshnOhtwVvi7g89XaOH35RTFKIZg=.8b19b043-0b16-4f28-a124-22ee2e644940@github.com>

On Thu, 22 Jun 2023 19:24:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605:
>> 
>>> 603:         return;
>>> 604:     }
>>> 605:     jint sx, sy, ex, ey;
>> 
>> Again these don't seem to need to be Java types.
>
> I've got the same concern.

Resolved, pushing soon

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239143080


From jwaters at openjdk.org  Fri Jun 23 00:19:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:19:18 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>

On Thu, 22 Jun 2023 19:51:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:
> 
>> 146: }
>> 147: 
>> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)
> 
> What is the reason for using `jint` instead of `int`?
> 
> The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.

I had it as a jint since it upcalls into Java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239144537


From jwaters at openjdk.org  Fri Jun 23 00:31:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:31:28 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Fixups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/84f8e08c..80b6f787

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=08-09

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From dholmes at openjdk.org  Fri Jun 23 02:08:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Jun 2023 02:08:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
Message-ID: <uXV4ZGxEPEhLn8yhnI7PmiPWgm9pSOpouoSIXyq2enQ=.617f49c8-4ba0-4e61-9775-58702fbb1ed0@github.com>

On Fri, 23 Jun 2023 00:31:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

Hotspot changes still approved.

Other changes seem okay to me.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1494291399


From jwaters at openjdk.org  Fri Jun 23 02:12:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:12:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
Message-ID: <v8-gfGamUHAsZgiQ8bo2lEVlI2pF8KeVfCdY0qrkjqQ=.4df0a245-cefa-4be8-ab16-990039ae0c9d@github.com>

On Fri, 23 Jun 2023 00:31:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

Alright, I'll integrate once Alexsey approve, anyone else has further objections?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1603594332


From jwaters at openjdk.org  Fri Jun 23 02:38:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:38:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Revert wrong Copyright
 - Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/80b6f787..16b5a914

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=09-10

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From psadhukhan at openjdk.org  Fri Jun 23 03:14:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 03:14:21 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: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
References: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
Message-ID: <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14614/files
  - new: https://git.openjdk.org/jdk/pull/14614/files/b74f36ab..92d46d26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14614&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14614/head:pull/14614

PR: https://git.openjdk.org/jdk/pull/14614


From psadhukhan at openjdk.org  Fri Jun 23 03:14:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 03:14:24 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: <IoxJ_dP6pAGnE1tpnxgYTUMfnAJXpNlReWUvggDf4Sw=.58548f38-5b8b-4fac-bbfe-5519be71b92e@github.com>
References: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
 <IoxJ_dP6pAGnE1tpnxgYTUMfnAJXpNlReWUvggDf4Sw=.58548f38-5b8b-4fac-bbfe-5519be71b92e@github.com>
Message-ID: <9eHcL-CFhArb6eQpu5PrlmJvPg_th8E77m44amkznXE=.813e81ac-9b10-4c42-8d83-e791e4ac9aee@github.com>

On Thu, 22 Jun 2023 21:17:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Formatting
>
> test/jdk/javax/swing/JTable/JLayerTableTest.java line 57:
> 
>> 55:             @Override public int getRowCount() {return 100;}
>> 56:             @Override public int getColumnCount() {return 3;}
>> 57:             @Override public Object getValueAt(int row, int column) {return "(" + row + "," + column + ")";}
> 
> Please split the long lines to have 80 chars.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14614#discussion_r1239274682


From psadhukhan at openjdk.org  Fri Jun 23 03:31:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 03:31:01 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v3]
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <ucnn5ZxmS0i5hqx7U9Afsw9N9Rtc1icYgd-cfxMROUI=.d8d2b888-8198-4c4e-a701-3842d1568067@github.com>

> 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 comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14555/files
  - new: https://git.openjdk.org/jdk/pull/14555/files/f8467953..ffac5500

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 1 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 psadhukhan at openjdk.org  Fri Jun 23 03:31:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 03:31:01 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v3]
In-Reply-To: <32HxLWkkzUx4baOp_oYbXLgsr4jKENWVv1UOOBpwIMk=.b8f8ba1a-907b-4713-8859-df5bc6812773@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <91ouxxaBSGiyRjhEgiYi5R7UzCg0DW7KAWd9ba0LgSc=.668aaab0-6b4f-49f4-b13a-1f7949f572ab@github.com>
 <32HxLWkkzUx4baOp_oYbXLgsr4jKENWVv1UOOBpwIMk=.b8f8ba1a-907b-4713-8859-df5bc6812773@github.com>
Message-ID: <bBrNlg3-X_yimxCZ0V8fOgYtLmg7XZBAXFhmkcRiqT4=.5ed673c0-3285-4d21-83ee-c0d15cabc90c@github.com>

On Thu, 22 Jun 2023 20:27:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It can be removed in the strict sense but we need something to initialise it to so kept it as it is, as it will do no harm
>
>> It can be removed in the strict sense but we need something to initialise it to so kept it as it is, as it will do no harm
> 
> Why does it need anything to initialise? The value is now set in either `if` or `else` branch.
> 
> It does not harm, yet it's never used. Not initialising it with `"InternalFrame.titleButtonWidth"` conveys it clearer: the value is computed later.

ok. I thought buttonWidth was declared in the method but it is class variable

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1239283097


From psadhukhan at openjdk.org  Fri Jun 23 03:58:02 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 03:58:02 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v3]
In-Reply-To: <SwVlAuFPqsIB_YmjtXu-25NB3PjgtCEdlYrfSTvd7zs=.72f5d340-019a-4021-84d8-26fc98027c11@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>
 <OF96hbG6CbEnCFCshbeEyZ06flhhp4su8PcHDIdXUn8=.36974c6f-10e7-480a-9cde-38d26db11163@github.com>
 <SwVlAuFPqsIB_YmjtXu-25NB3PjgtCEdlYrfSTvd7zs=.72f5d340-019a-4021-84d8-26fc98027c11@github.com>
Message-ID: <0JcnnISB-p-DMmMDjKHveYPWejEzl-TNVmFVO5Exvpo=.1579b1f1-2bf0-404e-9efc-f85557349a43@github.com>

On Thu, 22 Jun 2023 20:35:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > I wonder if the values stored in the UI Manager should have this trick applied rather tweaking the values on the fly. If a programmer gets the values from `UIManager` directly, they will get the incorrect value.
> > 
> > 
> > OK. UIManager is also updated with updated width so values will be identical
> 
> Can it be modified so that the value for `"InternalFrame.titleButtonWidth"` gets computed based on `"InternalFrame.titleButtonHeight"` using the algorithm in `WindowsIconFactory.java` and `WindowsInternalFrameTitlePane.java` when its value is requested?
> 
> This way UIManager automatically returns the value we want; the adjustment logic can be dropped from both classes above.

We probably can change in [WindowsLookAndFeel](https://github.com/openjdk/jdk/blob/5a82fa3bb278b5b80b9ede0619f364fe13cdbede/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#L813-L814) 
but for XPtheme `width = height-4` and for ClassicTheme `width = height-2` so we need `getXP ` check so I will prefer to keep it as it is as otherwise it might create regression and also I could not find anyway to access WIndowsInternalFrameTitlePane methods in WindowsIconFactory to avoid duplication..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1603647188


From tr at openjdk.org  Fri Jun 23 04:55:11 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 Jun 2023 04:55:11 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v7]
In-Reply-To: <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
 <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>
 <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>
Message-ID: <6aqWaUnWlba58kSQ5odysb7lAI4jp-rwz9cQcgrMW3g=.1f9b1efc-7e48-4ac8-a235-1f75d492a17f@github.com>

On Thu, 22 Jun 2023 18:36:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yeah, have tested in CI multiple time and also few manual dual screen related test. No regression found with fix.
>
> We have a couple of places where we call "setGraphicsConfiguration(null)", previously that sets the default GC, now it will set the null, can we try to trigger that codepath and check how it will work?

Removing a Component will call `Component.setGraphicsConfiguration()`, which in turn triggers `Component.updateGraphicsData()`. So `setGraphicsConfiguration(null)` never invoked `Window.setGraphicsConfiguration()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1239318085


From tr at openjdk.org  Fri Jun 23 05:16:09 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 Jun 2023 05:16:09 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v7]
In-Reply-To: <6aqWaUnWlba58kSQ5odysb7lAI4jp-rwz9cQcgrMW3g=.1f9b1efc-7e48-4ac8-a235-1f75d492a17f@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
 <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>
 <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>
 <6aqWaUnWlba58kSQ5odysb7lAI4jp-rwz9cQcgrMW3g=.1f9b1efc-7e48-4ac8-a235-1f75d492a17f@github.com>
Message-ID: <r8502FRjkQ5fI-QHb923T9ueUaUpNzFkfxU0BwKRzv8=.82ecb44d-b3f8-48a3-a46e-1af6ce117068@github.com>

On Fri, 23 Jun 2023 04:52:45 GMT, Tejesh R <tr at openjdk.org> wrote:

>> We have a couple of places where we call "setGraphicsConfiguration(null)", previously that sets the default GC, now it will set the null, can we try to trigger that codepath and check how it will work?
>
> Removing a Component will call `Component.setGraphicsConfiguration()`, which in turn triggers `Component.updateGraphicsData()`. So `setGraphicsConfiguration(null)` never invoked `Window.setGraphicsConfiguration()`.

Anyhow I have tested the updated code in CI system multiple time, never encountered a failure due to null. As part of precautionary measures, let me retain the old code too, along with updated ones.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1239327196


From mickleness at gmail.com  Fri Jun 23 06:06:03 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Fri, 23 Jun 2023 06:06:03 +0000
Subject: JDK-6196792 Image.getScaledInstance
Message-ID: <emfcc694dd-35fb-4ee5-803b-ce6dd0986f9a@cf4df73f.com>

The performance of Image.getScaledInstance() has been known to be a 
problem for a long time. (This ticket 
<https://bugs.openjdk.org/browse/JDK-6196792> discusses it well. It has 
a complicated history.)

I have developed code 
<https://github.com/mickleness/pumpernickel/wiki/Scaling> that is much 
more performant. It takes less than 10% of the time the 
AreaAveragingScaleFilter does. There?s nothing especially clever about 
it; it just iterates over the pixels more efficiently. Like 
AreaAveragingScaleFilter: it doesn?t suffer degraded appearance 
(pixelation) at less than 50% scale.

Is there any interest in me working on a PR to overhaul 
AreaAveragingScaleFilter? (That is: is there interest in 
reviewing/sponsoring such a PR?) It won?t be a trivial task, but the 
results I have now indicate the performance gains could be significant.

(Or in my wildest of pipe dreams: I?d love it if 
Graphics2D.drawImage(..) could scale images past 50% without looking 
pixelated? but that could be an even more difficult discussion about 
RenderingHints and long-established interpolation norms. So I assume 
that?s a non-starter.)

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230623/a512c035/attachment.htm>

From jwaters at openjdk.org  Fri Jun 23 06:16:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 06:16:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <LdyxdQwGp8-1SV9ljJSo_KQXQVa7Fwaai32DyrfezgI=.8f37a207-a58d-47a3-940a-3d7dcfedac2e@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

Wait a minute, I was right, it was a jint the whole time! Oh well, I'll wait for what @aivanov-jdk has to say, but I don't like the idea of leaving both inconsistent

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1603730539


From djelinski at openjdk.org  Fri Jun 23 06:22:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 06:22:06 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>

On Thu, 22 Jun 2023 09:58:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
> 
>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
> 
> Suggestion:
> 
>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Please remove the extra spaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239364317


From djelinski at openjdk.org  Fri Jun 23 06:13:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 06:13:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
Message-ID: <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>

On Fri, 23 Jun 2023 02:38:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert wrong Copyright
>  - Copyright

src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:

> 74:     /*for multifont menu */
> 75:     BOOL IsTopMenu();
> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);

Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239358334


From rmahajan at openjdk.org  Fri Jun 23 06:30:17 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 23 Jun 2023 06:30:17 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v16]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <4QvFHNeq5BZTf43MPzANyfE-Gt3P0aVN89X8j-8zbEs=.1cbacddf-dae5-4c3b-a32e-46881dcf9200@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
> Also tested with SwingSet2 .
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  minor edits to variable names and code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/517b1243..4d275736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=14-15

  Stats: 27 lines in 1 file changed: 9 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From asemenov at openjdk.org  Fri Jun 23 08:03:45 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:03:45 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/c4ca2205..92f629f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033


From asemenov at openjdk.org  Fri Jun 23 08:09:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:09:05 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
 <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
Message-ID: <uFToDpeYUWFQyhvBB5DMIvAYOdiUDq-KP-R6v64A51g=.361ef91f-3e20-4be7-b63e-f3774cb9128c@github.com>

On Fri, 23 Jun 2023 06:19:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
>> 
>>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>> 
>> Suggestion:
>> 
>>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>
> Please remove the extra spaces.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239506015


From asemenov at openjdk.org  Fri Jun 23 08:18:03 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:18:03 GMT
Subject: RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <-5Vysuy4IqT0jz792vnQf3TY25uduyXUS0aBH617nF8=.8d7ac78c-4afc-40ab-863d-7e8526532f78@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

LGTM.

-------------

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14605#pullrequestreview-1494678881


From djelinski at openjdk.org  Fri Jun 23 08:27:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 08:27:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
Message-ID: <6Ii3MX8vMTxkr1M6OSPRK1MC3Mird6O_jeC6topuMdU=.e954d902-8b57-40bf-8fd9-9d88b82cd969@github.com>

On Fri, 23 Jun 2023 08:03:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

LGTM

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1494691850


From psadhukhan at openjdk.org  Fri Jun 23 08:41:25 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 08:41:25 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4]
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <KckBcZ2emHE0glhhS4ssH6i2C7Cy_36Cq6ECzYHbMlE=.ffd3b8d2-7a1d-457a-a169-9d4137bda656@github.com>

> 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:

  Fix for JDK-8139392

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14555/files
  - new: https://git.openjdk.org/jdk/pull/14555/files/ffac5500..399d8125

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=02-03

  Stats: 17 lines in 2 files changed: 0 ins; 13 del; 4 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  Fri Jun 23 08:41:40 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2023 08:41:40 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4]
In-Reply-To: <0JcnnISB-p-DMmMDjKHveYPWejEzl-TNVmFVO5Exvpo=.1579b1f1-2bf0-404e-9efc-f85557349a43@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <w5Q5SvHegoito3W_692Vuo-eOfdAGem37mtTFc8sW_w=.578510ab-1b26-4e0f-8bb0-0ce051d62e02@github.com>
 <OF96hbG6CbEnCFCshbeEyZ06flhhp4su8PcHDIdXUn8=.36974c6f-10e7-480a-9cde-38d26db11163@github.com>
 <SwVlAuFPqsIB_YmjtXu-25NB3PjgtCEdlYrfSTvd7zs=.72f5d340-019a-4021-84d8-26fc98027c11@github.com>
 <0JcnnISB-p-DMmMDjKHveYPWejEzl-TNVmFVO5Exvpo=.1579b1f1-2bf0-404e-9efc-f85557349a43@github.com>
Message-ID: <WjIhQU-vBuuNrEwutGT2-aU4o3OEZMokfhi7T7joqrQ=.3327941c-42c1-408c-ab3f-37be67845a76@github.com>

On Fri, 23 Jun 2023 03:55:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > I wonder if the values stored in the UI Manager should have this trick applied rather tweaking the values on the fly. If a programmer gets the values from `UIManager` directly, they will get the incorrect value.
> > > 
> > > 
> > > OK. UIManager is also updated with updated width so values will be identical
> > 
> > 
> > Can it be modified so that the value for `"InternalFrame.titleButtonWidth"` gets computed based on `"InternalFrame.titleButtonHeight"` using the algorithm in `WindowsIconFactory.java` and `WindowsInternalFrameTitlePane.java` when its value is requested?
> > This way UIManager automatically returns the value we want; the adjustment logic can be dropped from both classes above.
> 
> We probably can change in [WindowsLookAndFeel](https://github.com/openjdk/jdk/blob/5a82fa3bb278b5b80b9ede0619f364fe13cdbede/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#L813-L814) but for XPtheme `width = height-4` and for ClassicTheme `width = height-2` so we need `getXP ` check so I will prefer to keep it as it is as otherwise it might create regression and also I could not find anyway to access WIndowsInternalFrameTitlePane methods in WindowsIconFactory to avoid duplication..

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://github.com/openjdk/jdk/assets/43534309/224f098c-5ff5-4713-8434-05d99e7d9a71)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1603936260


From kizune at openjdk.org  Fri Jun 23 10:14:14 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Jun 2023 10:14:14 GMT
Subject: Integrated: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
References: <sVAxnLb2FE82av34bxDUKsRxa0nVlQ1ZHuqtyfTYaqA=.6c80b104-f3de-42ab-b121-69d24a06ffe0@github.com>
Message-ID: <p4okaQDAMVqEwkb78lJY7AVfb6zAycPSHKq8PkFn0-E=.2024a30b-6b6c-44c1-ba1e-4f509776baa4@github.com>

On Wed, 21 Jun 2023 20:37:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only pass value changed event to the native accessibility peer when the value is actually changed. While at fixing it for RadioButton also fixing it for checkbox and toggle button so there is no need to re-visit this file later.
> Also updating the copyright year.

This pull request has now been integrated.

Changeset: d1d2b55c
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1d2b55ce0b950e07f6e3761983f73fd58079627
Stats:     10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8309733: [macOS, Accessibility] VoiceOver: Incorrect announcements of JRadioButton

Reviewed-by: abhiscxk, asemenov, prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/14605


From tr at openjdk.org  Fri Jun 23 10:30:13 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 Jun 2023 10:30:13 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v8]
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <QOehbqnKC74xMRewc16t8ZNoI5DUwiNVKEQNYDJjKUA=.badb96fc-aec7-4c22-b6a4-e95aab7d9d73@github.com>

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Retained GC null check code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14246/files
  - new: https://git.openjdk.org/jdk/pull/14246/files/428d0dd8..9cf33603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14246&range=06-07

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14246/head:pull/14246

PR: https://git.openjdk.org/jdk/pull/14246


From aivanov at openjdk.org  Fri Jun 23 14:27:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:27:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
Message-ID: <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>

On Fri, 23 Jun 2023 06:10:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert wrong Copyright
>>  - Copyright
>
> src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:
> 
>> 74:     /*for multifont menu */
>> 75:     BOOL IsTopMenu();
>> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);
> 
> Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
> https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261

The declaration and implementation have to match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239886709


From aivanov at openjdk.org  Fri Jun 23 14:27:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:27:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
 <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>
Message-ID: <2kn5RYAWrZokkv1fHoUC2FO0fS7Z1R4DQH2ws9Mrw88=.f8d7bd70-1a1c-4421-91d2-5296812b5561@github.com>

On Fri, 23 Jun 2023 00:16:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:
>> 
>>> 146: }
>>> 147: 
>>> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)
>> 
>> What is the reason for using `jint` instead of `int`?
>> 
>> The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.
>
> I had it as a jint since it upcalls into Java

I am fine with either way as long as it compiles without warning and menu works as expected.

I had to ask the question. Which way conveys the intention clearer? I don't know. I incline to using `int` as is in the latest version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239883713


From aivanov at openjdk.org  Fri Jun 23 14:34:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:34:17 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
Message-ID: <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>

On Fri, 23 Jun 2023 14:24:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:
>> 
>>> 74:     /*for multifont menu */
>>> 75:     BOOL IsTopMenu();
>>> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);
>> 
>> Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
>> https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261
>
> The declaration and implementation have to match.

To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.

What do you thing, @djelinski and @TheShermanTanker?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239891473


From jwaters at openjdk.org  Fri Jun 23 14:34:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 14:34:18 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
Message-ID: <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>

On Fri, 23 Jun 2023 14:28:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The declaration and implementation have to match.
>
> To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.
> 
> What do you thing, @djelinski and @TheShermanTanker?

Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239893754


From aivanov at openjdk.org  Fri Jun 23 16:56:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 16:56:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
 <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
Message-ID: <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>

On Fri, 23 Jun 2023 14:30:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.
>> 
>> What do you thing, @djelinski and @TheShermanTanker?
>
> Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code

You're right? it gives a hint it'll be an upcall into Java. Let's go for `jint` then.

I don't think there's a need to change the type of the for-loop variable to `jint`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240041248


From jwaters at openjdk.org  Fri Jun 23 16:59:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 16:59:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
 <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
 <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>
Message-ID: <bdR0sm_lnZmnnl_A9aEYIymH0RH8InYxi8JgcJ2-4zw=.4a44db67-31cd-4ec4-9533-5c9cda88fe14@github.com>

On Fri, 23 Jun 2023 16:53:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code
>
> You're right? it gives a hint it'll be an upcall into Java. Let's go for `jint` then.
> 
> I don't think there's a need to change the type of the for-loop variable to `jint`.

Oh no, I didn't mean to change the loop variable, rather that leaving the jint as is should be fine in the for loop

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240044495


From jwaters at openjdk.org  Fri Jun 23 17:09:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 17:09:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Swap to jint in awt_MenuBar.h
 - Swap to jint in awt_MenuBar.cpp
 - Swap to jint in awt_Menu.h

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/16b5a914..d5f74cc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=10-11

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From jwaters at openjdk.org  Fri Jun 23 17:09:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 17:09:14 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
Message-ID: <6LhofTh1RYX22niDjY1cPgArtX7E5Ghm4880ulFgUmI=.7326b3e2-8dd6-4e49-bf88-c91e4b93bbed@github.com>

On Fri, 23 Jun 2023 02:38:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert wrong Copyright
>  - Copyright

Alright, waiting for you to do the honours :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1604563651


From prr at openjdk.org  Fri Jun 23 17:46:09 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Jun 2023 17:46:09 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows [v2]
In-Reply-To: <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
 <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
Message-ID: <QSXSchndCq3vFWNMdGlRb6neflC9o4_51JXn_oaD-JU=.d8ae76e4-d1d5-48ba-a14d-d5fae94bce62@github.com>

On Tue, 13 Jun 2023 14:10:11 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use malloc instead of fixed size buffers.

So this looks good to me, but I want to run all our automated tests - I don't suppose you did that already ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13359#pullrequestreview-1495600173


From achung at openjdk.org  Fri Jun 23 17:57:16 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 23 Jun 2023 17:57:16 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v5]
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <HAI1IuVPthXgrx1wzJDh1tY_c8_XEcBoSanzhf9fFUM=.9b9252a4-5b88-44c7-ace3-cd9e343e9a5b@github.com>

> 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 suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14226/files
  - new: https://git.openjdk.org/jdk/pull/14226/files/767747a2..eaef82e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14226&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14226&range=03-04

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14226/head:pull/14226

PR: https://git.openjdk.org/jdk/pull/14226


From aivanov at openjdk.org  Fri Jun 23 18:05:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 18:05:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
Message-ID: <IWwjatEYIjQu7eT1_3MBUgza4BTmS0Gbro-ZJfmKQwY=.5eec9d8d-462d-4865-9f6d-347b747af77e@github.com>

On Fri, 23 Jun 2023 17:09:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Swap to jint in awt_MenuBar.h
>  - Swap to jint in awt_MenuBar.cpp
>  - Swap to jint in awt_Menu.h

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1126:

> 1124: 
> 1125:             // Free bitmap buffers if they were allocated
> 1126:             if (colorBits != nullptr) {

Let's revert `nullptr` to `NULL`.

The `NULL` value is used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through out the file, so `nullptr` is out of place.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1495623168
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240121736


From aivanov at openjdk.org  Fri Jun 23 18:43:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 18:43:08 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4]
In-Reply-To: <KckBcZ2emHE0glhhS4ssH6i2C7Cy_36Cq6ECzYHbMlE=.ffd3b8d2-7a1d-457a-a169-9d4137bda656@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <KckBcZ2emHE0glhhS4ssH6i2C7Cy_36Cq6ECzYHbMlE=.ffd3b8d2-7a1d-457a-a169-9d4137bda656@github.com>
Message-ID: <vKAIeZPxW2VrXTRidjSxwohLmMEDIkmccHHkj7Jv_NQ=.b448d948-d9c1-4afa-bdb6-c7560ee3ef71@github.com>

On Fri, 23 Jun 2023 08:41:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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:
> 
>   Fix for JDK-8139392

Looks good to me.

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.

> 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.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 292:

> 290:                 width = UIManager.getInt("InternalFrame.titleButtonHeight") + 2;
> 291:             } else {
> 292:                 width = UIManager.getInt("InternalFrame.titleButtonHeight") -2;

Perhaps, add a space between `-2` (to be consistent with `+ 2`). You've updated the entire method `getIconWidth`, so it will look better.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java line 80:

> 78:             // Fix for XP bug where sometimes these sizes aren't updated properly
> 79:             // Assume for now that height is correct and derive width from height
> 80:             buttonWidth = buttonHeight+6;

Perhaps?
Suggestion:

            buttonWidth = buttonHeight + 6;

For `height` above, it's `- 4`; no other instances of `-` or `+` inside the method, so spaces around `+` will be consistent.

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 55:

> 53: 
> 54:     public static void main(String[] args) throws Exception {
> 55:         if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {

If you remove this line (OS check), the test would be easier to run as a stand-alone app. It's up to you though.

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 104:

> 102:                     if (icon.getIconHeight() > height - 4 ||
> 103:                         icon.getIconWidth() > height - 2) {
> 104:                         throw new RuntimeException("Wrong title icon size");

Suggestion:

                    if (icon.getIconHeight() > height - 4
                        || icon.getIconWidth() > height - 2) {
                        throw new RuntimeException("Wrong title icon size");

Wrapping the operator prevents ambiguity: continuation line or statement.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1495668370
PR Comment: https://git.openjdk.org/jdk/pull/14555#issuecomment-1604699016
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1240160993
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1240162708
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1240155464
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1240156462


From aivanov at openjdk.org  Fri Jun 23 18:43:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 18:43:09 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v4]
In-Reply-To: <bBrNlg3-X_yimxCZ0V8fOgYtLmg7XZBAXFhmkcRiqT4=.5ed673c0-3285-4d21-83ee-c0d15cabc90c@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <tIuLsbev7xgj_swx0bKU0vW-6-oNIC1oSToZD2d4CPg=.415771c6-89ae-4165-8dfb-cab1c96315de@github.com>
 <91ouxxaBSGiyRjhEgiYi5R7UzCg0DW7KAWd9ba0LgSc=.668aaab0-6b4f-49f4-b13a-1f7949f572ab@github.com>
 <32HxLWkkzUx4baOp_oYbXLgsr4jKENWVv1UOOBpwIMk=.b8f8ba1a-907b-4713-8859-df5bc6812773@github.com>
 <bBrNlg3-X_yimxCZ0V8fOgYtLmg7XZBAXFhmkcRiqT4=.5ed673c0-3285-4d21-83ee-c0d15cabc90c@github.com>
Message-ID: <xqZhfbaUcRfCrpTwaRWRzgDQBcpVs7vZYt-Gd5W95mY=.5c723845-4688-4d38-b2cc-de4b466a09e9@github.com>

On Fri, 23 Jun 2023 03:24:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> It can be removed in the strict sense but we need something to initialise it to so kept it as it is, as it will do no harm
>> 
>> Why does it need anything to initialise? The value is now set in either `if` or `else` branch.
>> 
>> It does not harm, yet it's never used. Not initialising it with `"InternalFrame.titleButtonWidth"` conveys it clearer: the value is computed later.
>
> ok. I thought buttonWidth was declared in the method but it is class variable

Nothing would've changed if it had been a local variable. Both branches initialise the local variable, the compiler is happy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1240149559


From kizune at openjdk.org  Fri Jun 23 18:52:15 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Jun 2023 18:52:15 GMT
Subject: [jdk21] RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
Message-ID: <LwI6oisP43nAWtN2K2GvaNzvazXIouYO-5kVz7e5zMI=.4cb5a433-1f19-4fae-9f80-0bd223a5ff8d@github.com>

Backport of a regression fix for JDK-8309733

Changes applied cleanly.

-------------

Commit messages:
 - Backport d1d2b55ce0b950e07f6e3761983f73fd58079627

Changes: https://git.openjdk.org/jdk21/pull/59/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=59&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309733
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/59.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/59/head:pull/59

PR: https://git.openjdk.org/jdk21/pull/59


From prr at openjdk.org  Fri Jun 23 19:03:12 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Jun 2023 19:03:12 GMT
Subject: [jdk21] RFR: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <LwI6oisP43nAWtN2K2GvaNzvazXIouYO-5kVz7e5zMI=.4cb5a433-1f19-4fae-9f80-0bd223a5ff8d@github.com>
References: <LwI6oisP43nAWtN2K2GvaNzvazXIouYO-5kVz7e5zMI=.4cb5a433-1f19-4fae-9f80-0bd223a5ff8d@github.com>
Message-ID: <c7LFeiffweWbyYW1y5WxezyRfDpHZphGeGF1Os9sTUs=.73123b55-00d9-49c8-9e98-4af8b1248b6d@github.com>

On Fri, 23 Jun 2023 18:45:41 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport of a regression fix for JDK-8309733
> 
> Changes applied cleanly.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/59#pullrequestreview-1495745120


From honkar at openjdk.org  Fri Jun 23 19:12:09 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 Jun 2023 19:12:09 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v5]
In-Reply-To: <HAI1IuVPthXgrx1wzJDh1tY_c8_XEcBoSanzhf9fFUM=.9b9252a4-5b88-44c7-ace3-cd9e343e9a5b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <HAI1IuVPthXgrx1wzJDh1tY_c8_XEcBoSanzhf9fFUM=.9b9252a4-5b88-44c7-ace3-cd9e343e9a5b@github.com>
Message-ID: <Jo2p7HSBQfmdvyAYxxOXki92mesbXlgiyZR3M72ScMk=.baed53fa-a567-4bd3-a67a-3c3d4fb741e4@github.com>

On Fri, 23 Jun 2023 17:57:16 GMT, Alisen Chung <achung at openjdk.org> 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 suggested changes

The update fix - with the current state check before acquiring the lock and removing the WindowStateListener suggested by @dmarkov20 avoids unnecessary acquiring of lock  and looks to be a better solution that before.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 970:

> 968: 
> 969:     private void waitForWindowState(int state) {
> 970:         if(peer.getState() == state) {

Add a space after if

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 993:

> 991:             }
> 992:         }
> 993: 

Minor nit: Remove extra line

test/jdk/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java line 121:

> 119:         System.out.println("------");
> 120:         examineStates(new int[] {Frame.ICONIFIED, Frame.MAXIMIZED_BOTH, Frame.NORMAL});
> 121: 

@alisenchung Now that the `lastFrameState` is fixed, I would suggest adding the cases mentioned [here](https://github.com/openjdk/jdk/pull/14226/files#r1237259547) too, to make the test comprehensive.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1495733089
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1240194617
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1240192496
PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1240211363


From kizune at openjdk.org  Fri Jun 23 19:51:04 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Jun 2023 19:51:04 GMT
Subject: [jdk21] Integrated: 8309733: [macOS,
 Accessibility] VoiceOver: Incorrect announcements of JRadioButton
In-Reply-To: <LwI6oisP43nAWtN2K2GvaNzvazXIouYO-5kVz7e5zMI=.4cb5a433-1f19-4fae-9f80-0bd223a5ff8d@github.com>
References: <LwI6oisP43nAWtN2K2GvaNzvazXIouYO-5kVz7e5zMI=.4cb5a433-1f19-4fae-9f80-0bd223a5ff8d@github.com>
Message-ID: <Qpm_FmkHzwf1jAtU9LTRMx8OX7UCy3HPjDYbX4XWrUU=.27558e87-8258-4248-9b68-c0c5e75cdada@github.com>

On Fri, 23 Jun 2023 18:45:41 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport of a regression fix for JDK-8309733
> 
> Changes applied cleanly.

This pull request has now been integrated.

Changeset: 1bcf0016
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/1bcf00167f6c485d0983f0b4bd9f7a2ca455480d
Stats:     10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8309733: [macOS, Accessibility] VoiceOver: Incorrect announcements of JRadioButton

Reviewed-by: prr
Backport-of: d1d2b55ce0b950e07f6e3761983f73fd58079627

-------------

PR: https://git.openjdk.org/jdk21/pull/59


From achung at openjdk.org  Fri Jun 23 20:24:21 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 23 Jun 2023 20:24:21 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v6]
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14226/files
  - new: https://git.openjdk.org/jdk/pull/14226/files/eaef82e2..dc506488

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14226&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14226&range=04-05

  Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14226/head:pull/14226

PR: https://git.openjdk.org/jdk/pull/14226


From honkar at openjdk.org  Fri Jun 23 20:38:08 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 Jun 2023 20:38:08 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v6]
In-Reply-To: <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
Message-ID: <g4VrbK7LLtSI9CKcxCYuAUcmFzhBmmqNn7rZJndd8X4=.0d225f61-9574-49b8-9d5f-6ac184257dbe@github.com>

On Fri, 23 Jun 2023 20:24:21 GMT, Alisen Chung <achung at openjdk.org> 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

Marked as reviewed by honkar (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1495970131


From honkar at openjdk.org  Sat Jun 24 00:19:07 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 24 Jun 2023 00:19:07 GMT
Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus
In-Reply-To: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
References: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
Message-ID: <75JvkCoVUoSRJf4joERNzTZaz-1eq0YHCTLK1UGW4Jc=.d38436dd-e53f-4f83-a2d4-6e27b1a05cdc@github.com>

On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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)

Fix looks good. 

Minor changes: Copyright year needs to be updated for src file and unused imports can be removed from the test.

-------------

Marked as reviewed by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14596#pullrequestreview-1496234256


From ngubarkov at openjdk.org  Sat Jun 24 01:15:24 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Sat, 24 Jun 2023 01:15:24 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows [v2]
In-Reply-To: <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
 <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
Message-ID: <4fA6yhbKhau0U4lkAA3xLZIBWMm7NdJK2MqJh9UBZvY=.17ff00e4-ebda-4c9e-bbcf-731d70b64c87@github.com>

On Tue, 13 Jun 2023 14:10:11 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use malloc instead of fixed size buffers.

Please do, I only did manual testing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13359#issuecomment-1605209493


From jwaters at openjdk.org  Sat Jun 24 01:29:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Jun 2023 01:29:26 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Leave nullptr for another day
 - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/d5f74cc2..3fe2a894

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=11-12

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125


From jwaters at openjdk.org  Sat Jun 24 01:29:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Jun 2023 01:29:26 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
Message-ID: <U58XcxapZN50QfMSc4fGBWYmUg4jC1txpgiB8E1K9TY=.0cd5d06e-dcd4-4291-b819-ea64f4ae5a48@github.com>

On Fri, 23 Jun 2023 17:09:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Swap to jint in awt_MenuBar.h
>  - Swap to jint in awt_MenuBar.cpp
>  - Swap to jint in awt_Menu.h

Alright, done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1605222563


From duke at openjdk.org  Sat Jun 24 03:20:45 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Sat, 24 Jun 2023 03:20:45 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v2]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <8-6QZatSmVkmb-GyHZQnfExWsi909YpOuxuB107VaI4=.5b08280d-7b7b-4574-b94b-9422f753b5be@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated documentation of modified functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/f524c5cd..5f2a334d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=00-01

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From duke at openjdk.org  Sat Jun 24 03:26:03 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Sat, 24 Jun 2023 03:26:03 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v2]
In-Reply-To: <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
Message-ID: <W2kAnO-fYiHmHJdZKB4P9kbxE6n5bmleMCFX7A_EKng=.8ae8a7ce-a8f3-44e2-baf9-dc5daed2eb8e@github.com>

On Thu, 15 Jun 2023 22:57:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated documentation of modified functions
>
> I still quibble with the premise of this bug.
> No exceptions or any nasty stuff will happen if you don't use the EDT to call getSize().
> It is more a case of you may get stale results.
> 
> And nothing in the AWT docs say you need to do this.

I have updated documentation of all entry points, @prrace thank you for your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14354#issuecomment-1605248012


From duke at openjdk.org  Sat Jun 24 05:18:16 2023
From: duke at openjdk.org (=?UTF-8?B?5p6B6YCf6JyX54mb?=)
Date: Sat, 24 Jun 2023 05:18:16 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <FT80_iCS1jCCMlAY_0Po_m555WsyVPRZJbDPg9Y47LA=.e66aeb43-8d71-4b21-a043-46887f6e26f3@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> 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

This issue also affects JetBrains IDE and many other Java GUI apps on Linux, so I hope you can merge it ASAP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1605270753


From vsitnikov at openjdk.org  Sat Jun 24 06:51:16 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 24 Jun 2023 06:51:16 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1605290913


From duke at openjdk.org  Sat Jun 24 22:51:05 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Sat, 24 Jun 2023 22:51:05 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <FT80_iCS1jCCMlAY_0Po_m555WsyVPRZJbDPg9Y47LA=.e66aeb43-8d71-4b21-a043-46887f6e26f3@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <FT80_iCS1jCCMlAY_0Po_m555WsyVPRZJbDPg9Y47LA=.e66aeb43-8d71-4b21-a043-46887f6e26f3@github.com>
Message-ID: <C1T_ED0OUJEHTB1buiwX9xVSciRNtswFbb3ie8kCK4s=.c4fcbb3d-1b5a-4aca-8f9b-88f510a91d76@github.com>

On Sat, 24 Jun 2023 05:10:51 GMT, ???? <duke at openjdk.org> wrote:

> This issue also affects JetBrains IDE and many other Java GUI apps on Linux, so I hope you can merge it ASAP.

Thanks. I also hope so!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1605762640


From jwaters at openjdk.org  Sun Jun 25 15:57:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 15:57:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <zQsqobjLOQ-GppzX8gsbDxpKhuhWiF8Jp5iXMpgLuqU=.2b070d4d-c6ae-4e17-a3fd-93797540c381@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

@aivanov-jdk Is the final change ok with you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606140949


From aivanov at openjdk.org  Sun Jun 25 16:27:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 25 Jun 2023 16:27:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
Message-ID: <ZT6k0naheyEW_RQ2JW0f9TjuSa_fZkE9_wpfRmOd4iE=.655efdb2-c60c-402f-9011-8fcfc6680b1b@github.com>

On Sat, 24 Jun 2023 01:29:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Leave nullptr for another day
>  - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1497128460


From aivanov at openjdk.org  Sun Jun 25 16:27:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 25 Jun 2023 16:27:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <QbL4jd8c7y6nvdmPRyxZPbsTul6broWyq9OhFmI4W_M=.9a21d6f0-9aa0-414a-9a35-cd8e6feef1af@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

> @aivanov-jdk Is the final change ok with you?

Looks good now. Thanks!

I've run client tests, all is green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606149816


From jwaters at openjdk.org  Sun Jun 25 23:42:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 23:42:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
Message-ID: <g9W5Zu_YwH-B81CT-WrOUXlr9hD3JrkGP3Z1AtL-cNo=.b2f493fb-10ac-483e-8747-e988bd104d7b@github.com>

On Sat, 24 Jun 2023 01:29:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Leave nullptr for another day
>  - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Haha, thanks Alexsey!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606329100


From jwaters at openjdk.org  Sun Jun 25 23:46:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 23:46:17 GMT
Subject: Integrated: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <MXS9qJEUSawtZOjSVthEal4GTj6-igakdl6GvYg200s=.fe2c1484-8ea9-4584-b4da-d5def77bb101@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

This pull request has now been integrated.

Changeset: c92b049d
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c92b049db7853a061ce05cebdc1fd73205ed0c83
Stats:     28 lines in 10 files changed: 0 ins; 5 del; 23 mod

8308780: Fix the Java Integer types on Windows

Reviewed-by: dholmes, djelinski, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/14125


From duke at openjdk.org  Mon Jun 26 00:09:04 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Mon, 26 Jun 2023 00:09:04 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <6uKrkVs6vBywo39Tfe1T9hriwcCL8tgnhLnyAk5CLUQ=.292ec82f-a346-4c6b-b049-e58879c2770d@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> 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! Is there someone review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1606347392


From psadhukhan at openjdk.org  Mon Jun 26 09:27:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 Jun 2023 09:27:19 GMT
Subject: Integrated: 6664309: Docking point of a floating toolbar changes after
 closing
In-Reply-To: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
References: <qHGAHLYJLSzRZLi5uuTkyXAqaUNR8tvqGBuAm9VOk20=.1a41f3ce-ceda-430c-94e6-7bba5c208f7f@github.com>
Message-ID: <JBGMUDPg29J_SEMXPV-HmykCiVLDOfaoXaFN06tw1-4=.f5601b02-f5ea-43d7-a284-a77c936c513e@github.com>

On Tue, 13 Jun 2023 09:53:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
> This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
> I could not find any JBS which did that code change.
> 
> Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..

This pull request has now been integrated.

Changeset: a420ff48
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a420ff48da7d8861a874ea6f7278249c20113215
Stats:     109 lines in 2 files changed: 100 ins; 9 del; 0 mod

6664309: Docking point of a floating toolbar changes after closing

Reviewed-by: tr, prr

-------------

PR: https://git.openjdk.org/jdk/pull/14444


From erikj at openjdk.org  Mon Jun 26 09:32:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jun 2023 09:32:19 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
Message-ID: <G2HH46a1taYMgOcec5NyuO8VdM0f22Km2LRV5HkEAqg=.dd217011-3a2d-4357-ba0e-bf46f725822a@github.com>

On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

I think that sounds like a reasonable idea. I'm not following that mailing list. I think you can just post a PR with your suggested contents and target build-dev (through the `build` label). I'm not familiar with this kind of file, so an explanation of which IDEs support it would be good to include.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1607073914


From psadhukhan at openjdk.org  Mon Jun 26 11:52:34 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 Jun 2023 11:52:34 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>

> 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:

  Formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14555/files
  - new: https://git.openjdk.org/jdk/pull/14555/files/399d8125..17e50d79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=03-04

  Stats: 22 lines in 3 files changed: 3 ins; 3 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 aivanov at openjdk.org  Mon Jun 26 13:43:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Jun 2023 13:43:05 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
Message-ID: <L8-TSvHAONKGoaEH0cF0ZvS41PZmqA7krEXFb6a9a_g=.5e748916-5ef6-443a-a881-decdfaba0b09@github.com>

On Mon, 26 Jun 2023 11:52:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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:
> 
>   Formatting

Would you mind updating the copyright years?

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 59:

> 57:         UIManager.setLookAndFeel(
> 58:                "com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
> 59:         try {

Actually, I meant that you can skip checking for Windows at all: the test has `@requires (os.family == "windows")` tag. Then setting *Windows Classic Look and Feel* will fail on other platforms but Windows, that is `UIManager.setLookAndFeel` will throw an exception which will eventually fail the test.

Whatever way you prefer.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14555#pullrequestreview-1498547872
PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1242206200


From aivanov at openjdk.org  Mon Jun 26 14:28:11 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Jun 2023 14:28:11 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v2]
In-Reply-To: <8-6QZatSmVkmb-GyHZQnfExWsi909YpOuxuB107VaI4=.5b08280d-7b7b-4574-b94b-9422f753b5be@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <8-6QZatSmVkmb-GyHZQnfExWsi909YpOuxuB107VaI4=.5b08280d-7b7b-4574-b94b-9422f753b5be@github.com>
Message-ID: <btNNTvmumtSJsPrI2Im1P_Of8ucWgsV6IwbLx83kQFo=.b3db08ef-41fe-4326-bef1-04b58da7e5e8@github.com>

On Sat, 24 Jun 2023 03:20:45 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated documentation of modified functions

Looks good to me except for the few comments I've left.

Did you run the tests?

test/jdk/javax/swing/regtesthelpers/JRobot.java line 42:

> 40: import javax.swing.SwingUtilities;
> 41: import java.util.concurrent.atomic.AtomicReference;
> 42: import java.lang.reflect.InvocationTargetException;

Could you sort the imports, please? You IDE should be able to handle it for you.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 44:

> 42: import java.lang.reflect.InvocationTargetException;
> 43: 
> 44: public class JRobot extends java.awt.Robot {

It would be good if you moved the javadoc for the `JRobot` class to where it belongs: to the class declaration. Now it precedes the import block.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 45:

> 43: 
> 44: public class JRobot extends java.awt.Robot {
> 45:     private static int DEFAULT_DELAY = 550;

Can you add the `final` modifier to both `DEFAULT_DELAY` and `INTERNAL_DELAY`.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 116:

> 114:      * Move mouse cursor to the center of the Component.
> 115:      * <p>
> 116:      * <b>Note:</b> This method is executed on EDT

Suggestion:

     * <b>Note:</b> This method is executed on EDT.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 178:

> 176: 
> 177:     /**
> 178:      * Click in the center of the given Component

Suggestion:

     * Click in the center of the given Component.

Let's fix the javadoc even further and add the full stop.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 180:

> 178:      * Click in the center of the given Component
> 179:      * <p>
> 180:      * <b>Note:</b> This method uses EDT

Suggestion:

     * <b>Note:</b> This method is executed on EDT.

Let's be consistent and use the same phrase.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 183:

> 181:      *
> 182:      * @param c the Component to click on
> 183:      * @param buttons mouse button(s).

Suggestion:

     * @param buttons mouse button(s)

In description of parameters, there are usually no full stops.

test/jdk/javax/swing/regtesthelpers/JRobot.java line 326:

> 324:         return (getPixelColor(x0, y0).equals(getPixelColor(x1, y1)));
> 325:     }
> 326: }

Could you add a blank line to the end of the file, please?

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1498648975
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242269274
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242285001
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242270965
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242273273
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242276455
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242274807
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242277111
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1242281272


From dmarkov at openjdk.org  Mon Jun 26 15:28:06 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 26 Jun 2023 15:28:06 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v6]
In-Reply-To: <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
Message-ID: <4StRvkzCQ8iT_UX_S-J81q7Sf_vNpo2JWeE8rb_ZNIE=.d618c9cc-9732-49be-9dda-c5e4ecb21791@github.com>

On Fri, 23 Jun 2023 20:24:21 GMT, Alisen Chung <achung at openjdk.org> 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

@alisenchung The fix looks OK. Did you test it on macOS 12? If not, can you ensure that previous macOS version(s) works fine with the proposed changes?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1498815269


From tr at openjdk.org  Mon Jun 26 16:59:11 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Jun 2023 16:59:11 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v4]
In-Reply-To: <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <xVdLss03_Om4s2hhSejEld-ARAOlDKdtDGydMzc7IFw=.843a0ce0-81b5-48fd-86e2-0d2994fd0f3d@github.com>
 <9GiNP39mXw1b3JqkSFV3PjXuQVYBIAOMiIA4OP75v84=.fd662138-47de-4d6a-b8ac-e2c8b5c28a41@github.com>
 <f0xTKNLJc3CAbIoL82kiIpTUhfzTJ0Bgy0yjI63BlwU=.aa54465e-0a65-44ce-971e-2bb5913dabb9@github.com>
 <wv5K97zhjsp0R6-MgBrpSS1hTEglhEkhPEVsJeX1N40=.18942db3-1715-4dbf-b0cc-a2438691d66c@github.com>
Message-ID: <vu-W0QRR2W6YpA3i-5k2PrrTCaBaRHoHDRv57fbBDMw=.397bb7dd-926e-4073-adf7-267c6af90e0e@github.com>

On Thu, 22 Jun 2023 18:36:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yeah, have tested in CI multiple time and also few manual dual screen related test. No regression found with fix.
>
> We have a couple of places where we call "setGraphicsConfiguration(null)", previously that sets the default GC, now it will set the null, can we try to trigger that codepath and check how it will work?

@mrserb I have addressed your review comments, Please let me know if anything else is there w.r.t fix? Let me know if the fix is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14246#discussion_r1242485099


From jjg at openjdk.org  Mon Jun 26 18:45:05 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 18:45:05 GMT
Subject: RFR: JDK-8310908: Non-standard `@since` tag in
 `com.sun.java.accessibility.util.package-info`
Message-ID: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>

Please review a trivial update to normalize an `@since` tag.

-------------

Commit messages:
 - JDK-8310908: Non-standard `@since` tag in `com.sun.java.accessibility.util.package-info`

Changes: https://git.openjdk.org/jdk/pull/14663/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14663&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310908
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14663/head:pull/14663

PR: https://git.openjdk.org/jdk/pull/14663


From bpb at openjdk.org  Mon Jun 26 18:49:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Jun 2023 18:49:02 GMT
Subject: RFR: JDK-8310908: Non-standard `@since` tag in
 `com.sun.java.accessibility.util.package-info`
In-Reply-To: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
References: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
Message-ID: <vjK61Fj6ytDJohI3QTdNDc5V2I2swpMMDQXYBdz-J-0=.c2f33e6d-2568-4ad0-8d0b-b67c83c11afc@github.com>

On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to normalize an `@since` tag.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14663#pullrequestreview-1499189002


From iris at openjdk.org  Mon Jun 26 19:12:02 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 26 Jun 2023 19:12:02 GMT
Subject: RFR: JDK-8310908: Non-standard `@since` tag in
 `com.sun.java.accessibility.util.package-info`
In-Reply-To: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
References: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
Message-ID: <e5sMf3rkhju4BsbRsqSLl78kz_tycuCBWaU4_csVZdo=.040a3181-9175-4e82-8c3a-a0bed42466bf@github.com>

On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to normalize an `@since` tag.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14663#pullrequestreview-1499229502


From aturbanov at openjdk.org  Mon Jun 26 21:03:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Jun 2023 21:03:06 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
Message-ID: <VfcRcklfVIwN5k5B8dsKHNtL9lZ60RQoXrtk0pyEdFA=.ef7789ea-e188-4053-a399-17257dc43d50@github.com>

On Mon, 26 Jun 2023 11:52:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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:
> 
>   Formatting

test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 53:

> 51:     public static void main(String[] args) throws Exception {
> 52:         String osName = System.getProperty("os.name");
> 53:         if(!osName.toLowerCase().contains("win")) {

Suggestion:

        if (!osName.toLowerCase().contains("win")) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1242763596


From aivanov at openjdk.org  Mon Jun 26 21:13:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Jun 2023 21:13:15 GMT
Subject: RFR: JDK-8310908: Non-standard `@since` tag in
 `com.sun.java.accessibility.util.package-info`
In-Reply-To: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
References: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
Message-ID: <npoJ5jktyHttvDLgDYW3wyVa0hObwNyEgGnY28L8GJ8=.513c263d-5e17-4c53-9eb7-f77be8694af8@github.com>

On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to normalize an `@since` tag.

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14663#pullrequestreview-1499440907


From honkar at openjdk.org  Mon Jun 26 21:26:09 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 26 Jun 2023 21:26:09 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <VfcRcklfVIwN5k5B8dsKHNtL9lZ60RQoXrtk0pyEdFA=.ef7789ea-e188-4053-a399-17257dc43d50@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
 <VfcRcklfVIwN5k5B8dsKHNtL9lZ60RQoXrtk0pyEdFA=.ef7789ea-e188-4053-a399-17257dc43d50@github.com>
Message-ID: <TXypAa2e-hNjfgOgkNIlbhgER1frDUZDcvPlmk0DaD0=.63a50a43-1fac-4c41-8baa-28034921715f@github.com>

On Mon, 26 Jun 2023 21:00:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Formatting
>
> test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 53:
> 
>> 51:     public static void main(String[] args) throws Exception {
>> 52:         String osName = System.getProperty("os.name");
>> 53:         if(!osName.toLowerCase().contains("win")) {
> 
> Suggestion:
> 
>         if (!osName.toLowerCase().contains("win")) {

@prsadhuk The string compare can be replaced with `OSInfo.getOSType() == OSInfo.OSType.WINDOWS`  and in case you want to retain the OSCheck along with `@requires (os.family == "windows")` when run as standalone test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1242783152


From aivanov at openjdk.org  Mon Jun 26 21:32:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Jun 2023 21:32:05 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <TXypAa2e-hNjfgOgkNIlbhgER1frDUZDcvPlmk0DaD0=.63a50a43-1fac-4c41-8baa-28034921715f@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
 <VfcRcklfVIwN5k5B8dsKHNtL9lZ60RQoXrtk0pyEdFA=.ef7789ea-e188-4053-a399-17257dc43d50@github.com>
 <TXypAa2e-hNjfgOgkNIlbhgER1frDUZDcvPlmk0DaD0=.63a50a43-1fac-4c41-8baa-28034921715f@github.com>
Message-ID: <rZ_xcOA8W5lqrv1l8TUiL-lMzjJVWSqK-DOrcVMLWIo=.f05ebb2a-e149-494a-8e1d-f9f94e99cfb8@github.com>

On Mon, 26 Jun 2023 21:21:01 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JInternalFrame/InternalFrameTitleButtonTest.java line 53:
>> 
>>> 51:     public static void main(String[] args) throws Exception {
>>> 52:         String osName = System.getProperty("os.name");
>>> 53:         if(!osName.toLowerCase().contains("win")) {
>> 
>> Suggestion:
>> 
>>         if (!osName.toLowerCase().contains("win")) {
>
> @prsadhuk The string compare can be replaced with `OSInfo.getOSType() == OSInfo.OSType.WINDOWS`  and in case you want to retain the OSCheck along with `@requires (os.family == "windows")` when run as standalone test.

I think [it's redundant](https://github.com/openjdk/jdk/pull/14555#discussion_r1242206200) in this case because setting Windows Classic L&F will throw an exception on other platforms.

It was [`OSInfo`-check initially](https://github.com/openjdk/jdk/pull/14555#discussion_r1240155464).

I'm fine with either way. However, I prefer *no check* in this particular case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1242789336


From jjg at openjdk.org  Mon Jun 26 22:28:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 22:28:10 GMT
Subject: Integrated: JDK-8310908: Non-standard `@since` tag in
 `com.sun.java.accessibility.util.package-info`
In-Reply-To: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
References: <EKqUJPtWdW18zYiGXQ2M1BUdrnATVxa3_2WfIkkl8H0=.9f2b9db8-0125-4003-9791-e7522badd12f@github.com>
Message-ID: <ZukcofJdsiINncPe6cv1AP0tqJuqeaoTf_9pkYsBNpQ=.6052a137-22d9-4b63-8009-0a31fb86c840@github.com>

On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to normalize an `@since` tag.

This pull request has now been integrated.

Changeset: 8f5b6771
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f5b6771b8eb43c695fe2bfed100f17376b9efe7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310908: Non-standard `@since` tag in `com.sun.java.accessibility.util.package-info`

Reviewed-by: bpb, iris, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/14663


From duke at openjdk.org  Tue Jun 27 01:07:09 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Tue, 27 Jun 2023 01:07:09 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <QQuGtFC5YvkEzS3rz94uzMJJae9KKxI9aDM__8-o0wE=.80fcc3e0-ec1f-47f4-b5a6-c7ec3d0337fb@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> 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

Who can review this? Or can I ask someone to review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1608550129


From serb at openjdk.org  Tue Jun 27 03:31:13 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 Jun 2023 03:31:13 GMT
Subject: RFR: 8006421: GraphicsConfiguration of a frame is changed when the
 frame is moved to another screen [v8]
In-Reply-To: <QOehbqnKC74xMRewc16t8ZNoI5DUwiNVKEQNYDJjKUA=.badb96fc-aec7-4c22-b6a4-e95aab7d9d73@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
 <QOehbqnKC74xMRewc16t8ZNoI5DUwiNVKEQNYDJjKUA=.badb96fc-aec7-4c22-b6a4-e95aab7d9d73@github.com>
Message-ID: <Ghp2GGQHZy_wWAfEsf1_gIVNB2HN83Teg5JRzLy55eU=.8f007824-8a43-4ac5-843f-917e491de1a0@github.com>

On Fri, 23 Jun 2023 10:30:13 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
>> The fix is verified in CI for regression check, which is Green.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Retained GC null check code

Marked as reviewed by serb (Reviewer).

Looks fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14246#pullrequestreview-1499879742
PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1608716331


From tr at openjdk.org  Tue Jun 27 04:59:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Jun 2023 04:59:25 GMT
Subject: Integrated: 8006421: GraphicsConfiguration of a frame is changed when
 the frame is moved to another screen
In-Reply-To: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
References: <4Vzu3_C36i3ApYZa5wqNej5YiDaTCawJh9NWrMDy_Ac=.ae965d58-f73e-4670-ba7c-ca0002315def@github.com>
Message-ID: <blFjmP794ZyDBECdemTmlU3HflmjCckmk9DxTQomdOg=.170559c8-55f7-4b67-894f-0e135a193b6c@github.com>

On Wed, 31 May 2023 11:34:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a frame is dragged from one screen to another screen, the `GraphicsConfigurations` may vary depending on screen/monitor. However, transparency has to be maintained since it is expected as it is set. So the fix addresses in maintaining the translucency capability when frame is moved from one screen to another screen. For main screen, translucency is set when `setBackground` is called, but for second screen the same is not taken care. Hence setting of Translucency Capable `GC` is taken care when screen switch happens. The fix handles only for non-opaque windows alone retaining the behavior for opaque windows. 
> The fix is verified in CI for regression check, which is Green.

This pull request has now been integrated.

Changeset: 79c056ec
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79c056ec8b73de8e4841f9fdea494821a15e7313
Stats:     161 lines in 4 files changed: 161 ins; 0 del; 0 mod

8006421: GraphicsConfiguration of a frame is changed when the frame is moved to another screen

Reviewed-by: azvegint, serb

-------------

PR: https://git.openjdk.org/jdk/pull/14246


From psadhukhan at openjdk.org  Tue Jun 27 05:56:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 27 Jun 2023 05:56:14 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v6]
In-Reply-To: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
Message-ID: <4bovhOY4E9WY8F-TxLJumOchRzsliB3HTm23xCigCU8=.42173da1-ea58-42f8-919c-b4f28913f3f2@github.com>

> 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:

  Copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14555/files
  - new: https://git.openjdk.org/jdk/pull/14555/files/17e50d79..0d030f3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14555&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 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 Jun 27 05:56:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 27 Jun 2023 05:56:15 GMT
Subject: RFR: 8140527: JInternalFrame has incorrect title button width [v5]
In-Reply-To: <rZ_xcOA8W5lqrv1l8TUiL-lMzjJVWSqK-DOrcVMLWIo=.f05ebb2a-e149-494a-8e1d-f9f94e99cfb8@github.com>
References: <U_ESSWqg4QeeUqvtKVy8pA9EYjX0J5Lv0EI5mSBKWi4=.a6ca7c36-a9d6-4925-a8ad-525bcacc2186@github.com>
 <vsioWFX1ApQsLexbvhY0EaqSqXtnQzaezgyIgLxB24A=.1fdb8ce6-7f26-4daa-8203-d5a5dc9c2250@github.com>
 <VfcRcklfVIwN5k5B8dsKHNtL9lZ60RQoXrtk0pyEdFA=.ef7789ea-e188-4053-a399-17257dc43d50@github.com>
 <TXypAa2e-hNjfgOgkNIlbhgER1frDUZDcvPlmk0DaD0=.63a50a43-1fac-4c41-8baa-28034921715f@github.com>
 <rZ_xcOA8W5lqrv1l8TUiL-lMzjJVWSqK-DOrcVMLWIo=.f05ebb2a-e149-494a-8e1d-f9f94e99cfb8@github.com>
Message-ID: <d0LXu2Egzq5qDULA_1fVBMNXKUKxYyVjuiM1LGLG-dY=.ac0fc625-b7cf-4d1e-9ed8-967c4c37e818@github.com>

On Mon, 26 Jun 2023 21:29:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @prsadhuk The string compare can be replaced with `OSInfo.getOSType() == OSInfo.OSType.WINDOWS`  and in case you want to retain the OSCheck along with `@requires (os.family == "windows")` when run as standalone test.
>
> I think [it's redundant](https://github.com/openjdk/jdk/pull/14555#discussion_r1242206200) in this case because setting Windows Classic L&F will throw an exception on other platforms.
> 
> It was [`OSInfo`-check initially](https://github.com/openjdk/jdk/pull/14555#discussion_r1240155464).
> 
> I'm fine with either way. However, I prefer *no check* in this particular case.

Actually I will prefer gentle nudge stating it's not applicable other than windows as compared to harsh failing via throwing exception, if you dont mind..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14555#discussion_r1243174370


From rmahajan at openjdk.org  Tue Jun 27 06:00:27 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 27 Jun 2023 06:00:27 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v17]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <UCboob_1scxqKAkj-LqPBo6LWZQvf8ghw-QmWuYUcco=.6e32d6f4-1765-43f0-bd0e-b1a6171a67ab@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
> Also tested with SwingSet2 .
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  minor edit to change variable name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/4d275736..473328dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=15-16

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From duke at openjdk.org  Tue Jun 27 09:59:17 2023
From: duke at openjdk.org (=?UTF-8?B?5p6B6YCf6JyX54mb?=)
Date: Tue, 27 Jun 2023 09:59:17 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
Message-ID: <LDx-77mnLrhCrkHoJ9AwUU9g2odoOqchhQdlP80gZvw=.c7963b12-130a-488e-89e7-17fe31940821@github.com>

On Fri, 7 Apr 2023 05:26:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> ??? 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
>
> Provide a complete description and explanation of what you are doing, and why it is is the correct solution and
> what testing you have done and what testing you have NOT done and what the risks are - including to apps not using an IM
> In other words, whilst you (I hope) understand how you decided this was the right solution (and weren't just copying
> what someone proposed in the bug report), reviewers would like to hear from YOU. Not just see code.
> So spend time writing it up properly and clearly.

@prrace Is there anyone we can ask for help?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1609175188


From duke at openjdk.org  Tue Jun 27 11:49:00 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 27 Jun 2023 11:49:00 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v3]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <dT-hvSlukwvb4JtiHaljjQ4jZxZbfV_1UUoHA0KHB6o=.4d1725e8-72d8-4138-bf21-fe4bd6f1ffe6@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Reordered imports and updated java doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/5f2a334d..b482a9c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=01-02

  Stats: 8 lines in 1 file changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From duke at openjdk.org  Tue Jun 27 11:50:03 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 27 Jun 2023 11:50:03 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v3]
In-Reply-To: <xghKrtFGjLMyXJ8fZNLeG_pdh2xoOTckMEhxLfKhMr8=.fbcdff8d-d6ab-4ab2-b3f7-419f5f5fd02c@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <R7VCXo7U6yYPvvkL2YpLG6m-b6wKdfe3kS9ejce8WPs=.ec0b308c-cef8-4c9d-80de-ebc2b0b015c3@github.com>
 <xghKrtFGjLMyXJ8fZNLeG_pdh2xoOTckMEhxLfKhMr8=.fbcdff8d-d6ab-4ab2-b3f7-419f5f5fd02c@github.com>
Message-ID: <fH6ZX2VfR0nUG-VdZ5AWhOUr9RROMLSpv-WVsXV-KVc=.3737dd23-3636-4863-a0d8-4a4fc53fc368@github.com>

On Wed, 21 Jun 2023 10:36:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I still quibble with the premise of this bug.
>> No exceptions or any nasty stuff will happen if you don't use the EDT to call getSize().
>> It is more a case of you may get stale results.
>> 
>> And nothing in the AWT docs say you need to do this.
>
>> I still quibble with the premise of this bug. No exceptions or any nasty stuff will happen if you don't use the EDT to call getSize(). It is more a case of you may get stale results.
> 
> Stale result may lead to a test failure because robot moved mouse to an incorrect location.
> 
> I submitted this bug after I noticed it in a code review. It might have been the reason why that test failed intermittently. That test was rewritten without using `JRobot` if my memory serves me right.
> 
>> And nothing in the AWT docs say you need to do this.
> 
> AWT docs don't say AWT is thread-safe either, at least explicitly.
> 
> Yet this case is for Swing components where the docs always say Swing is not thread-safe. The `JRobot` class is `test/jdk/javax/swing/regtesthelpers/` which implies it's used for testing Swing.

Thank you @aivanov-jdk for the review, I have sorted imports and updated java docs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14354#issuecomment-1609339241


From aivanov at openjdk.org  Tue Jun 27 12:45:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Jun 2023 12:45:05 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v3]
In-Reply-To: <dT-hvSlukwvb4JtiHaljjQ4jZxZbfV_1UUoHA0KHB6o=.4d1725e8-72d8-4138-bf21-fe4bd6f1ffe6@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <dT-hvSlukwvb4JtiHaljjQ4jZxZbfV_1UUoHA0KHB6o=.4d1725e8-72d8-4138-bf21-fe4bd6f1ffe6@github.com>
Message-ID: <qAeDBt4bvbaXsIh7AwZfQ34RCCGn_0C79uE6Ur5alQQ=.8294d25d-fac7-48b2-9782-aa151c608648@github.com>

On Tue, 27 Jun 2023 11:49:00 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reordered imports and updated java doc

Other comments haven't been addressed.

> It would be good if you moved the javadoc for the JRobot class to where it belongs: to the class declaration. Now it precedes the import block. [?](https://github.com/openjdk/jdk/pull/14354#discussion_r1242285001)

GitHub doesn't allow adding comments to unmodified lines. The javadoc for the class is at lines 24?33:
https://github.com/openjdk/jdk/blob/b482a9c08c500cc260f07cfe11c8aa11c8f066dc/test/jdk/javax/swing/regtesthelpers/JRobot.java#L24-L34

That is it's before the imports, but it has to be before the class declaration at line 45.

> Can you add the `final` modifier to both `DEFAULT_DELAY` and `INTERNAL_DELAY`. [?](https://github.com/openjdk/jdk/pull/14354#discussion_r1242270965)

These are the two constants declared at lines 46?47:

https://github.com/openjdk/jdk/blob/b482a9c08c500cc260f07cfe11c8aa11c8f066dc/test/jdk/javax/swing/regtesthelpers/JRobot.java#L46-L47

test/jdk/javax/swing/regtesthelpers/JRobot.java line 194:

> 192:      * Click the first mouse button in the center of the given Component
> 193:      * <p>
> 194:      * <b>Note:</b> This method uses EDT

This instance still uses the old wording.

In [my comment](https://github.com/openjdk/jdk/pull/14354#discussion_r1242274807), I meant updating **all** the notes when I said about *being consistent*.

The `convertRectToScreen` method needs updating as well.

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1500730356
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1243648357


From duke at openjdk.org  Tue Jun 27 14:10:38 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 27 Jun 2023 14:10:38 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v4]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <wdM1DVfTVw_xzfX3Tg7qOreoJYlR6rWEShiV1SjN5nc=.63812f14-6e20-49f0-870c-e8357d2adece@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated java doc and added final to delay

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/b482a9c0..6b6a4412

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=02-03

  Stats: 25 lines in 1 file changed: 11 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From duke at openjdk.org  Tue Jun 27 14:10:38 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 27 Jun 2023 14:10:38 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v3]
In-Reply-To: <dT-hvSlukwvb4JtiHaljjQ4jZxZbfV_1UUoHA0KHB6o=.4d1725e8-72d8-4138-bf21-fe4bd6f1ffe6@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <dT-hvSlukwvb4JtiHaljjQ4jZxZbfV_1UUoHA0KHB6o=.4d1725e8-72d8-4138-bf21-fe4bd6f1ffe6@github.com>
Message-ID: <n2zW87xWwg7vAM9lBzjIhhj00mClckaxfSVtT4CXuUc=.95ca2dd6-9050-41df-a561-2fa5f2dd05a7@github.com>

On Tue, 27 Jun 2023 11:49:00 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reordered imports and updated java doc

Updated those changes, please review and let me know your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14354#issuecomment-1609580148


From aivanov at openjdk.org  Tue Jun 27 14:31:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Jun 2023 14:31:06 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v4]
In-Reply-To: <wdM1DVfTVw_xzfX3Tg7qOreoJYlR6rWEShiV1SjN5nc=.63812f14-6e20-49f0-870c-e8357d2adece@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <wdM1DVfTVw_xzfX3Tg7qOreoJYlR6rWEShiV1SjN5nc=.63812f14-6e20-49f0-870c-e8357d2adece@github.com>
Message-ID: <N40ODeiyYeajV6TejdYUodjh5gAhpZEfKYMRqweQjz0=.c2cc6879-6a6b-43b3-807e-b688e8220f22@github.com>

On Tue, 27 Jun 2023 14:10:38 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated java doc and added final to delay

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/regtesthelpers/JRobot.java line 48:

> 46: public class JRobot extends java.awt.Robot {
> 47:     final private static int DEFAULT_DELAY = 550;
> 48:     final private static int INTERNAL_DELAY = 250;

Please use [the *blessed* modifier order](https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Modifier.html#toString-int-): `private static final`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1501034446
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1243846370


From duke at openjdk.org  Tue Jun 27 14:44:21 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 27 Jun 2023 14:44:21 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v5]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <ruhotLQ2aEqutdga1qjRZttOA4COwWt5ncxN0DuWw6A=.6caa9167-1609-41d5-bd5b-864f4c52bcb3@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Corrected modifiers order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/6b6a4412..b8ab541d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From aivanov at openjdk.org  Tue Jun 27 15:00:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Jun 2023 15:00:09 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v5]
In-Reply-To: <ruhotLQ2aEqutdga1qjRZttOA4COwWt5ncxN0DuWw6A=.6caa9167-1609-41d5-bd5b-864f4c52bcb3@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <ruhotLQ2aEqutdga1qjRZttOA4COwWt5ncxN0DuWw6A=.6caa9167-1609-41d5-bd5b-864f4c52bcb3@github.com>
Message-ID: <oMplnGpWL4zEonjEQPJsFLyuorHkSbn9XshDOIJ6BhI=.f01173ef-240f-4b31-b67c-8212a35cee81@github.com>

On Tue, 27 Jun 2023 14:44:21 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected modifiers order

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/regtesthelpers/JRobot.java line 42:

> 40:  * @library ../../../regtesthelpers
> 41:  * @build JRobot
> 42:  * </pre>

Could you please add `{@code}` to avoid IDE warning about wrong javadoc tags?

That is the javadoc comment should look like this:


 * <pre>{@code
 * @library ../../../regtesthelpers
 * @build JRobot
 * }</pre>

-------------

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1501133980
PR Review Comment: https://git.openjdk.org/jdk/pull/14354#discussion_r1243898216


From aivanov at openjdk.org  Tue Jun 27 16:27:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Jun 2023 16:27:20 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v17]
In-Reply-To: <UCboob_1scxqKAkj-LqPBo6LWZQvf8ghw-QmWuYUcco=.6e32d6f4-1765-43f0-bd0e-b1a6171a67ab@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <UCboob_1scxqKAkj-LqPBo6LWZQvf8ghw-QmWuYUcco=.6e32d6f4-1765-43f0-bd0e-b1a6171a67ab@github.com>
Message-ID: <g5IgoFZjMnBoloV-jIUHvRnmMAVV7NwtfaYULSXPESw=.a2a85c6d-727d-4b83-aeb2-a3db16381725@github.com>

On Tue, 27 Jun 2023 06:00:27 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
>> Also tested with SwingSet2 .
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling value...
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor edit to change variable name

Looks good to me.

Check boxes, radio buttons as well as checks in menus look crisp on all displays.

The following image displays the difference between the current and proposed versions. The current JDK code is on the left; build with code from this PR is on the right. SwingSet2 was moved from main 200%-scale display to a secondary 150%-scale display.

![Radio check in menu, Check in menu and check boxes and radio buttons without the fix and with the fix](https://github.com/openjdk/jdk/assets/70774172/8baa6b0b-9a99-4570-ac93-396389508424)

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1501392033


From prr at openjdk.org  Tue Jun 27 20:03:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 Jun 2023 20:03:12 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows [v2]
In-Reply-To: <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
 <TOe8ktgFlz3CyUe5AgiRZLeGz3Snq8d0TSh98JW086s=.2486e321-72b1-4c71-9d64-09cf93c5a684@github.com>
Message-ID: <Q7tDZ9fcvlqTSzuoxq0BJKSAOOUDV6YCBAZ8lhWH_gk=.03b2295e-b12a-490f-9f5f-f98116641814@github.com>

On Tue, 13 Jun 2023 14:10:11 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use malloc instead of fixed size buffers.

Marked as reviewed by prr (Reviewer).

Automated testing looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13359#pullrequestreview-1501754000
PR Comment: https://git.openjdk.org/jdk/pull/13359#issuecomment-1610133182


From prr at openjdk.org  Tue Jun 27 20:23:14 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 Jun 2023 20:23:14 GMT
Subject: Integrated: 8310238: [test bug]
 javax/swing/JTableHeader/6889007/bug6889007.java fails
In-Reply-To: <60Na-NI_BW5Bb5dmHQalB6rS61twGQRLFw1kSExCDe4=.b0d0b5d2-30fd-4d7f-b6cf-2bb92c77d241@github.com>
References: <60Na-NI_BW5Bb5dmHQalB6rS61twGQRLFw1kSExCDe4=.b0d0b5d2-30fd-4d7f-b6cf-2bb92c77d241@github.com>
Message-ID: <26tpVzp-S2iLBTcLpY_Yr8IV7PGMV0DLG05Q5yqpRRc=.52a282f0-8e6b-4b6c-9cc3-615a22cffb64@github.com>

On Fri, 16 Jun 2023 19:25:14 GMT, Phil Race <prr at openjdk.org> wrote:

> This test fails *every* time when run as part of full set of jtreg tests and that is because it is sensitive to the initial mouse location,
> and the previous test always sets it to within the location of this test's window.
> The only reason it isn't problem listed is because on re-run - without that preceding test - it will pass.
> 
> More info in the bug report.

This pull request has now been integrated.

Changeset: 2cf5c2f4
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cf5c2f4b6cdb52a3560ab03d272f19f47b22b17
Stats:     24 lines in 1 file changed: 19 ins; 2 del; 3 mod

8310238: [test bug] javax/swing/JTableHeader/6889007/bug6889007.java fails

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/14527


From rmahajan at openjdk.org  Tue Jun 27 20:26:53 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 27 Jun 2023 20:26:53 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v18]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <UdWCKBdXjM8NS4iX1D3hSlnyCCRhgSpq3bevWZvG8JA=.b6e8ba07-acc0-464d-8a6a-894be0769c7b@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
> Also tested with SwingSet2 .
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

Rajat Mahajan 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 22 additional commits since the last revision:

 - Merge branch 'master' into jdk_8294427
 - minor edit to change variable name
 - minor edits to variable names and code
 - get DPI based part size for widgets and parts that need it. This ensures that all parts and widgets get rendered correctly. I ensured this by running the SwingSet2 tests.
 - code changes as per reviewers suggestions
 - code changes as per suggestions by reviewer
 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ed7359e4...0719ec3b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/473328dd..0719ec3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=16-17

  Stats: 581083 lines in 7186 files changed: 465290 ins; 64975 del; 50818 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From achung at openjdk.org  Tue Jun 27 20:57:26 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 27 Jun 2023 20:57:26 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v18]
In-Reply-To: <UdWCKBdXjM8NS4iX1D3hSlnyCCRhgSpq3bevWZvG8JA=.b6e8ba07-acc0-464d-8a6a-894be0769c7b@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <UdWCKBdXjM8NS4iX1D3hSlnyCCRhgSpq3bevWZvG8JA=.b6e8ba07-acc0-464d-8a6a-894be0769c7b@github.com>
Message-ID: <jtLTNjmXGRK4EfW_c33zj1pXuWNp-xOdxMIaMUOzfmU=.e868048b-c0b2-4eae-99a4-f565137aab18@github.com>

On Tue, 27 Jun 2023 20:26:53 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
>> Also tested with SwingSet2 .
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling value...
>
> Rajat Mahajan 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 22 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk_8294427
>  - minor edit to change variable name
>  - minor edits to variable names and code
>  - get DPI based part size for widgets and parts that need it. This ensures that all parts and widgets get rendered correctly. I ensured this by running the SwingSet2 tests.
>  - code changes as per reviewers suggestions
>  - code changes as per suggestions by reviewer
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/3e4ff1f5...0719ec3b

Marked as reviewed by achung (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1501827405


From duke at openjdk.org  Wed Jun 28 03:25:23 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 28 Jun 2023 03:25:23 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v6]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <9PhUAIfkq7C7ch-caJTaMEdjlKYfLlrPIejKnsS6cE8=.b368ae8f-6eae-4036-b44a-0a0f69ecb532@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Removed blank space from javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/b8ab541d..24745391

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From duke at openjdk.org  Wed Jun 28 03:52:08 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Wed, 28 Jun 2023 03:52:08 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
Message-ID: <q-mRHGN_uhkNVv1kV_tOyAx94xlut99ggUYx3SgKytE=.fdd440cb-be9d-46f3-bfc2-030ed83b79ed@github.com>

On Fri, 7 Apr 2023 05:26:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> ??? 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
>
> Provide a complete description and explanation of what you are doing, and why it is is the correct solution and
> what testing you have done and what testing you have NOT done and what the risks are - including to apps not using an IM
> In other words, whilst you (I hope) understand how you decided this was the right solution (and weren't just copying
> what someone proposed in the bug report), reviewers would like to hear from YOU. Not just see code.
> So spend time writing it up properly and clearly.

@prrace This bug exists in all jdk version, like jdk8,jdk11,jdk17. I hope the codes can be integrated ASAP, then I will create PR for jdk8/jdk11/jdk17. So can you ask someone to review and integrate this PR?
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1610643413


From tr at openjdk.org  Wed Jun 28 06:06:06 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 28 Jun 2023 06:06:06 GMT
Subject: RFR: 8301606: JFileChooser file chooser details view "size" label
 cut off in Metal Look&Feel
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>
 <GKD5zWBExhGT2JcDkX5u5yUcYUI8dAAIynczs7Cut8I=.9594cbc5-7ea9-4fa7-a2b2-5fbb810ce27f@github.com>
 <v1huuck2nrRW4l1bOffl8RQpis7nQYiE7PQctg-8Zew=.ced7bb24-49cf-4c6d-8509-e0d4578425ec@github.com>
 <3X75XfgvvgHMJXa8sRG6TrvE7GfYqLHO3jlmN_H-XT8=.378115b4-3b61-4ccb-8f02-0883d51c6961@github.com>
Message-ID: <KsMNdw5_BwC-eiZiysvd5Ak_QhcNDI0OEEP8niSeQc8=.c08c3dd1-9a57-4e92-bfc5-4bd11d66147b@github.com>

On Tue, 20 Jun 2023 20:33:32 GMT, Phil Race <prr at openjdk.org> 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 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1610798256


From duke at openjdk.org  Wed Jun 28 10:43:18 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 28 Jun 2023 10:43:18 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v7]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <C1L1YwRPJTqYCugVuiu88QCXKcYtJ4paL-4znb4adaU=.89028e6e-7275-4390-9fe0-497b17277df2@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Removed blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/24745391..ea5d1829

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From aivanov at openjdk.org  Wed Jun 28 10:59:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 10:59:06 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v7]
In-Reply-To: <C1L1YwRPJTqYCugVuiu88QCXKcYtJ4paL-4znb4adaU=.89028e6e-7275-4390-9fe0-497b17277df2@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
 <C1L1YwRPJTqYCugVuiu88QCXKcYtJ4paL-4znb4adaU=.89028e6e-7275-4390-9fe0-497b17277df2@github.com>
Message-ID: <pV-oMhAR0fmdlhVrq0BJQSYZxV-f7NaNFGngYVL1MMY=.a91cc044-2938-4dcb-b151-0acc873f80c3@github.com>

On Wed, 28 Jun 2023 10:43:18 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> 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
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed blank line

Looks good to me.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14354#pullrequestreview-1502828211


From duke at openjdk.org  Wed Jun 28 11:27:19 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 28 Jun 2023 11:27:19 GMT
Subject: RFR: 8307934 JRobot.moveMouseTo must access component on EDT [v8]
In-Reply-To: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
References: <fCTw4rOGXVSCGfIyqRos2zEcv-X9FQR952Y5CLIqjb0=.f36fa023-632a-4c66-a6b6-cd6e72b9bd5f@github.com>
Message-ID: <LALByVw5XD-lOOPElTls5EWn4Sp4EgnPEhltqF9lJm0=.2c065891-6bde-415a-bfc7-d644e874f34d@github.com>

> 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

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14354/files
  - new: https://git.openjdk.org/jdk/pull/14354/files/ea5d1829..9beebe6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14354&range=06-07

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14354/head:pull/14354

PR: https://git.openjdk.org/jdk/pull/14354


From ngubarkov at openjdk.org  Wed Jun 28 12:42:25 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 28 Jun 2023 12:42:25 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <PAwP-wsTf7PB9sz9aDxaa0SV46QijENlT9zUMMlAIn4=.5ac87ec5-522a-4db7-92ab-3ff1cd644ea1@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <zIGac-2zWoqMQdivqDZQTl3SRwhvl0P-jl7xM1T-bTs=.1af598c3-85bf-4637-bb91-c1b6d30b9360@github.com>
 <PAwP-wsTf7PB9sz9aDxaa0SV46QijENlT9zUMMlAIn4=.5ac87ec5-522a-4db7-92ab-3ff1cd644ea1@github.com>
Message-ID: <W81VOK25MVsC6wpuL_cBdyyRXhj2ELbwnO0qHdswn0c=.e5bd1a35-7ce8-43c3-ba0d-ddd9aca319f1@github.com>

On Mon, 20 Mar 2023 21:09:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Cool, then I wouldn't have to implement lookup tables myself :)
>
>> Cool, then I wouldn't have to implement lookup tables myself :)
> 
> It is now integrated so you can sync master into your branch and take it for a spin !

@prrace could you take a look at this when you have time, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/4798#issuecomment-1611326977


From mbaesken at openjdk.org  Wed Jun 28 12:57:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 12:57:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
Message-ID: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>

On Thu, 22 Jun 2023 14:20:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/java.sql/share/classes/java/sql/DriverManager.java line 658:
> 
>> 656:          * (which is invoking this class indirectly)
>> 657:          * classloader, so that the JDBC driver class outside the image
>> 658:          * can be loaded from here.
> 
> This code should probably be changed to use VM.isSystemDomainLoader(callerCL).
> 
> I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:
> 
> "If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

Hi Alan, regarding usage of class VM I get 
'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
Is there any concern to export it as well to module java.sql  ?
And btw did you mean to use it like this, in the if  ?

`        if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
            callerCL = Thread.currentThread().getContextClassLoader();
        }`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245164604


From alanb at openjdk.org  Wed Jun 28 13:19:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jun 2023 13:19:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
Message-ID: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>

On Wed, 28 Jun 2023 12:54:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
> 
> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`

It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245197137


From mbaesken at openjdk.org  Wed Jun 28 13:25:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 13:25:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
Message-ID: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>

On Wed, 28 Jun 2023 13:16:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, regarding usage of class VM I get 
>> 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
>> Is there any concern to export it as well to module java.sql  ?
>> And btw did you mean to use it like this, in the if  ?
>> 
>> `
>>  if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
>>             callerCL = Thread.currentThread().getContextClassLoader();
>> }
>> `
>
>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>> 
>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
> 
> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245204791


From lkorinth at openjdk.org  Wed Jun 28 17:04:24 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 28 Jun 2023 17:04:24 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
Message-ID: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>

Remove trailing "blank" lines in source files.

I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.

The fix removes trailing lines matching ^[[:space:]]*$ in

- *.java
- *.cpp
- *.hpp
- *.c
- *.h 

I have applied the following bash script to each file:

    file="$1"
    
    while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
        truncate -s -1 "$file"
    done

`git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
`git diff --ignore-blank-lines  master` displays one change

-------------

Commit messages:
 - h
 - c
 - hpp
 - cpp
 - 8311043: Remove trailing blank lines in source files

Changes: https://git.openjdk.org/jdk/pull/14698/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311043
  Stats: 4529 lines in 4382 files changed: 0 ins; 4529 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14698/head:pull/14698

PR: https://git.openjdk.org/jdk/pull/14698


From dnguyen at openjdk.org  Wed Jun 28 18:40:53 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 28 Jun 2023 18:40:53 GMT
Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus
In-Reply-To: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
References: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
Message-ID: <GWRid2Fo5DXlgWQZz8_tv0atCVujLWdfJs5IbrZ8jV0=.85f27c3b-e544-4479-81b6-d5a3621f875b@github.com>

On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14596#discussion_r1245613153


From abhiscxk at openjdk.org  Wed Jun 28 18:41:54 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 28 Jun 2023 18:41:54 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
Message-ID: <tROWmEWnhf0VHmHOGaB9NfL-ilNTqiDBO1efreXjUtM=.767d5d57-f4c3-4fb1-93ca-999ff47237cd@github.com>

On Mon, 19 Jun 2023 09:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

@azuev-java  Please review this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1611900115


From achung at openjdk.org  Wed Jun 28 19:08:55 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 28 Jun 2023 19:08:55 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v2]
In-Reply-To: <nUShWDISGozG3gLdI1JFruD8chLxHIXvae2nk_-58DQ=.d5bd497c-37cf-4db6-a287-7edf263cc15d@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <sHB0UoH0F1qG6Opu5t-S70Ypm8XlgMKbnKZZjI8En2w=.b7ea192a-1a44-4669-9407-32eacb85f0a2@github.com>
 <CeXRtSTsGN2b2IMEQpWIOcek5fZKkEhaHS59-Li5F44=.93bb9b89-f8f0-4659-b0a9-4203e056c286@github.com>
 <nUShWDISGozG3gLdI1JFruD8chLxHIXvae2nk_-58DQ=.d5bd497c-37cf-4db6-a287-7edf263cc15d@github.com>
Message-ID: <A21Y5Na0fzXwaPrm8iAtvOVgqBhSsM-XdKJ6jQEPKXE=.2da43466-8f3d-4fd4-b504-08283648bf08@github.com>

On Wed, 14 Jun 2023 20:35:14 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I don't like the idea of a delay in either of the ways discussed here.
>> And although I do think that its much better to wait for delivery of an event,  I'm not sure I understand the windowState listener proposal.
>> How do you know in this code that the transition of
>> iconified-> normal will then followed by normal->maximised ?
>> Perhaps you'll wait for ever ?
>> But I don't know what the macOS native model is for all of this.
>> This sequence is kind of odd and I'm curious what happens on older macOS releases - Sergey touched on this but I don't see direct followup.
>> There seems to be assumptions it was like this previously but now it is slower ?
>> 
>> I suggest explicit verification of what happens on macOS 12.6.
>> Are we now getting two native events when there used to be only one ?
>
>> I don't like the idea of a delay in either of the ways discussed here. And although I do think that its much better to wait for delivery of an event, I'm not sure I understand the windowState listener proposal. How do you know in this code that the transition of iconified-> normal will then followed by normal->maximised ? 
> 
> The code here is trying to do a transition from iconified -> maximized, but splits it up into iconified -> normal and normal -> maximized.

> @alisenchung The fix looks OK. Did you test it on macOS 12? If not, can you ensure that previous macOS version(s) works fine with the proposed changes?

I've tested on macOS12 and it works fine with the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1611938229


From aivanov at openjdk.org  Wed Jun 28 19:18:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 19:18:10 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v18]
In-Reply-To: <UdWCKBdXjM8NS4iX1D3hSlnyCCRhgSpq3bevWZvG8JA=.b6e8ba07-acc0-464d-8a6a-894be0769c7b@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <UdWCKBdXjM8NS4iX1D3hSlnyCCRhgSpq3bevWZvG8JA=.b6e8ba07-acc0-464d-8a6a-894be0769c7b@github.com>
Message-ID: <5FEJDkJ2pj3QhPS3-Ovi8xvQlE3dpZuXRM-QMNwTGe0=.9f5b787b-b3f0-44fa-8e64-e528834f6240@github.com>

On Tue, 27 Jun 2023 20:26:53 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
>> Also tested with SwingSet2 .
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling value...
>
> Rajat Mahajan 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 22 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk_8294427
>  - minor edit to change variable name
>  - minor edits to variable names and code
>  - get DPI based part size for widgets and parts that need it. This ensures that all parts and widgets get rendered correctly. I ensured this by running the SwingSet2 tests.
>  - code changes as per reviewers suggestions
>  - code changes as per suggestions by reviewer
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/a41efb76...0719ec3b

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 93:

> 91:                  int iPropId, DWORD *pdwDuration);
> 92: 
> 93: static PFNOPENTHEMEDATAFORDPI OpenThemeDataFuncForDpi = NULL;

All other function have the `-Func` postfix, we should follow the naming convention.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1503819441
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1245655149


From aivanov at openjdk.org  Wed Jun 28 19:33:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 19:33:00 GMT
Subject: RFR: 8307325: Verify the focus owner when non focused windows
 requesting focus [v2]
In-Reply-To: <GvPoYjKB48bcJGyqDVpIavie-xf1BIiIZ_csxYCZNIw=.d107a1aa-12b4-43f6-ba79-0e96a36c50be@github.com>
References: <tYKi1dYUhO_JjPfOi2jV0RMD2SfIpu5soQNbkKtdQS0=.5cceb380-71d7-4da8-8f17-b3d6f5bf98e5@github.com>
 <GvPoYjKB48bcJGyqDVpIavie-xf1BIiIZ_csxYCZNIw=.d107a1aa-12b4-43f6-ba79-0e96a36c50be@github.com>
Message-ID: <w4Qp51Pzwb5VPKibKRhSeIVGPB3_r-WNlbEvUHQfm0E=.639c1338-6dc8-4929-91b1-68845a55648b@github.com>

On Tue, 16 May 2023 05:04:51 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following
>> 
>> 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus
>> across Windows.
>> 2.The request is remembered and  be granted when the Window is later focused If the platform does not support requesting focus
>> across Windows.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307325: Review comments fixed

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 50:

> 48: 
> 49:     private static Frame frame1, frame2;
> 50:     private volatile static Button button;

Please use the [blessed modifier order](https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Modifier.html#toString-int-): `private static volatile`.

In fact, neither `button` nor `textField` need to be `volatile`.

test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 95:

> 93:                 compAt.y + compSize.height - 20);
> 94:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
> 95:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);

How does it test that the `requestFocus` works across frames?!

You click the text field in the first frame, which grants the focus to the text field irrespective whether `requestFocus` was called or not.

It does not make sense to me.

test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 141:

> 139:     }
> 140: 
> 141:     public static void disposeFrame() {

Suggestion:

    private static void disposeFrames() {

`initializeGUI` is private, why is `disposeFrame` public?

Since you have two frames, using plural is better.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13790#pullrequestreview-1503761835
PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1245628552
PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1245666425
PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1245672255


From aivanov at openjdk.org  Wed Jun 28 19:33:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 19:33:02 GMT
Subject: RFR: 8307325: Verify the focus owner when non focused windows
 requesting focus [v2]
In-Reply-To: <uLNiiXCXhoB8PydKtXNhbUtxwToQKYPBXp99DzSa1qA=.b4d4b82d-b30d-44a7-a9d6-eb052e59fdd2@github.com>
References: <tYKi1dYUhO_JjPfOi2jV0RMD2SfIpu5soQNbkKtdQS0=.5cceb380-71d7-4da8-8f17-b3d6f5bf98e5@github.com>
 <GvPoYjKB48bcJGyqDVpIavie-xf1BIiIZ_csxYCZNIw=.d107a1aa-12b4-43f6-ba79-0e96a36c50be@github.com>
 <uLNiiXCXhoB8PydKtXNhbUtxwToQKYPBXp99DzSa1qA=.b4d4b82d-b30d-44a7-a9d6-eb052e59fdd2@github.com>
Message-ID: <dFoDPaEa8Zgk7vF_ZKKqYkQWskpAJXKKDEr6O4j53CU=.a93c96aa-dae4-431b-ac7f-0f22b567eacf@github.com>

On Tue, 30 May 2023 19:12:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Should these frames be named something specific to the test?

I agree, more specific caption could help diagnose which test left frames open.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1245670693


From dmarkov at openjdk.org  Wed Jun 28 19:41:00 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 28 Jun 2023 19:41:00 GMT
Subject: RFR: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected. [v6]
In-Reply-To: <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
 <PwpV-R-faRCsmL6e7txArwPs5Iv7vr2WN3I2RFzL6EY=.d288c643-9e72-494c-b947-242ec24d4abc@github.com>
Message-ID: <wIedoV0N-HiyvIIX8S-nlM-aWi-P0eUOoZkK_IQV4R8=.b8d9d742-2f2e-48cf-aa26-4dce328edee2@github.com>

On Fri, 23 Jun 2023 20:24:21 GMT, Alisen Chung <achung at openjdk.org> 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

Marked as reviewed by dmarkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1503857057


From rmahajan at openjdk.org  Wed Jun 28 19:42:21 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 28 Jun 2023 19:42:21 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v19]
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <wn_hf1m5S-mLbvUfNZYENkGRvSJXdlLM2yelbTEIKUs=.6836cc21-2e32-40c8-a54d-c501de65ba40@github.com>

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
> Also tested with SwingSet2 .
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  variable name change to match convention

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13701/files
  - new: https://git.openjdk.org/jdk/pull/13701/files/0719ec3b..e73dfbe2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=17-18

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From aivanov at openjdk.org  Wed Jun 28 20:04:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 20:04:00 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v5]
In-Reply-To: <oodhO-t4FiVs57TnqVz33f7Fg8fXIJf2T8lV7QmzA6k=.5fe52446-5e29-4193-aebd-ce3f4139d980@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
 <oodhO-t4FiVs57TnqVz33f7Fg8fXIJf2T8lV7QmzA6k=.5fe52446-5e29-4193-aebd-ce3f4139d980@github.com>
Message-ID: <mQ42USSuO1bsp6PYLrM6IYPI9U3vhtzg-o1p4YyZL94=.c0307828-fc38-479d-b9a9-ad23ca55e505@github.com>

On Thu, 4 May 2023 09:56:18 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code modified

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 58:

> 56:     private volatile static TextField textField;
> 57:     private volatile static Checkbox checkbox;
> 58:     private volatile static List list;

@DamonGuy also asked why these particular components were chosen. And it looks some of them are non-focusable.

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 71:

> 69:         new CountDownLatch(1);
> 70: 
> 71:     private volatile static FocusListener listener = new FocusListener() {

Why are all listeners volatile?
And why is this listener is just listener rather than a specific one as others?

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 97:

> 95:     };
> 96: 
> 97:     private volatile static FocusListener butonListener = new FocusListener() {

Suggestion:

    private volatile static FocusListener buttonListener = new FocusListener() {

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 170:

> 168:             });
> 169: 
> 170:             if (!button.isFocusOwner()) {

If you carefully call component methods on EDT, then `isFocusOwner` should also be called on EDT.

And before calling this method, you should still call `robot.waitForIdle()` ? the `autoWaitForIdle` property works only when you call Robot API.

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 184:

> 182: 
> 183:             EventQueue.invokeAndWait(() -> {
> 184:                 checkbox.requestFocusInWindow();

@DamonGuy  asked the question:

> Question: The title and bug description mentions testing requestFocus but this test uses requestFocusInWindow. Are you actually testing the right thing here?

It's still unanswered. It's also unclear to me.

Are you testing `requestFocus` or `requestFocusInWindow`?

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 234:

> 232:                     + comp);
> 233:         }
> 234:         if (!comp.isFocusOwner()) {

The `isFocusOwner` method needs to be called on EDT. However, the latch synchronises the two threads, so the call to `isFocusOwner` on the main thread should return the same result.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13293#pullrequestreview-1503857212
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245694846
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245678449
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245692361
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245683882
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245689251
PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1245691630


From aivanov at openjdk.org  Wed Jun 28 20:05:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Jun 2023 20:05:02 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v19]
In-Reply-To: <wn_hf1m5S-mLbvUfNZYENkGRvSJXdlLM2yelbTEIKUs=.6836cc21-2e32-40c8-a54d-c501de65ba40@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <wn_hf1m5S-mLbvUfNZYENkGRvSJXdlLM2yelbTEIKUs=.6836cc21-2e32-40c8-a54d-c501de65ba40@github.com>
Message-ID: <CjtJwqbCeSA7oE3uIYpQkIpt2Z6NZ_Dp9t4lmZO0Bz4=.3d8422eb-09fc-4ea4-9205-3e78cd2d3a8b@github.com>

On Wed, 28 Jun 2023 19:42:21 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
>> Also tested with SwingSet2 .
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling value...
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   variable name change to match convention

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1503887873


From achung at openjdk.org  Wed Jun 28 20:20:06 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 28 Jun 2023 20:20:06 GMT
Subject: Integrated: 8296972: [macos13]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java:
 getExtendedState() != 6 as expected.
In-Reply-To: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
References: <uhjJcEpeUQ18IcLHLmtNmcRGSo9uqgWtNgzibcX4mGE=.fe11b033-995d-409b-8e8c-4ab541715f3b@github.com>
Message-ID: <n0wiMA3D2i0hSfXnuXlPwK5cssTg16aKsBGYj4kbTJg=.ebc690bd-234e-41a6-a378-aa7b471b118f@github.com>

On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung <achung at openjdk.org> wrote:

> added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize
> All client tests passed after change

This pull request has now been integrated.

Changeset: f0c2f098
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0c2f098150335fce736708354d58bae383cc4a1
Stats:     40 lines in 3 files changed: 38 ins; 1 del; 1 mod

8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected.

Reviewed-by: dmarkov, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/14226


From rmahajan at openjdk.org  Wed Jun 28 21:10:11 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 28 Jun 2023 21:10:11 GMT
Subject: Integrated: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <cDgpgvEIvBY4pKpzk6VvOW0sj4p8yu4ZUTMTfKLkgz4=.b4e40bab-bedf-4cfa-9d2d-5b6b2267ab1c@github.com>

On Thu, 27 Apr 2023 19:25:55 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and automated testing.
> Also tested with SwingSet2 .
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

This pull request has now been integrated.

Changeset: a63afa4a
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd
Stats:     198 lines in 5 files changed: 100 ins; 36 del; 62 mod

8294427: Check boxes and radio buttons have rendering issues on Windows in High DPI env

Reviewed-by: aivanov, achung

-------------

PR: https://git.openjdk.org/jdk/pull/13701


From duke at openjdk.org  Wed Jun 28 21:48:58 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 28 Jun 2023 21:48:58 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <aczaDANDVE57IOrmxBp6TJexgbwzv6Z5kX3ZnEkhWPw=.e20ff74f-073a-425d-b58e-044d5ea1ba0b@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> 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

Hi, guys! I want to notice that JetBrains is working on the issue too and we're going to propose our own fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1612148793


From duke at openjdk.org  Thu Jun 29 00:23:57 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Thu, 29 Jun 2023 00:23:57 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <aczaDANDVE57IOrmxBp6TJexgbwzv6Z5kX3ZnEkhWPw=.e20ff74f-073a-425d-b58e-044d5ea1ba0b@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <aczaDANDVE57IOrmxBp6TJexgbwzv6Z5kX3ZnEkhWPw=.e20ff74f-073a-425d-b58e-044d5ea1ba0b@github.com>
Message-ID: <A6Gy2KiMGlf6G2R7jhWefLd-Bvw-PBKvCdu9rTqyFkI=.f517e392-4290-4c47-9eb3-92f2ca36b129@github.com>

On Wed, 28 Jun 2023 21:46:30 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> ??? 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
>
> Hi, guys! I want to notice that JetBrains is working on the issue too and we're going to propose our own fix.

@NikitkoCent It's a good news. If you find any problem, you can try this example:
https://github.com/quantum6/X11InputMethod

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1612266440


From erikj at openjdk.org  Thu Jun 29 07:23:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 07:23:54 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <nuJPc-yjOE7DrniF-EEjhLk-HQOBXJs4Ju4rWV4xxpw=.29e0f50a-084f-4091-8d96-ef05ab41427b@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261


From dholmes at openjdk.org  Thu Jun 29 07:43:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 07:43:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

It also seems far too large and disruptive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676


From erikj at openjdk.org  Thu Jun 29 08:00:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 08:00:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <Jo4ev4ByTzxMNpDvKGyYL9G8TzbpVerc1YXde4iu_5Q=.afe5e6d2-63a5-4956-9d5c-17675789a051@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

The patch is leaving exactly one newline at the end of the file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091


From ngubarkov at openjdk.org  Thu Jun 29 08:31:07 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 29 Jun 2023 08:31:07 GMT
Subject: Integrated: 8305667: Some fonts installed in user directory are not
 detected on Windows
In-Reply-To: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
Message-ID: <UxoxwB5HuxKe1baj0SfzVsB9nj2GxAYlfsYM0Qw50D4=.8abcc76c-725b-493b-9351-a4dbf35676a3@github.com>

On Wed, 5 Apr 2023 17:03:45 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.

This pull request has now been integrated.

Changeset: f842ec48
Author:    Nikita Gubarkov <ngubarkov at openjdk.org>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f842ec48b1e24afd99ad06cb1310bd51d9b8bae4
Stats:     21 lines in 1 file changed: 6 ins; 8 del; 7 mod

8305667: Some fonts installed in user directory are not detected on Windows

Reviewed-by: avu, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13359


From lkorinth at openjdk.org  Thu Jun 29 08:58:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 08:58:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <z1LaNlMKfruphxc495xDHe2Ou64psUrXMobtiqqnqqk=.cdf515c9-2243-42ba-bea6-d24967ce3634@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.
>
> It also seems far too large and disruptive.

Do you still think it is too disruptive after Erik's explanation?  I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457


From asemenov at openjdk.org  Thu Jun 29 09:11:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Jun 2023 09:11:05 GMT
Subject: Integrated: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <RJfR256QMKuXBAiw1oWhHWImDH-oLic1q__QwUdR6OU=.fa227014-c5f4-4466-9677-a6061cf39c4a@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

This pull request has now been integrated.

Changeset: 98a954ee
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98a954eebc4f97dd16cb89bd4f1122952c8482ca
Stats:     20 lines in 6 files changed: 14 ins; 0 del; 6 mod

8308286: Fix clang warnings in linux code

Reviewed-by: avu, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/14033


From coleenp at openjdk.org  Thu Jun 29 12:03:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:03:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Why do we care about this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234


From dholmes at openjdk.org  Thu Jun 29 12:14:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:14:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398


From lkorinth at openjdk.org  Thu Jun 29 12:38:57 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 12:38:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
Message-ID: <vkPgWAbLJRXEPOQ0alkrWJ7Gv7jLDEF3ak1ipe9xxZw=.5b93f57d-7ddb-42fb-b41b-76f4e3193d78@github.com>

On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why do we care about this?

I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me.

And it does not look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390


From coleenp at openjdk.org  Thu Jun 29 12:42:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:42:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

You could fix your emacs functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245


From lkorinth at openjdk.org  Thu Jun 29 13:08:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 13:08:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
Message-ID: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>

On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

My changes look like this in the diff output

 }
-

Removal of the last newline would look like this:

-}
+}
\ No newline at end of file

(both with `git diff` and `git diff --unified`) 

I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641


From aivanov at openjdk.org  Thu Jun 29 13:45:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jun 2023 13:45:56 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
Message-ID: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>

On Mon, 19 Jun 2023 08:49:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 162:
>> 
>>> 160:             AccessibleContext ac = this.getAccessibleContext();
>>> 161:             if (ac != null && (comboBox.getSelectedItem() != null)) {
>>> 162:                 ac.setAccessibleName(comboBox.getSelectedItem().toString());
>> 
>> Are you sure that the toString() method always provides a valid string, and not a descriptive JSON or some other character set that is useless for a blind user?
>
> I tested several times, didn't get such kind of result and as per java docs toString method returns `a string representation of the object.` So, I think it will be a valid string.

An interesting question? it depends on the object.

At the same time, if I'm not mistaken, the renderer also uses `.toString()` to display an object. However, it's possible to set a custom renderer which may display an arbitrary property from an object.

Did you try to populate combo box with anything but `String` objects?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246636688


From aivanov at openjdk.org  Thu Jun 29 13:45:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jun 2023 13:45:59 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <zO9NicVkHfVsksIMle1Q4rEtEe5c-IKkSgltXrC5meQ=.b5352b96-f354-4ff8-9036-34aebb2908ef@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <cN-bfdWUf1O1c8M4_2Tpq_I-shD_4IFwJEPV2LwzOFE=.22502d28-fc65-40f6-90dc-cdb8804225a8@github.com>
 <o1wJgosBd6MqqsI2D_q7bVadH04FRIsUCV7WZWPV1GA=.53dbe234-5af1-44ba-bbac-7d9d67df4352@github.com>
 <CxO8LYLfchSjsd94DipVXzLW_Np8CtTE9_QCwreTWc0=.695f3aad-651b-4b8d-ae0f-a05af403219d@github.com>
 <zO9NicVkHfVsksIMle1Q4rEtEe5c-IKkSgltXrC5meQ=.b5352b96-f354-4ff8-9036-34aebb2908ef@github.com>
Message-ID: <EXLQxGfRXQ-qCTGeCq6LDmNSjGdgO1DnW8lff4layjE=.5a15fb22-6d7e-4ca7-afa9-328bad2c9bff@github.com>

On Wed, 21 Jun 2023 08:56:37 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I mean `getAccessibleChild(..., 1)` can still return null (when both `if`s of `case 1` resolve to false). Let's consider the following code:
>> 
>> public void doSmthWith(JComponent component, BasicComboBoxUI ui) {
>>     if (ui.getAccessibleChildrenCount(component) > 1) {
>>         // well, we have at least 2 components, so we can expect to get a valid object below
>>         final var ac = ui.getAccessibleChild(component, 1)
>>                                   .getAccessibleContext(); // <= possible NPE
>>         // ...
>>     }
>> }
>> 
>> 
>> I think we have to return 1 from `getAccessibleChildrenCount(...)` for the cases when `getAccessibleChild(..., 1)` returns `null`
>
> 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`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246631766


From aivanov at openjdk.org  Thu Jun 29 13:46:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jun 2023 13:46:06 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
Message-ID: <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>

On Mon, 19 Jun 2023 09:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1141:

> 1139:                 return(Accessible) popup;
> 1140:             }
> 1141:             break;

Why do you change indentation? To minimise the number of changed lines, please keep the existing indentation.

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 30:

> 28:  * @build PassFailJFrame
> 29:  * @requires (os.family == "mac")
> 30:  * @summary Verifies if JComboBox selected itemmagnifies using

Suggestion:

 * @summary Verifies if JComboBox selected item magnifies using

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 68:

> 66:                     frame.dispose();
> 67:                 }
> 68:             });

This is redundant, `PassFailJFrame` automatically handles disposing of windows which are added using the `addTestWindow` method.

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 77:

> 75:                 "Mango", "Pine Apple", "Banana"};
> 76:         JComboBox<String> comboBox = new JComboBox<String>(fruits);
> 77:         JPanel fruitPanel = new JPanel(new GridLayout(1,2));

Suggestion:

        JPanel fruitPanel = new JPanel(new GridLayout(1, 2));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246625361
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246637228
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246639497
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1246639809


From lkorinth at openjdk.org  Thu Jun 29 14:12:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 14:12:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
Message-ID: <pfRQFPE48dsB4zX-Rf7hnkzlyMzdctcY-veiO1KeN70=.bffbbead-ef44-461c-8362-21418c7db00e@github.com>

On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could fix your emacs functions.

It is a *very nice* feature of global-whitespace-cleanup-mode

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347


From coleenp at openjdk.org  Thu Jun 29 15:46:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 15:46:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <DR0fysIfEikX8EG5J7RlPyej6GFMsw-_WkeuS7pM6HM=.36fca2c0-54a4-4563-b40a-c626bc7e1587@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that.  That's a nice feature.  I object to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709


From lkorinth at openjdk.org  Thu Jun 29 16:55:05 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <azIQJToZ2tpGJTsICHpL96zs9mmHI3fW-laYwy3H-Xk=.99615245-24f9-4b95-b66d-eaba04c8318c@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This was not liked, I will close it.

I will possibly do it under another PR for the GC code.

Thanks for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703


From lkorinth at openjdk.org  Thu Jun 29 16:55:06 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:06 GMT
Subject: Withdrawn: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <Hsf1WhdMKL5I-3HmOkCZQJWI3MPIHPnFUpo_oMkZj6I=.1ca1f233-3eb8-4d1e-ae3e-eb19729dc1c9@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14698


From vdyakov at openjdk.org  Thu Jun 29 20:22:00 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Thu, 29 Jun 2023 20:22:00 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
Message-ID: <3d-C4sWOsSH-SI4xpU-7mHxj7ogdpnnlW3A3zxrqlJU=.da8710f8-474b-46c6-89c8-3b04f02d552f@github.com>

On Mon, 19 Jun 2023 09:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1613759027


From aivanov at openjdk.org  Thu Jun 29 20:46:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jun 2023 20:46:00 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
 <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>
Message-ID: <AlFpNBC_8-JjzXesXl1aPtA9W02Dy1382lubUBkTdwQ=.062a591d-4f44-44e3-a29f-b962ee1ecc5c@github.com>

On Thu, 29 Jun 2023 13:31:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1141:
> 
>> 1139:                 return(Accessible) popup;
>> 1140:             }
>> 1141:             break;
> 
> Why do you change indentation? To minimise the number of changed lines, please keep the existing indentation.

It's a matter of style.

The [old conventions](https://www.oracle.com/docs/tech/java/codeconventions.pdf)? suggest that `case` statements shouldn't be indented. The code followed this style.

[A latest draft](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html) which is often referred to explicitly states that `case` statements should be indented with four spaces and the statements inside should be be indented with additional four spaces.

The updated code follows the new style. Since you're updating the code in the `switch` statement, it's fine to change the indentation? provided we agree to *follow the new style*.

? The [HTML version for `switch` statement](https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#468) is completely *unreadable now*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247151681


From vdyakov at openjdk.org  Thu Jun 29 22:41:57 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Thu, 29 Jun 2023 22:41:57 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
Message-ID: <cKwory5x3Y6ruXW4TjuZ79juqDhA68Qdfhq-dFovNmE=.261bafda-fb47-4115-b8ee-493cd5560a23@github.com>

On Mon, 19 Jun 2023 09:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> 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.
>> 
>> This fix results in few JCK test failure and that may require modification. I have filed an issue against JCK ([JCK-7319423](https://bugs.openjdk.org/browse/JCK-7319423)).  
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

JCK challenge public bug https://bugs.openjdk.org/browse/JCK-7319452

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1613886491


From dholmes at openjdk.org  Fri Jun 30 01:24:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:24:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
 <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
Message-ID: <ufj18ITz-S_VgkscmrxacxLtfQB-4I5hpgs8c61kOmA=.15f34364-70ac-4279-8669-f01e109b8411@github.com>

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My changes look like this in the diff output
> ```
>  }
> -
> ```

Thanks for showing  this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636


From abhiscxk at openjdk.org  Fri Jun 30 07:42:07 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 07:42:07 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <v00SaCcqPfUeR3k7c9-d_-ZFJk77Fq4MyFM8fg1U_C4=.dec2b8a8-e0d5-4abf-a175-f4da97852298@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 four additional commits since the last revision:

 - 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/db0a35b7..1cdc34dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14497&range=01-02

  Stats: 16509 lines in 717 files changed: 8810 ins; 4008 del; 3691 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 Jun 30 07:42:10 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 07:42:10 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v2]
In-Reply-To: <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
 <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>
Message-ID: <YhcXpVyDEmFCk_ntj1PV9VwJ48KJqUzPkHDb83fYjC0=.5dee5cff-b795-4940-b7b7-5b3122e0218f@github.com>

On Thu, 29 Jun 2023 13:39:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 30:
> 
>> 28:  * @build PassFailJFrame
>> 29:  * @requires (os.family == "mac")
>> 30:  * @summary Verifies if JComboBox selected itemmagnifies using
> 
> Suggestion:
> 
>  * @summary Verifies if JComboBox selected item magnifies using

Updated.

> test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 68:
> 
>> 66:                     frame.dispose();
>> 67:                 }
>> 68:             });
> 
> This is redundant, `PassFailJFrame` automatically handles disposing of windows which are added using the `addTestWindow` method.

Updated.

> test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 77:
> 
>> 75:                 "Mango", "Pine Apple", "Banana"};
>> 76:         JComboBox<String> comboBox = new JComboBox<String>(fruits);
>> 77:         JPanel fruitPanel = new JPanel(new GridLayout(1,2));
> 
> Suggestion:
> 
>         JPanel fruitPanel = new JPanel(new GridLayout(1, 2));

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247540422
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247540469
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247540502


From abhiscxk at openjdk.org  Fri Jun 30 07:49:03 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 07:49:03 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
 <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>
Message-ID: <Asft0p_f5zgNQE27HzWu0LlQ9AsvbAg3EEQoQWjrtvI=.c68aa0c1-87c5-44cd-942a-e0bea03443b4@github.com>

On Thu, 29 Jun 2023 13:39:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I tested several times, didn't get such kind of result and as per java docs toString method returns `a string representation of the object.` So, I think it will be a valid string.
>
> An interesting question? it depends on the object.
> 
> At the same time, if I'm not mistaken, the renderer also uses `.toString()` to display an object. However, it's possible to set a custom renderer which may display an arbitrary property from an object.
> 
> Did you try to populate combo box with anything but `String` objects?

I tried with the `Integer` object and it works fine. Please suggest if anything else I can test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247548938


From abhiscxk at openjdk.org  Fri Jun 30 07:49:04 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 07:49:04 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <AlFpNBC_8-JjzXesXl1aPtA9W02Dy1382lubUBkTdwQ=.062a591d-4f44-44e3-a29f-b962ee1ecc5c@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <quTBd_Fm8mC5evP-WUTDbO7ylDlzHUfXfBeKrP9dVmA=.010a4971-9d9d-4761-be39-e2b86f0e01e2@github.com>
 <ZF_6cGYU9C0fJ1S1Nk_4rArTJRZ54VbJmkbft6IyY1g=.14863ec7-a2a8-42d6-bf0f-2cddadb2f937@github.com>
 <AlFpNBC_8-JjzXesXl1aPtA9W02Dy1382lubUBkTdwQ=.062a591d-4f44-44e3-a29f-b962ee1ecc5c@github.com>
Message-ID: <Nu5zolkS5WjFyUbWRhtbH3u4kdn02czbwH7vDL3HCgs=.331b85b0-a9e0-4007-9849-e0e21cb4cfad@github.com>

On Thu, 29 Jun 2023 20:43:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java line 1141:
>> 
>>> 1139:                 return(Accessible) popup;
>>> 1140:             }
>>> 1141:             break;
>> 
>> Why do you change indentation? To minimise the number of changed lines, please keep the existing indentation.
>
> It's a matter of style.
> 
> The [old conventions](https://www.oracle.com/docs/tech/java/codeconventions.pdf)? suggest that `case` statements shouldn't be indented. The code followed this style.
> 
> [A latest draft](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html) which is often referred to explicitly states that `case` statements should be indented with four spaces and the statements inside should be be indented with additional four spaces.
> 
> The updated code follows the new style. Since you're updating the code in the `switch` statement, it's fine to change the indentation? provided we agree to *follow the new style*.
> 
> ? The [HTML version for `switch` statement](https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#468) is completely *unreadable now*.

> It's a matter of style.
> 
> The [old conventions](https://www.oracle.com/docs/tech/java/codeconventions.pdf)? suggest that `case` statements shouldn't be indented. The code followed this style.
> 
> [A latest draft](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html) which is often referred to explicitly states that `case` statements should be indented with four spaces and the statements inside should be be indented with additional four spaces.
> 
> The updated code follows the new style. Since you're updating the code in the `switch` statement, it's fine to change the indentation? provided we agree to _follow the new style_.
> 
> ? The [HTML version for `switch` statement](https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#468) is completely _unreadable now_.

The indented code is more readable and as you pointed it is inline with new style too. So, I am ok with the current indentation if we are on same page.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247547737


From abhiscxk at openjdk.org  Fri Jun 30 09:08:53 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 09:08:53 GMT
Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus
In-Reply-To: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
References: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
Message-ID: <NasEKyv2ge-6R7H6__bMqyJHrKWqRak3rhYBGn2I5A0=.fc4e879c-4a59-4ebe-ae0b-1c532d9bf56a@github.com>

On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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)

Looks good to me.

-------------

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14596#pullrequestreview-1506820243


From mbaesken at openjdk.org  Fri Jun 30 10:02:01 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <Ykg6Amp7406I2u7bTQig2FG2o_g4ebNwgmWCgPOR_Ow=.2394846a-4734-4faf-8d38-77f05d98b95b@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 in src/java.sql/share/classes/java/sql/DriverManager.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/5d52b4cb..6665f60b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 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  Fri Jun 30 10:02:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
 <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
Message-ID: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>

On Wed, 28 Jun 2023 13:22:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>>> 
>>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
>> 
>> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.
>
> Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

Hi Alan, I adjusted the comment in DriverManager.java  .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1247686721


From alexsch at openjdk.org  Fri Jun 30 10:08:31 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 30 Jun 2023 10:08:31 GMT
Subject: RFR: 8311033: [macos] PrinterJob does not take into account Sides
 attribute
Message-ID: <-x_HMc_ircmNeuuzRlxELE1PFyLXKgqbq2O501iP4fY=.b479106e-2e5d-4f80-bdd9-4761c2d18260@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

-------------

Commit messages:
 - 8311033: [macos] PrinterJob does not take into account Sides attribute

Changes: https://git.openjdk.org/jdk/pull/14727/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311033
  Stats: 288 lines in 4 files changed: 288 ins; 0 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 abhiscxk at openjdk.org  Fri Jun 30 10:10:55 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 10:10:55 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: <ghcOvw5tidRcGRGqbBw50fEiRdDdBDzXNsNEsxunKoQ=.73e35a51-2fea-4dbf-ac0c-19bd060f3d01@github.com>
 <5sSYlicO5-4ngRFNT76NIquAhe_v6o0xM3GNeffHNtM=.8d202054-17bf-4fc1-b5c8-bb81cb0f9776@github.com>
Message-ID: <hMA2IiT_Zd8_dSWY9rVhvIXKvJn3aIMbBZ5-fe64c8M=.4b8e6369-2724-4b21-b0f0-01c699465e52@github.com>

On Fri, 23 Jun 2023 03:14:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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

Fix verified.

-------------

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14614#pullrequestreview-1506920908


From aivanov at openjdk.org  Fri Jun 30 10:41:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 Jun 2023 10:41:08 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <Asft0p_f5zgNQE27HzWu0LlQ9AsvbAg3EEQoQWjrtvI=.c68aa0c1-87c5-44cd-942a-e0bea03443b4@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
 <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>
 <Asft0p_f5zgNQE27HzWu0LlQ9AsvbAg3EEQoQWjrtvI=.c68aa0c1-87c5-44cd-942a-e0bea03443b4@github.com>
Message-ID: <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com>

On Fri, 30 Jun 2023 07:46:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> I tried with the `Integer` object and it works fine. Please suggest if anything else I can test.

Obviously, it does.

What about a custom object which doesn't override `toString`? Although this shouldn't be a problem either.

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.

How does `JTable` handle this kind of situation? Or `JList`? Swing relies on renderers which makes it capable of displaying an arbitrary object (it uses `toString` by default, if I'm not mistaken), a renderer could provide a custom view of an object in a cell, in a list.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247721381


From abhiscxk at openjdk.org  Fri Jun 30 11:18:56 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Jun 2023 11:18:56 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
 <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>
 <Asft0p_f5zgNQE27HzWu0LlQ9AsvbAg3EEQoQWjrtvI=.c68aa0c1-87c5-44cd-942a-e0bea03443b4@github.com>
 <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com>
Message-ID: <DYY-HpqbVWD0AIESaT21qi6mnKq68SIGhRnWXpadrHI=.16a700e8-30a6-4e2e-b8e7-e371553ac21c@github.com>

On Fri, 30 Jun 2023 10:38:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I tried with the `Integer` object and it works fine. Please suggest if anything else I can test.
>
>> I tried with the `Integer` object and it works fine. Please suggest if anything else I can test.
> 
> Obviously, it does.
> 
> What about a custom object which doesn't override `toString`? Although this shouldn't be a problem either.
> 
> 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.
> 
> How does `JTable` handle this kind of situation? Or `JList`? Swing relies on renderers which makes it capable of displaying an arbitrary object (it uses `toString` by default, if I'm not mistaken), a renderer could provide a custom view of an object in a cell, in a list.

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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1247750687


From mbaesken at openjdk.org  Fri Jun 30 11:37:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:37:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@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:

  remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/6665f60b..9b2232a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 dcubed at openjdk.org  Fri Jun 30 15:21:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 15:21:10 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Ending the file with a blank line? I would not have expected that at all.
I expect a single EOL at the end of the file; from a visual POV, the last
line of non-blank text ends with an EOL. No more, no less.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396


From aivanov at openjdk.org  Fri Jun 30 19:39:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 Jun 2023 19:39:59 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v3]
In-Reply-To: <DYY-HpqbVWD0AIESaT21qi6mnKq68SIGhRnWXpadrHI=.16a700e8-30a6-4e2e-b8e7-e371553ac21c@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <h7bMIRQVUGEE7zi2VSERxyjslfS0QVLOKATJjH00ZQQ=.282e8443-9265-48a0-a0fa-d38e86fc12be@github.com>
 <a_2NE8JEc8Y7clXly_lBeuwIe-esrRpZ3sPP4VWxryI=.32345935-3aeb-45b7-994a-eff7c9e54e08@github.com>
 <7iCmIUh-FecliqDYjP6Nxxz1BWdBupnKloNT0RU2KkE=.2c82b84d-3bbc-47b9-aefc-49065c41a143@github.com>
 <Asft0p_f5zgNQE27HzWu0LlQ9AsvbAg3EEQoQWjrtvI=.c68aa0c1-87c5-44cd-942a-e0bea03443b4@github.com>
 <-GJATDjlSyx24cwd2mR3kacGAGSKhnGcINfZn1H4qEM=.9a2834c9-38cb-42b6-ba79-a76fbba80374@github.com>
 <DYY-HpqbVWD0AIESaT21qi6mnKq68SIGhRnWXpadrHI=.16a700e8-30a6-4e2e-b8e7-e371553ac21c@github.com>
Message-ID: <IfEHPiSo9AlCSW65rWRbqTeEZFsAR8nqNqee9P_ZR7I=.f5423cd2-6aec-47be-bede-99f5b1da9c30@github.com>

On Fri, 30 Jun 2023 11:16:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1248224305


From dnguyen at openjdk.org  Fri Jun 30 20:32:54 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 30 Jun 2023 20:32:54 GMT
Subject: RFR: 6875229: Wrong placement of icons in JTabbedPane in Nimbus
In-Reply-To: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
References: <QdQENslyn-eP_UmH1Dwz6MLpZ_Z-Gn7vXc8ErWGNKBo=.afc6afee-9f95-4861-9d5c-5078e7e825c4@github.com>
Message-ID: <RBBcHANZLFpR1mHvsKdL950tstwoq3GSWIBr25jGqfQ=.efc13b97-b2cb-4aba-bad9-cd6cfa1266d2@github.com>

On Wed, 21 Jun 2023 15:36:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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 dnguyen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14596#pullrequestreview-1507856429


From honkar at openjdk.org  Fri Jun 30 22:39:05 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 Jun 2023 22:39:05 GMT
Subject: RFR: JDK-8302618: Problem typing uppercase letters with java.awt.Robot
 on Mac when moving mouse
Message-ID: <ZqhIYTFuyW36WTnzIX3oIqcYqZQ3F5OwsRvGstrIOdk=.d3ddc124-079a-483e-9f7a-17cf49443096@github.com>

**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. 

This issue is not restricted for the Shift modifier key and causes problems with other modifier keys too and sometimes 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. 

- CGEvent APIs were introduced in [jdk-9+130](https://github.com/openjdk/jdk/commit/0d7becfcb7568417afb9c19f2db24e7797afc1d6#diff-ad38f25bd9f72b45c5cca2ba7f7fc6743c4820e7aeb1bbf5d7802c9d4e0e1479).

- 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 the 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 all the test cases.

CASE 2 : Run the test in semi-automated mode. While the Robot in typing, manually move the mouse (without clicking/dragging). check if the test Passes or Fails.

CI Testing works as expected with the fix and does not break any existing Robot related tests.

-------------

Commit messages:
 - whitespace fix
 - test update
 - removed debug logs
 - test changes & allModifiersMask chnaged to static var
 - copyright header for test
 - localFlag fix, allModifiersMask added for correct flag bit calculation
 - initial test case added with debug logs
 - spacing
 - Dictionary implementation changes with NSLog
 - indent changes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ec45bd64...20f8fd07

Changes: https://git.openjdk.org/jdk/pull/14744/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302618
  Stats: 288 lines in 4 files changed: 284 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