From azvegint at openjdk.java.net  Tue Jun  1 11:41:20 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 1 Jun 2021 11:41:20 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <7BryfzAYMTSTa3s7_ETPQjiiIIWWC52RyMKurV_gjMc=.c89c3ed4-c701-4c5b-8ec6-9dd74f2a2a4f@github.com>

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

This fix most likely will require a CSR

test/jdk/java/awt/Window/WindowTitleVisibleTest/WindowTitleVisibleTestLinuxGnome.java line 111:

> 109:     private void captureTitleBarNotVisible() {
> 110:         runSwing( () -> {
> 111:             titleBarImageNotVisible = robot.createScreenCapture(titleBarBounds);

`createScreenCapture` does not require to be called on EDT.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+28651297+mkartashev at openjdk.java.net  Tue Jun  1 11:55:16 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Tue, 1 Jun 2021 11:55:16 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <7BryfzAYMTSTa3s7_ETPQjiiIIWWC52RyMKurV_gjMc=.c89c3ed4-c701-4c5b-8ec6-9dd74f2a2a4f@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <7BryfzAYMTSTa3s7_ETPQjiiIIWWC52RyMKurV_gjMc=.c89c3ed4-c701-4c5b-8ec6-9dd74f2a2a4f@github.com>
Message-ID: <BKAxNZz8aUmZ2zOrUjhFK1d9iXKiIbaUvRkjS2Qlwa8=.619a7f9e-97f8-4414-be90-cb35e1936304@github.com>

On Tue, 1 Jun 2021 11:38:49 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix most likely will require a CSR

There already is one linked from the enhancement: [JDK-8267308](https://bugs.openjdk.java.net/browse/JDK-8267308)

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From alanb at openjdk.java.net  Tue Jun  1 12:50:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 12:50:29 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <dVFpffOKyZHh8laXoFtu1wOUx8nLCS9d12qsoSUE5Bk=.632c4211-41df-40b4-8e07-ee8c3cb249f5@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the  middle of the declaration?

The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message.

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

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue Jun  1 15:06:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:06:41 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v7]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <DSVYh67KJe9RW8wMcOpG0R8F4Jx4HYzwW66XEV-EH1w=.cb0b76eb-c433-4ed1-bf62-e227082768f3@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

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

  rename setSecurityManagerDirect to implSetSecurityManager

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From javalists at cbfiddle.com  Tue Jun  1 15:10:35 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 1 Jun 2021 08:10:35 -0700
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <4cmV5nhNGYZNPcRlF5_3KQPY_FKZQBFvnqw-4RrY-wc=.262ebb56-0306-40f7-b486-59c034a1d5de@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <4cmV5nhNGYZNPcRlF5_3KQPY_FKZQBFvnqw-4RrY-wc=.262ebb56-0306-40f7-b486-59c034a1d5de@github.com>
Message-ID: <783B389F-67C3-4195-BECC-095A44487EED@cbfiddle.com>

Could the flashing problem be related to the timing problem described in JDK-8209329 <https://bugs.openjdk.java.net/browse/JDK-8209329>?

I have noticed occasional red flashes using Metal, which I suspect are caused by trying to render uninitialized data.
(I?m guessing that the red is a debugging aid provided by Apple. Previously, they used yellow.)


> On May 29, 2021, at 12:22 AM, Alexey Ushakov <avu at openjdk.java.net> wrote:
> 
> On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:
> 
>> Set black color for underlying window background to perform correct blending operations in metal with window surface destination
> 
> Looks like the second option won't work because the result of blending will still be mixed with the NSWindow background color. Also, I tried several more approaches (Use only rgb blending, make the layer opaque). They helped to resolve the test issues but caused regressions in other areas (SwingSet2 tree for example). So, now I think that the only working solution is presented here (to set the background color of the window) 
> 
>> Yes, looks like we have the flashing problem back. It seems more serious than this particular bug.
>> We have two options here:
>> 
>> 1. accept this behavior for metal (It would be not a problem if we implement  JDK-8265445)
>> 2. reimplement all the composing operations via shaders instead of using metal blending rules
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4206
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210601/4e09c548/attachment-0001.htm>

From weijun at openjdk.java.net  Tue Jun  1 15:21:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:21:33 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From alanb at openjdk.java.net  Tue Jun  1 16:05:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 16:05:29 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <M0Mj0BK_4OBlu3dwDgSWnaM8KDpkL0KxAJldFL7q-eY=.31a0aa64-5a69-42df-bf80-09b4e7a3c144@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4073

From azvegint at openjdk.java.net  Tue Jun  1 16:27:25 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 1 Jun 2021 16:27:25 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <nruA4TBpwEQ0lZ7tns4aMygxBCwgqSSToMkgThFwU9Y=.597ea7d5-b501-4777-b784-5cc5d78f98a4@github.com>

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From joehw at openjdk.java.net  Tue Jun  1 16:28:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Jun 2021 16:28:27 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <rwSPwilSFt5efKcqrbureXYq8SmLxHMgrE_psXV-S9A=.87124c9e-112f-4a4e-80de-26bfa32fa995@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4073

From serb at openjdk.java.net  Tue Jun  1 19:28:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 1 Jun 2021 19:28:43 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <ILpLRXt8y9ecZpGU0XuKic1UMAbWaiTJEbkXYz4wHy0=.94c21b2a-1468-41c1-9e82-9ceda06ede69@github.com>

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

Please check that the test code added in the JDK-8265005 can be adapted to verify this fix as well.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From serb at openjdk.java.net  Tue Jun  1 20:36:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 1 Jun 2021 20:36:10 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
Message-ID: <KwfoNvujsBstUpWzkTs_ffvmQKcoe2Nx9DoaaR5wdHI=.07c6ed5f-87b7-4daf-bec5-5cc5f1c71b75@github.com>

On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Set black color for underlying window background to perform correct blending operations in metal with window surface destination

I guess the bug happens when we blit our "layer" surface to the window? So there is no way to set a kind of "src" composite? Will it help if you "clear" the layer to some color(white?) and then immediately blit the content on top of it?

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jun  2 10:56:30 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 2 Jun 2021 10:56:30 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <ILpLRXt8y9ecZpGU0XuKic1UMAbWaiTJEbkXYz4wHy0=.94c21b2a-1468-41c1-9e82-9ceda06ede69@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <ILpLRXt8y9ecZpGU0XuKic1UMAbWaiTJEbkXYz4wHy0=.94c21b2a-1468-41c1-9e82-9ceda06ede69@github.com>
Message-ID: <ULrc6O4MTpOadwv_cEHpK8DB5lszbMo2HHv2e3aeCGg=.84ca18f8-2b91-4c35-a5c2-c18690a9143b@github.com>

On Tue, 1 Jun 2021 19:24:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please check that the test code added in the JDK-8265005 can be adapted to verify this fix as well.

@mrserb Please clarify: do you suggest to have one common test code for this feature and JDK-8265005? This is certainly possible, but will contaminate the Mac test with Linux-specific window manager checking stuff, making it harder to debug failures, I think.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From weijun at openjdk.java.net  Wed Jun  2 12:01:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:30 GMT
Subject: <AWT Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v9]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <HOkSwSOf7m0eP71_pjxacSX3FnXw8CbONP_DbY0mCno=.969b9543-c6d1-4001-afac-d8cb337fd60f@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed Jun  2 12:01:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:33 GMT
Subject: <AWT Dev> Integrated: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <PsbFcEhvCahb4zpsvIhOlxvAbJK7DTE3-umT3Nsn5dY=.fe038b5f-dc17-4d4f-a19b-ed8c238c7d58@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

This pull request has now been integrated.

Changeset: 6765f902
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats:     2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/4073

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:38 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:38 GMT
Subject: <AWT Dev> RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <PSyJvVFJ9ZdvF7KLSUwpd2ZUNj_zgTnlnfb894o0s2M=.3d72b382-7e1c-45b4-b704-541e57dfab0e@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

PR: https://git.openjdk.java.net/jdk/pull/4138

From pbansal at openjdk.java.net  Wed Jun  2 14:10:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 2 Jun 2021 14:10:48 GMT
Subject: <AWT Dev> RFR: 8264305: Create implementation for native
 accessibility peer for Statusbar java role
Message-ID: <4_Z-zcRCkPV2GtVvj9t0dSgxk8SU7tFtZZntHWzqHyo=.7170046f-b9b4-4831-9a46-fead96690f7c@github.com>

Create implementation for native accessibility peer for Statusbar java role. I do not see any Swing component with StatusBar accessibility role, so I have created a component with the StatusBar role to test this. I have tested the implementation with the following example and a few more similar examples. I do not see any difference in Voice Over output.
`  

    import javax.accessibility.Accessible;
    import javax.accessibility.AccessibleContext;
    import javax.accessibility.AccessibleRole;
    import javax.accessibility.AccessibleStateSet;
    import javax.swing.JFrame;
    import javax.swing.JLabel;
    import javax.swing.JPanel;
    import javax.swing.SwingUtilities;
    import javax.swing.Timer;
    import javax.swing.border.BevelBorder;
    import java.awt.BorderLayout;
    import java.awt.Color;
    import java.awt.Dimension;
    import java.awt.event.ActionEvent;
    import java.awt.event.ActionListener;
    import java.text.DateFormat;

    public class StatusBarDemo {

        public static void main(String[] args) throws Exception {
            StatusBarDemo demo = new StatusBarDemo();
            SwingUtilities.invokeAndWait(demo::createAndShowGUI);
        }

        void createAndShowGUI() {
            JFrame jframe = new JFrame("StatusBar Demo");
            jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            jframe.setLayout(new BorderLayout());
            jframe.setSize(200, 200);

            // create the status bar panel and shove it down the bottom of the frame
            JPanel statusPanel = new StatusBar();
            statusPanel.setBorder(new BevelBorder(BevelBorder.LOWERED));
            statusPanel.setPreferredSize(new Dimension(jframe.getWidth(), 16));
            statusPanel.setLayout(new BorderLayout());

            JLabel date = new JLabel();
            date.setOpaque(true);
            date.setBackground(Color.black);
            date.setForeground(Color.WHITE);
            statusPanel.setLayout(new BorderLayout());
            statusPanel.setBackground(Color.LIGHT_GRAY);
            statusPanel.add(date, BorderLayout.CENTER);


            Timer timer = new javax.swing.Timer(1000, new ActionListener() {
                @Override
                public void actionPerformed(ActionEvent e) {
                    java.util.Date now = new java.util.Date();
                    String ss = DateFormat.getDateTimeInstance().format(now);
                    date.setText(ss);
                    date.setToolTipText("Welcome, Today is " + ss);

                }
            });

            timer.start();

            jframe.add(statusPanel, BorderLayout.SOUTH);

            jframe.setLocationRelativeTo(null);
            jframe.setVisible(true);
        }

        class StatusBar extends JPanel implements Accessible {

            AccessibleContext accessibleContext;

            public AccessibleContext getAccessibleContext() {
                if (accessibleContext == null) {
                    accessibleContext = new StatusBar.AccessibleJStatusBar();
                }
                return accessibleContext;
            }

            protected class AccessibleJStatusBar extends AccessibleJComponent {
                public AccessibleStateSet getAccessibleStateSet() {
                    AccessibleStateSet states = super.getAccessibleStateSet();
                    return states;
                }
                public AccessibleRole getAccessibleRole() {
                    return AccessibleRole.STATUS_BAR;
                }
            }
        }
    }


`

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

Commit messages:
 - 8264305: Create implementation for native accessibility peer for Statusbar java role

Changes: https://git.openjdk.java.net/jdk/pull/4307/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4307&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264305
  Stats: 41 lines in 3 files changed: 39 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4307/head:pull/4307

PR: https://git.openjdk.java.net/jdk/pull/4307

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 14:19:42 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 14:19:42 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
Message-ID: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>

There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

Commit messages:
 - 8268113: Re-use Long.hashCode() where possible

Changes: https://git.openjdk.java.net/jdk/pull/4309/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268113
  Stats: 10 lines in 7 files changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 14:19:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 14:19:43 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>

On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

src/java.base/share/classes/java/util/BitSet.java line 1040:

> 1038:             h ^= words[i] * (i + 1);
> 1039: 
> 1040:         return Long.hashCode(h);

Here `>>` instead of `>>>` in original code seems to be a typo

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+7806504+liach at openjdk.java.net  Wed Jun  2 14:54:31 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Wed, 2 Jun 2021 14:54:31 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <iwzs-BHBLELnoCif1WMC5_Np_O1VqzQxEaTmQJhsts8=.8034416f-f6cb-446b-9067-4e1e246f49fe@github.com>

On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

src/java.base/share/classes/java/lang/Double.java line 881:

> 879:     public static int hashCode(double value) {
> 880:         long bits = doubleToLongBits(value);
> 881:         return Long.hashCode(bits);

Imo these should be squashed to just 

return Long.hashCode(doubleToLongBits(value));

since the local variable is no longer meaningful. Previously, they were required as they were retrieved twice in hash code calculation.

Same for other usages.

src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java line 115:

> 113:         public int hashCode() {
> 114:             final long bits = Double.doubleToLongBits(doubleValue);
> 115:             return Long.hashCode(bits);

This one and the `DoubleDV` one should actually delegate to `Double.hashCode`, which delegates to `Long.hashCode` after this change.

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From weijun at openjdk.java.net  Wed Jun  2 15:40:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:40:55 GMT
Subject: <AWT Dev> RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v4]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <iWLNwxV2CvTVXj57-NbeWHor64Ab3P7461jOk1XxoJ0=.91556668-25eb-40b4-afae-730f9c1d621f@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8267521: Post JEP 411 refactoring: maximum covering > 50K

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

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Wed Jun  2 15:51:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:33 GMT
Subject: <AWT Dev> Integrated: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <zkd_bofYu1MISkzzGFuI8utKnvp_M7M4icu-ws3be7k=.d7621e87-5890-492f-a64a-187e1f9eb9ed@github.com>

On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 508cec75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats:     245 lines in 18 files changed: 140 ins; 39 del; 66 mod

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

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

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 16:31:56 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 16:31:56 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v2]
In-Reply-To: <iwzs-BHBLELnoCif1WMC5_Np_O1VqzQxEaTmQJhsts8=.8034416f-f6cb-446b-9067-4e1e246f49fe@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <iwzs-BHBLELnoCif1WMC5_Np_O1VqzQxEaTmQJhsts8=.8034416f-f6cb-446b-9067-4e1e246f49fe@github.com>
Message-ID: <R9BnT2zMSBJc1tJbLGDU3OJRV0WopCPq5zOz-Y9AZA0=.f5c97387-836a-479a-b839-dfdccc752181@github.com>

On Wed, 2 Jun 2021 14:51:35 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8268113: Delegate to Double.hashCode()
>
> src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java line 115:
> 
>> 113:         public int hashCode() {
>> 114:             final long bits = Double.doubleToLongBits(doubleValue);
>> 115:             return Long.hashCode(bits);
> 
> This one and the `DoubleDV` one should actually delegate to `Double.hashCode`, which delegates to `Long.hashCode` after this change.

Good point, done!

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 16:31:55 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 16:31:55 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v2]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <R7QLU7YkKu9xDjGiJ530O3COI4nKHtUW9O-7OE49cMU=.08736e98-47ee-47a1-a026-89f7fb927a39@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

  8268113: Delegate to Double.hashCode()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/9c7ddc0c..3f5b431d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 16:37:51 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 16:37:51 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v3]
In-Reply-To: <iwzs-BHBLELnoCif1WMC5_Np_O1VqzQxEaTmQJhsts8=.8034416f-f6cb-446b-9067-4e1e246f49fe@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <iwzs-BHBLELnoCif1WMC5_Np_O1VqzQxEaTmQJhsts8=.8034416f-f6cb-446b-9067-4e1e246f49fe@github.com>
Message-ID: <NsK_-cZySGW7iEFqmlfOx2m3-U1sxXrj2vZeeUnnvPs=.84143747-d762-42d2-915a-9ea43ccb0ed0@github.com>

On Wed, 2 Jun 2021 14:50:23 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8268113: Inline local vars where reasonable
>
> src/java.base/share/classes/java/lang/Double.java line 881:
> 
>> 879:     public static int hashCode(double value) {
>> 880:         long bits = doubleToLongBits(value);
>> 881:         return Long.hashCode(bits);
> 
> Imo these should be squashed to just 
> 
> return Long.hashCode(doubleToLongBits(value));
> 
> since the local variable is no longer meaningful. Previously, they were required as they were retrieved twice in hash code calculation.
> 
> Same for other usages.

Done!

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 16:37:49 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 16:37:49 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v3]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <W6aTlT8rjKY9SNxxH4VMg31R4yLZKtwbgU-pRSyPF60=.56c6035f-6b6e-42bc-9899-c5503f871c66@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

  8268113: Inline local vars where reasonable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/3f5b431d..df8be00a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From vtewari at openjdk.java.net  Wed Jun  2 18:01:29 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Wed, 2 Jun 2021 18:01:29 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v3]
In-Reply-To: <W6aTlT8rjKY9SNxxH4VMg31R4yLZKtwbgU-pRSyPF60=.56c6035f-6b6e-42bc-9899-c5503f871c66@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <W6aTlT8rjKY9SNxxH4VMg31R4yLZKtwbgU-pRSyPF60=.56c6035f-6b6e-42bc-9899-c5503f871c66@github.com>
Message-ID: <pA1IITG3c_dRJXwxfIbrok-8Hz-ItsGs8vJMiVvOe4k=.70df8a69-d42b-4dee-bf54-e2a94482c164@github.com>

On Wed, 2 Jun 2021 16:37:49 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268113: Inline local vars where reasonable

src/java.base/share/classes/java/util/BitSet.java line 105:

> 103:      * the user knows what he's doing and try harder to preserve it.
> 104:      */
> 105:     private transient boolean sizeIsSticky = false;

This change is OK, but it is not related to "8268113", do you really wants to  do these changes as part of "8268113" ?

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  2 18:36:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 2 Jun 2021 18:36:28 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v3]
In-Reply-To: <pA1IITG3c_dRJXwxfIbrok-8Hz-ItsGs8vJMiVvOe4k=.70df8a69-d42b-4dee-bf54-e2a94482c164@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <W6aTlT8rjKY9SNxxH4VMg31R4yLZKtwbgU-pRSyPF60=.56c6035f-6b6e-42bc-9899-c5503f871c66@github.com>
 <pA1IITG3c_dRJXwxfIbrok-8Hz-ItsGs8vJMiVvOe4k=.70df8a69-d42b-4dee-bf54-e2a94482c164@github.com>
Message-ID: <pZinB0MiN1l0lX2hCKSZYWZamvPI6EkYR8zyFr60OZs=.6842ee22-9e6a-49cc-b804-5987bb6af9c2@github.com>

On Wed, 2 Jun 2021 17:58:29 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8268113: Inline local vars where reasonable
>
> src/java.base/share/classes/java/util/BitSet.java line 105:
> 
>> 103:      * the user knows what he's doing and try harder to preserve it.
>> 104:      */
>> 105:     private transient boolean sizeIsSticky = false;
> 
> This change is OK, but it is not related to "8268113", do you really wants to  do these changes as part of "8268113" ?

This is just a tiny code clean-up, so I think it's ok to go

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

PR: https://git.openjdk.java.net/jdk/pull/4309

From serb at openjdk.java.net  Wed Jun  2 20:53:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 2 Jun 2021 20:53:39 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <Skip7QE1hxhyIi7zJRCgAPsn0EU9uVSk8Qj1sbEgHIg=.881963b5-175c-4f6c-b4ed-cd2b6568ac98@github.com>

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

You can reuse that test or create the new one, I just pointed out how the "same" feature was tested on mac.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From kcr at openjdk.java.net  Thu Jun  3 12:15:39 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 3 Jun 2021 12:15:39 GMT
Subject: <AWT Dev> RFR: 8256465: [macos11] Java frame and dialog
 presented full screen freeze application [v8]
In-Reply-To: <F37seqFvMv0fgFDdwUrpvdD-JjE3fZm9ZCMCsQzoCJw=.b9d53a29-65f6-4d60-b89f-ecda2fa44974@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <F37seqFvMv0fgFDdwUrpvdD-JjE3fZm9ZCMCsQzoCJw=.b9d53a29-65f6-4d60-b89f-ecda2fa44974@github.com>
Message-ID: <kWOAbdHyVGt5qK8Ltgnz5ZbAvEx4yJ3F5zBS9BV81J8=.d56fee5b-4bc9-414e-b063-617616f9d411@github.com>

On Mon, 31 May 2021 14:05:51 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
>> It doesn't freeze when the Prefer tabs is set to "never".
>> 
>> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
>> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
>> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
>> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
>> 
>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
>> 
>> Test : Added a manual test and tested on MacOS 10.15 and 11.
>> All the internal tests run are green.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the comment

The fix looks fine, although you need to merge in the latest changes from the jdk master and add the now-required annotation to ignore the security manager deprecation warning (else it will fail to compile). I left a couple comments on the test as well.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 132:

> 130:     // This system property is named as jdk.* because it is not specific to AWT
> 131:     // and it is also used in JavaFX
> 132:     public static final String MAC_OS_TABBED_WINDOW = AccessController.doPrivileged(

Now that the fix for JEP 411 (security manager deprecation) is integrated, you will need to add the following annotation to this field, else it will fail to compile:


    @SuppressWarnings("removal")

test/jdk/java/awt/Window/TestAppFreeze.java line 64:

> 62:     private static void createInstructionUI() {
> 63:         SwingUtilities.invokeLater(() -> {
> 64:             String instruction = "1. This test is only for Mac OS Version 11 " +

This bug also affects macOS 10.15. On 10.15 the "Prefer Tabs" setting in the `System Preferences -> Dock` rather than `-> General`.

test/jdk/java/awt/Window/TestAppFreeze.java line 107:

> 105:     private static void testApp() {
> 106:         testFrame = new JFrame("TestFrame");
> 107:         testFrame.setBounds(600,0,1000,200);

Minor: add spaces after the commas.

test/jdk/java/awt/Window/TestAppFreeze.java line 110:

> 108:         testFrame.getContentPane().add(new JButton(new AbstractAction("Click") {
> 109:             @Override
> 110:             public void actionPerformed(ActionEvent e) {

Minor: you can use a lambda here if you like.

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

Changes requested by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3407

From alexey.ushakov at jetbrains.com  Thu Jun  3 12:35:45 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 3 Jun 2021 15:35:45 +0300
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <nruA4TBpwEQ0lZ7tns4aMygxBCwgqSSToMkgThFwU9Y=.597ea7d5-b501-4777-b784-5cc5d78f98a4@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <nruA4TBpwEQ0lZ7tns4aMygxBCwgqSSToMkgThFwU9Y=.597ea7d5-b501-4777-b784-5cc5d78f98a4@github.com>
Message-ID: <044924E7-7944-460C-B624-2EC3F0FF537D@jetbrains.com>

Could anyone from the dev team review my CSR request for this change: https://bugs.openjdk.java.net/browse/JDK-8267308 <https://bugs.openjdk.java.net/browse/JDK-8267308> ?

Best Regards,
Alexey

> On 1 Jun 2021, at 19:27, Alexander Zvegintsev <azvegint at openjdk.java.net> wrote:
> 
> On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:
> 
>> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.
> 
> Marked as reviewed by azvegint (Reviewer).
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4113

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210603/d76006ac/attachment.htm>

From trebari at openjdk.java.net  Thu Jun  3 12:51:27 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 3 Jun 2021 12:51:27 GMT
Subject: <AWT Dev> RFR: 8256465: [macos11] Java frame and dialog
 presented full screen freeze application [v9]
In-Reply-To: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
Message-ID: <VRFYg6TMtO7LtSn0_hKG1PajwSPLacmREYBtA5LSHXQ=.039ac76e-b45d-4ef6-b1ff-6844adee2dcb@github.com>

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
> It doesn't freeze when the Prefer tabs is set to "never".
> 
> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
> 
> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
> 
> Test : Added a manual test and tested on MacOS 10.15 and 11.
> All the internal tests run are green.

Tejpal Rebari 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 11 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8256465
 - updated the comment
 - make string final
 - doPrivileged to the system.getproperty
 - addressed review comments
 - made changed according to CSR comments
 - initialize in static block added doprivilged and removed @available
 - code cleanup
 - Merge remote-tracking branch 'upstream/master' into 8256465
 - add system property
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/6fe46985...28752a2c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3407/files
  - new: https://git.openjdk.java.net/jdk/pull/3407/files/7fbb729e..28752a2c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=07-08

  Stats: 129126 lines in 4462 files changed: 46743 ins; 68014 del; 14369 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3407/head:pull/3407

PR: https://git.openjdk.java.net/jdk/pull/3407

From avu at openjdk.java.net  Thu Jun  3 14:04:40 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 3 Jun 2021 14:04:40 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <KwfoNvujsBstUpWzkTs_ffvmQKcoe2Nx9DoaaR5wdHI=.07c6ed5f-87b7-4daf-bec5-5cc5f1c71b75@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <KwfoNvujsBstUpWzkTs_ffvmQKcoe2Nx9DoaaR5wdHI=.07c6ed5f-87b7-4daf-bec5-5cc5f1c71b75@github.com>
Message-ID: <d2H40j0EIu5-21FXjoPPJ5aB1JJcYa3aR-TakrwEl4g=.1b37c552-f2ff-47fa-98af-b3ef48c5009d@github.com>

On Tue, 1 Jun 2021 20:32:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I guess the bug happens when we blit our "layer" surface to the window? So there is no way to set a kind of "src" composite? 

AFAIK, we don't have any control over composing the layer content on top of the window surface. We just get drawable for the layer that has a texture attached and then blits our content into it.

> Will it help if you "clear" the layer to some color(white?) and then immediately blit the content on top of it?


In current implementation - no. We use a blitencoder that just replaces pixels at the texture attached to the drawable. Texture rendering also won't help as we still blend the resulting color with the window surface. See MTLLayer.m (80-133) for more details.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From avu at openjdk.java.net  Thu Jun  3 14:13:38 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 3 Jun 2021 14:13:38 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
Message-ID: <xJJgyBNr26GB0PH0aot_L4TmyFbQBNqp87Fzxwe0BJE=.b1638f0f-6bf0-4902-b4f8-1460193dae31@github.com>

On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Set black color for underlying window background to perform correct blending operations in metal with window surface destination

> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [awt-dev](mailto:awt-dev at mail.openjdk.java.net):_
> 
> Could the flashing problem be related to the timing problem described in JDK-8209329 <https://bugs.openjdk.java.net/browse/JDK-8209329>?
> 
> I have noticed occasional red flashes using Metal, which I suspect are caused by trying to render uninitialized data.
> (I?m guessing that the red is a debugging aid provided by Apple. Previously, they used yellow.)
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210601/4e09c548/attachment-0001.htm>

Yes, blit encoder works asynchronously so we may have some latency before the actual content is presented to the window.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From javalists at cbfiddle.com  Thu Jun  3 14:31:04 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 3 Jun 2021 07:31:04 -0700
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <xJJgyBNr26GB0PH0aot_L4TmyFbQBNqp87Fzxwe0BJE=.b1638f0f-6bf0-4902-b4f8-1460193dae31@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <xJJgyBNr26GB0PH0aot_L4TmyFbQBNqp87Fzxwe0BJE=.b1638f0f-6bf0-4902-b4f8-1460193dae31@github.com>
Message-ID: <E54791D5-92A4-4CBE-A58C-FC7EEE5E83F6@cbfiddle.com>

My concern is that these latency problems are much more noticeable when the Metal pipeline is used.

See JDK-8267226 <https://bugs.openjdk.java.net/browse/JDK-8267226>.

  Alan



> On Jun 3, 2021, at 7:13 AM, Alexey Ushakov <avu at openjdk.java.net> wrote:
> 
> On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:
> 
>> Set black color for underlying window background to perform correct blending operations in metal with window surface destination
> 
>> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [awt-dev](mailto:awt-dev at mail.openjdk.java.net):_
>> 
>> Could the flashing problem be related to the timing problem described in JDK-8209329 <https://bugs.openjdk.java.net/browse/JDK-8209329>?
>> 
>> I have noticed occasional red flashes using Metal, which I suspect are caused by trying to render uninitialized data.
>> (I?m guessing that the red is a debugging aid provided by Apple. Previously, they used yellow.)
>> 
> 
> Yes, blit encoder works asynchronously so we may have some latency before the actual content is presented to the window.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210603/75f93f87/attachment.htm>

From trebari at openjdk.java.net  Thu Jun  3 16:07:42 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 3 Jun 2021 16:07:42 GMT
Subject: <AWT Dev> RFR: 8256465: [macos11] Java frame and dialog
 presented full screen freeze application [v8]
In-Reply-To: <kWOAbdHyVGt5qK8Ltgnz5ZbAvEx4yJ3F5zBS9BV81J8=.d56fee5b-4bc9-414e-b063-617616f9d411@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <F37seqFvMv0fgFDdwUrpvdD-JjE3fZm9ZCMCsQzoCJw=.b9d53a29-65f6-4d60-b89f-ecda2fa44974@github.com>
 <kWOAbdHyVGt5qK8Ltgnz5ZbAvEx4yJ3F5zBS9BV81J8=.d56fee5b-4bc9-414e-b063-617616f9d411@github.com>
Message-ID: <sjJ9DId6v-pYi5dN3MKU4owgt6F4Mhp50rbvb2LdGls=.4c850fa0-a659-4012-b9dd-e7d85e2f8a3d@github.com>

On Thu, 3 Jun 2021 11:48:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the comment
>
> test/jdk/java/awt/Window/TestAppFreeze.java line 64:
> 
>> 62:     private static void createInstructionUI() {
>> 63:         SwingUtilities.invokeLater(() -> {
>> 64:             String instruction = "1. This test is only for Mac OS Version 11 " +
> 
> This bug also affects macOS 10.15. On 10.15 the "Prefer Tabs" setting in the `System Preferences -> Dock` rather than `-> General`.

Yeah, i think it will affect Mac OS 10.12.+  as the tabbedWindows was introduced in 10.12 , i have checked it affects the 10.14 , don't have earlier version to check.

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From trebari at openjdk.java.net  Thu Jun  3 16:55:12 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 3 Jun 2021 16:55:12 GMT
Subject: <AWT Dev> RFR: 8256465: [macos11] Java frame and dialog
 presented full screen freeze application [v10]
In-Reply-To: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
Message-ID: <wwiVp0YZwraqWWi1da-dJThbV78MIl91eTRd0t8fVu8=.d2423daf-1d02-4643-9e85-120d70c951e6@github.com>

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
> It doesn't freeze when the Prefer tabs is set to "never".
> 
> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
> 
> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
> 
> Test : Added a manual test and tested on MacOS 10.15 and 11.
> All the internal tests run are green.

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

  add SupressWarnings and test changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3407/files
  - new: https://git.openjdk.java.net/jdk/pull/3407/files/28752a2c..d710f761

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=08-09

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From serb at openjdk.java.net  Thu Jun  3 18:43:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 18:43:35 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <d2H40j0EIu5-21FXjoPPJ5aB1JJcYa3aR-TakrwEl4g=.1b37c552-f2ff-47fa-98af-b3ef48c5009d@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <KwfoNvujsBstUpWzkTs_ffvmQKcoe2Nx9DoaaR5wdHI=.07c6ed5f-87b7-4daf-bec5-5cc5f1c71b75@github.com>
 <d2H40j0EIu5-21FXjoPPJ5aB1JJcYa3aR-TakrwEl4g=.1b37c552-f2ff-47fa-98af-b3ef48c5009d@github.com>
Message-ID: <CRODRMthsCtYRR2SIS8rOuJrTXlM9DOJjdD2tj3mdDw=.6b8a429f-4e66-437f-b6ff-efd34c5a2480@github.com>

On Thu, 3 Jun 2021 13:59:57 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> AFAIK, we don't have any control over composing the layer content on top of the window surface. We just get drawable for the layer that has a texture attached and then blits our content into it.

Probably I missed your point, but there is no issue if we draw opaque color to the layer. Since it does not matter what kind of blending is used when we blit layer to nswindow and the layer has an opaque color. Why we cannot emulate the same when the app draws some transparency and use some blending? Just fill the layer with the opaque "default" color(or make it "opaque"), blend the transparent color on top of it and then blit this opaque result to the window.

Its is actually a question why the mtl layer is initialised as opaque=false in all cases.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From avu at openjdk.java.net  Thu Jun  3 19:00:57 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 3 Jun 2021 19:00:57 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <CRODRMthsCtYRR2SIS8rOuJrTXlM9DOJjdD2tj3mdDw=.6b8a429f-4e66-437f-b6ff-efd34c5a2480@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <KwfoNvujsBstUpWzkTs_ffvmQKcoe2Nx9DoaaR5wdHI=.07c6ed5f-87b7-4daf-bec5-5cc5f1c71b75@github.com>
 <d2H40j0EIu5-21FXjoPPJ5aB1JJcYa3aR-TakrwEl4g=.1b37c552-f2ff-47fa-98af-b3ef48c5009d@github.com>
 <CRODRMthsCtYRR2SIS8rOuJrTXlM9DOJjdD2tj3mdDw=.6b8a429f-4e66-437f-b6ff-efd34c5a2480@github.com>
Message-ID: <oV4yyD6LNJhVhieXUrDEeCruG3qUhn6-44qH9qfzZ3M=.a1de0cc7-231a-45a7-b482-55c15ec08504@github.com>

On Thu, 3 Jun 2021 18:40:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > AFAIK, we don't have any control over composing the layer content on top of the window surface. We just get drawable for the layer that has a texture attached and then blits our content into it.
> 
> Probably I missed your point, but there is no issue if we draw opaque color to the layer. Since it does not matter what kind of blending is used when we blit layer to nswindow and the layer has an opaque color. Why we cannot emulate the same when the app draws some transparency and use some blending? Just fill the layer with the opaque "default" color(or make it "opaque"), blend the transparent color on top of it and then blit this opaque result to the window.
> 
> Its is actually a question why the mtl layer is initialised as opaque=false in all cases.

Yes, this approach (make MTLLayer opaque) works for this particular test but it causes artifacts in SwingSet demo. It prevents me from implementing the fix that way. Probably, there is another rendering problem that is masked by making the layer transparent.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From kizune at openjdk.java.net  Fri Jun  4 03:12:54 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 4 Jun 2021 03:12:54 GMT
Subject: <AWT Dev> RFR: 8264305: Create implementation for native
 accessibility peer for Statusbar java role
In-Reply-To: <4_Z-zcRCkPV2GtVvj9t0dSgxk8SU7tFtZZntHWzqHyo=.7170046f-b9b4-4831-9a46-fead96690f7c@github.com>
References: <4_Z-zcRCkPV2GtVvj9t0dSgxk8SU7tFtZZntHWzqHyo=.7170046f-b9b4-4831-9a46-fead96690f7c@github.com>
Message-ID: <PFAFCmxDRUmzFDprCebVeOrccQa8DM1oTJxtEllN3OE=.cd2377ae-25fd-4172-9c3c-4d199bd79d25@github.com>

On Wed, 2 Jun 2021 13:58:24 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Create implementation for native accessibility peer for Statusbar java role. I do not see any Swing component with StatusBar accessibility role, so I have created a component with the StatusBar role to test this. I have tested the implementation with the following example and a few more similar examples. I do not see any difference in Voice Over output.
> `  
> 
>     import javax.accessibility.Accessible;
>     import javax.accessibility.AccessibleContext;
>     import javax.accessibility.AccessibleRole;
>     import javax.accessibility.AccessibleStateSet;
>     import javax.swing.JFrame;
>     import javax.swing.JLabel;
>     import javax.swing.JPanel;
>     import javax.swing.SwingUtilities;
>     import javax.swing.Timer;
>     import javax.swing.border.BevelBorder;
>     import java.awt.BorderLayout;
>     import java.awt.Color;
>     import java.awt.Dimension;
>     import java.awt.event.ActionEvent;
>     import java.awt.event.ActionListener;
>     import java.text.DateFormat;
> 
>     public class StatusBarDemo {
> 
>         public static void main(String[] args) throws Exception {
>             StatusBarDemo demo = new StatusBarDemo();
>             SwingUtilities.invokeAndWait(demo::createAndShowGUI);
>         }
> 
>         void createAndShowGUI() {
>             JFrame jframe = new JFrame("StatusBar Demo");
>             jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             jframe.setLayout(new BorderLayout());
>             jframe.setSize(200, 200);
> 
>             // create the status bar panel and shove it down the bottom of the frame
>             JPanel statusPanel = new StatusBar();
>             statusPanel.setBorder(new BevelBorder(BevelBorder.LOWERED));
>             statusPanel.setPreferredSize(new Dimension(jframe.getWidth(), 16));
>             statusPanel.setLayout(new BorderLayout());
> 
>             JLabel date = new JLabel();
>             date.setOpaque(true);
>             date.setBackground(Color.black);
>             date.setForeground(Color.WHITE);
>             statusPanel.setLayout(new BorderLayout());
>             statusPanel.setBackground(Color.LIGHT_GRAY);
>             statusPanel.add(date, BorderLayout.CENTER);
> 
> 
>             Timer timer = new javax.swing.Timer(1000, new ActionListener() {
>                 @Override
>                 public void actionPerformed(ActionEvent e) {
>                     java.util.Date now = new java.util.Date();
>                     String ss = DateFormat.getDateTimeInstance().format(now);
>                     date.setText(ss);
>                     date.setToolTipText("Welcome, Today is " + ss);
> 
>                 }
>             });
> 
>             timer.start();
> 
>             jframe.add(statusPanel, BorderLayout.SOUTH);
> 
>             jframe.setLocationRelativeTo(null);
>             jframe.setVisible(true);
>         }
> 
>         class StatusBar extends JPanel implements Accessible {
> 
>             AccessibleContext accessibleContext;
> 
>             public AccessibleContext getAccessibleContext() {
>                 if (accessibleContext == null) {
>                     accessibleContext = new StatusBar.AccessibleJStatusBar();
>                 }
>                 return accessibleContext;
>             }
> 
>             protected class AccessibleJStatusBar extends AccessibleJComponent {
>                 public AccessibleStateSet getAccessibleStateSet() {
>                     AccessibleStateSet states = super.getAccessibleStateSet();
>                     return states;
>                 }
>                 public AccessibleRole getAccessibleRole() {
>                     return AccessibleRole.STATUS_BAR;
>                 }
>             }
>         }
>     }
> 
> 
> `

Marked as reviewed by kizune (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4307

From pbansal at openjdk.java.net  Fri Jun  4 05:22:04 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 4 Jun 2021 05:22:04 GMT
Subject: <AWT Dev> Integrated: 8264305: Create implementation for native
 accessibility peer for Statusbar java role
In-Reply-To: <4_Z-zcRCkPV2GtVvj9t0dSgxk8SU7tFtZZntHWzqHyo=.7170046f-b9b4-4831-9a46-fead96690f7c@github.com>
References: <4_Z-zcRCkPV2GtVvj9t0dSgxk8SU7tFtZZntHWzqHyo=.7170046f-b9b4-4831-9a46-fead96690f7c@github.com>
Message-ID: <Xptznf3gdxJtrzcKrNL1jFVz32fvilX1M3Rhvx3FHyA=.011efdf7-737f-4fef-b31a-f17d092232a8@github.com>

On Wed, 2 Jun 2021 13:58:24 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Create implementation for native accessibility peer for Statusbar java role. I do not see any Swing component with StatusBar accessibility role, so I have created a component with the StatusBar role to test this. I have tested the implementation with the following example and a few more similar examples. I do not see any difference in Voice Over output.
> `  
> 
>     import javax.accessibility.Accessible;
>     import javax.accessibility.AccessibleContext;
>     import javax.accessibility.AccessibleRole;
>     import javax.accessibility.AccessibleStateSet;
>     import javax.swing.JFrame;
>     import javax.swing.JLabel;
>     import javax.swing.JPanel;
>     import javax.swing.SwingUtilities;
>     import javax.swing.Timer;
>     import javax.swing.border.BevelBorder;
>     import java.awt.BorderLayout;
>     import java.awt.Color;
>     import java.awt.Dimension;
>     import java.awt.event.ActionEvent;
>     import java.awt.event.ActionListener;
>     import java.text.DateFormat;
> 
>     public class StatusBarDemo {
> 
>         public static void main(String[] args) throws Exception {
>             StatusBarDemo demo = new StatusBarDemo();
>             SwingUtilities.invokeAndWait(demo::createAndShowGUI);
>         }
> 
>         void createAndShowGUI() {
>             JFrame jframe = new JFrame("StatusBar Demo");
>             jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             jframe.setLayout(new BorderLayout());
>             jframe.setSize(200, 200);
> 
>             // create the status bar panel and shove it down the bottom of the frame
>             JPanel statusPanel = new StatusBar();
>             statusPanel.setBorder(new BevelBorder(BevelBorder.LOWERED));
>             statusPanel.setPreferredSize(new Dimension(jframe.getWidth(), 16));
>             statusPanel.setLayout(new BorderLayout());
> 
>             JLabel date = new JLabel();
>             date.setOpaque(true);
>             date.setBackground(Color.black);
>             date.setForeground(Color.WHITE);
>             statusPanel.setLayout(new BorderLayout());
>             statusPanel.setBackground(Color.LIGHT_GRAY);
>             statusPanel.add(date, BorderLayout.CENTER);
> 
> 
>             Timer timer = new javax.swing.Timer(1000, new ActionListener() {
>                 @Override
>                 public void actionPerformed(ActionEvent e) {
>                     java.util.Date now = new java.util.Date();
>                     String ss = DateFormat.getDateTimeInstance().format(now);
>                     date.setText(ss);
>                     date.setToolTipText("Welcome, Today is " + ss);
> 
>                 }
>             });
> 
>             timer.start();
> 
>             jframe.add(statusPanel, BorderLayout.SOUTH);
> 
>             jframe.setLocationRelativeTo(null);
>             jframe.setVisible(true);
>         }
> 
>         class StatusBar extends JPanel implements Accessible {
> 
>             AccessibleContext accessibleContext;
> 
>             public AccessibleContext getAccessibleContext() {
>                 if (accessibleContext == null) {
>                     accessibleContext = new StatusBar.AccessibleJStatusBar();
>                 }
>                 return accessibleContext;
>             }
> 
>             protected class AccessibleJStatusBar extends AccessibleJComponent {
>                 public AccessibleStateSet getAccessibleStateSet() {
>                     AccessibleStateSet states = super.getAccessibleStateSet();
>                     return states;
>                 }
>                 public AccessibleRole getAccessibleRole() {
>                     return AccessibleRole.STATUS_BAR;
>                 }
>             }
>         }
>     }
> 
> 
> `

This pull request has now been integrated.

Changeset: 3025f059
Author:    Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3025f05970ede82c6f67a0434e33b27205e10130
Stats:     41 lines in 3 files changed: 39 ins; 0 del; 2 mod

8264305: Create implementation for native accessibility peer for Statusbar java role

Reviewed-by: kizune

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

PR: https://git.openjdk.java.net/jdk/pull/4307

From serb at openjdk.java.net  Fri Jun  4 06:51:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 4 Jun 2021 06:51:56 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <seXXGprSw8J_2HX1d8Yn1QIUJ3WPKNATj-iodEU2BCg=.7fd321ff-a709-413f-a6f7-355ab90ccf59@github.com>

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

src/java.desktop/unix/classes/sun/awt/X11/XFramePeer.java line 84:

> 82: 
> 83:     private void registerWindowDecorationChangeListener() {
> 84:         if (target instanceof javax.swing.RootPaneContainer) {

Probably this should be done via runtime check? Overwise the swing classes will be always loaded even if swing is not used. see the usage of SunToolkit.isInstanceOf in java.awt.WIndow.java:3965

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+28651297+mkartashev at openjdk.java.net  Fri Jun  4 08:44:22 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Jun 2021 08:44:22 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

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

  Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
  order to avoid unnecessary class loading if it isn't.
  
  Also updated the test such that robot.createScreenCapture() is not
  executed on EDT.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4113/files
  - new: https://git.openjdk.java.net/jdk/pull/4113/files/d2586618..da9fbfd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=00-01

  Stats: 8 lines in 2 files changed: 1 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4113.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4113/head:pull/4113

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+28651297+mkartashev at openjdk.java.net  Fri Jun  4 08:44:23 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Jun 2021 08:44:23 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <seXXGprSw8J_2HX1d8Yn1QIUJ3WPKNATj-iodEU2BCg=.7fd321ff-a709-413f-a6f7-355ab90ccf59@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <seXXGprSw8J_2HX1d8Yn1QIUJ3WPKNATj-iodEU2BCg=.7fd321ff-a709-413f-a6f7-355ab90ccf59@github.com>
Message-ID: <cfItXa0iw9G2Nu8uEnNfwZUf6tuwVcpYOO9-7qjXaq0=.fd86167c-da0b-4843-bad8-b7ae91f336ce@github.com>

On Fri, 4 Jun 2021 06:49:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
>>   order to avoid unnecessary class loading if it isn't.
>>   
>>   Also updated the test such that robot.createScreenCapture() is not
>>   executed on EDT.
>
> src/java.desktop/unix/classes/sun/awt/X11/XFramePeer.java line 84:
> 
>> 82: 
>> 83:     private void registerWindowDecorationChangeListener() {
>> 84:         if (target instanceof javax.swing.RootPaneContainer) {
> 
> Probably this should be done via runtime check? Overwise the swing classes will be always loaded even if swing is not used. see the usage of SunToolkit.isInstanceOf in java.awt.WIndow.java:3965

Thanks! Updated the code; please, have a look.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+28651297+mkartashev at openjdk.java.net  Fri Jun  4 08:44:24 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Jun 2021 08:44:24 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <7BryfzAYMTSTa3s7_ETPQjiiIIWWC52RyMKurV_gjMc=.c89c3ed4-c701-4c5b-8ec6-9dd74f2a2a4f@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <7BryfzAYMTSTa3s7_ETPQjiiIIWWC52RyMKurV_gjMc=.c89c3ed4-c701-4c5b-8ec6-9dd74f2a2a4f@github.com>
Message-ID: <DzLJEwuNxrZ9ZCJOVGu-UbHhZinj8XX6SRBqyzN1QeU=.68ed1c52-827a-4881-a222-5bc32dea3ae6@github.com>

On Tue, 1 Jun 2021 11:31:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
>>   order to avoid unnecessary class loading if it isn't.
>>   
>>   Also updated the test such that robot.createScreenCapture() is not
>>   executed on EDT.
>
> test/jdk/java/awt/Window/WindowTitleVisibleTest/WindowTitleVisibleTestLinuxGnome.java line 111:
> 
>> 109:     private void captureTitleBarNotVisible() {
>> 110:         runSwing( () -> {
>> 111:             titleBarImageNotVisible = robot.createScreenCapture(titleBarBounds);
> 
> `createScreenCapture` does not require to be called on EDT.

Thanks! Moved `createScreenCapture()` out of EDT. Please, have a look at the updated code.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+10835776+stsypanov at openjdk.java.net  Fri Jun  4 11:54:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 4 Jun 2021 11:54:31 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v4]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <HoB4bIMKlVpWgpjzmfKigCj9peFXbp6GuZxyIZnA2xs=.9d6ba2b9-51fe-4c06-a011-258ced3513d8@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/df8be00a..7dc5020e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=02-03

  Stats: 454615 lines in 1482 files changed: 442781 ins; 7489 del; 4345 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From azvegint at openjdk.java.net  Fri Jun  4 12:25:58 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 4 Jun 2021 12:25:58 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>
Message-ID: <tJ3X1rUHCJSdbUMCBAOiRo_9GQfvqQdrWftuRW3ltSQ=.86203638-899d-47df-96c7-0d88748fccf1@github.com>

On Fri, 4 Jun 2021 08:44:22 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
>   order to avoid unnecessary class loading if it isn't.
>   
>   Also updated the test such that robot.createScreenCapture() is not
>   executed on EDT.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From kcr at openjdk.java.net  Fri Jun  4 13:52:04 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 4 Jun 2021 13:52:04 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v10]
In-Reply-To: <wwiVp0YZwraqWWi1da-dJThbV78MIl91eTRd0t8fVu8=.d2423daf-1d02-4643-9e85-120d70c951e6@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <wwiVp0YZwraqWWi1da-dJThbV78MIl91eTRd0t8fVu8=.d2423daf-1d02-4643-9e85-120d70c951e6@github.com>
Message-ID: <tuuLV30RkRzJbLuiF-zPGIIiUAQjt3PeMAeA2FWG9x8=.8edf44d5-b6b9-4ea5-ba6b-7ac7b82f12a4@github.com>

On Thu, 3 Jun 2021 16:55:12 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
>> It doesn't freeze when the Prefer tabs is set to "never".
>> 
>> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
>> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
>> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
>> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
>> 
>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
>> 
>> Test : Added a manual test and tested on MacOS 10.15 and 11.
>> All the internal tests run are green.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add SupressWarnings and test changes

The updates look good. I noted one more test issue and otherwise I think this is ready to go.

test/jdk/java/awt/Window/TestAppFreeze.java line 107:

> 105: 
> 106:     private static void testApp() {
> 107:         testFrame = new JFrame("TestFrame");

This is being run on the wrong thread. You should wrap this method in an `invokeLater` as you did in the `createInstructionUI` method.

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From trebari at openjdk.java.net  Fri Jun  4 14:25:31 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Fri, 4 Jun 2021 14:25:31 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v11]
In-Reply-To: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
Message-ID: <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
> It doesn't freeze when the Prefer tabs is set to "never".
> 
> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
> 
> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
> 
> Test : Added a manual test and tested on MacOS 10.15 and 11.
> All the internal tests run are green.

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

  call on testApp on correct thread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3407/files
  - new: https://git.openjdk.java.net/jdk/pull/3407/files/d710f761..c078f8d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3407&range=09-10

  Stats: 14 lines in 1 file changed: 2 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3407/head:pull/3407

PR: https://git.openjdk.java.net/jdk/pull/3407

From trebari at openjdk.java.net  Fri Jun  4 14:30:02 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Fri, 4 Jun 2021 14:30:02 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v10]
In-Reply-To: <tuuLV30RkRzJbLuiF-zPGIIiUAQjt3PeMAeA2FWG9x8=.8edf44d5-b6b9-4ea5-ba6b-7ac7b82f12a4@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <wwiVp0YZwraqWWi1da-dJThbV78MIl91eTRd0t8fVu8=.d2423daf-1d02-4643-9e85-120d70c951e6@github.com>
 <tuuLV30RkRzJbLuiF-zPGIIiUAQjt3PeMAeA2FWG9x8=.8edf44d5-b6b9-4ea5-ba6b-7ac7b82f12a4@github.com>
Message-ID: <eum7XCJrfbQXp4yGwBpVM1wPC89V0V1uMu88GRScGjo=.3b9cfc42-5b47-4f5a-a292-7a7e245fbc9c@github.com>

On Fri, 4 Jun 2021 13:48:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add SupressWarnings and test changes
>
> test/jdk/java/awt/Window/TestAppFreeze.java line 107:
> 
>> 105: 
>> 106:     private static void testApp() {
>> 107:         testFrame = new JFrame("TestFrame");
> 
> This is being run on the wrong thread. You should wrap this method in an `invokeLater` as you did in the `createInstructionUI` method.

yeah , i have added this code to run on  EDT.

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From kcr at openjdk.java.net  Fri Jun  4 14:30:01 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 4 Jun 2021 14:30:01 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v11]
In-Reply-To: <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
Message-ID: <6wm28APSC35IVQKB2_FTQu4jsaxiXwDAyqATxkb2RS8=.ae9ffc7c-ff0d-4635-945c-8040b565b5c5@github.com>

On Fri, 4 Jun 2021 14:25:31 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
>> It doesn't freeze when the Prefer tabs is set to "never".
>> 
>> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
>> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
>> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
>> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
>> 
>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
>> 
>> Test : Added a manual test and tested on MacOS 10.15 and 11.
>> All the internal tests run are green.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call on testApp on correct thread

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From serb at openjdk.java.net  Fri Jun  4 21:39:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 4 Jun 2021 21:39:03 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>
Message-ID: <dqpgWRqa8SwCZWj_vxwq2AqGOfM7oYeRId5MKaqwvnc=.6171380f-8fc8-4e66-8148-20cc0b35e676@github.com>

On Fri, 4 Jun 2021 08:44:22 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
>   order to avoid unnecessary class loading if it isn't.
>   
>   Also updated the test such that robot.createScreenCapture() is not
>   executed on EDT.

src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java line 1327:

> 1325:         Optional<Boolean> res = Optional.empty();
> 1326: 
> 1327:         if (target instanceof javax.swing.RootPaneContainer) {

Looks like this instanceof will load the Swing as well.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From serb at openjdk.java.net  Sat Jun  5 03:38:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 5 Jun 2021 03:38:03 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v11]
In-Reply-To: <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
Message-ID: <ednhZUgks8OdOqlQ50tMT9USf6ZVlfK4O_TNBB9rrlY=.8503842b-232c-4e88-9b63-8d72feae3ee2@github.com>

On Fri, 4 Jun 2021 14:25:31 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
>> It doesn't freeze when the Prefer tabs is set to "never".
>> 
>> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
>> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
>> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
>> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
>> 
>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
>> 
>> Test : Added a manual test and tested on MacOS 10.15 and 11.
>> All the internal tests run are green.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call on testApp on correct thread

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From prr at openjdk.java.net  Sat Jun  5 15:14:22 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 5 Jun 2021 15:14:22 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode!
Message-ID: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>

There are two issues here, both macOS specific.
First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
Only a single supported display mode is returned and it is also the current mode.
A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
will fail because macOS reports the same display mode it returned as valid as now being illegal.
It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
so it probably is the case that macOS simply does not allow this shared desktop to be changed although
there's no docs I can find
Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that

Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
an external monitor attached as well, or not, activates the discrete card, or not.

Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
can I find an explanation.

It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
so the list of available modes is reduced by one.
But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 

So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
Only if that fails do we then throw an exception.

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

Commit messages:
 - 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

Changes: https://git.openjdk.java.net/jdk/pull/4373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267430
  Stats: 123 lines in 3 files changed: 120 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Sat Jun  5 20:55:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 5 Jun 2021 20:55:02 GMT
Subject: <AWT Dev> RFR: 8256465: [macos] Java frame and dialog presented
 full screen freeze application [v11]
In-Reply-To: <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
 <RkcxMW366YJVFCKwGcCx0mvQsgjjLBYRiVQb8n8pAzw=.e6ebbd53-371c-4d70-af8d-8aa40741d643@github.com>
Message-ID: <h2z3fOoa522V5_Hg-raknYa0NWwq_loWFcGijcaIQIU=.b32671e0-4f3f-4c79-ae09-f4c97e0d8618@github.com>

On Fri, 4 Jun 2021 14:25:31 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
>> It doesn't freeze when the Prefer tabs is set to "never".
>> 
>> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
>> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
>> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
>> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
>> 
>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
>> 
>> Test : Added a manual test and tested on MacOS 10.15 and 11.
>> All the internal tests run are green.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call on testApp on correct thread

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From trebari at openjdk.java.net  Sun Jun  6 04:13:21 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Sun, 6 Jun 2021 04:13:21 GMT
Subject: <AWT Dev> Integrated: 8256465: [macos] Java frame and dialog
 presented full screen freeze application
In-Reply-To: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
References: <9eu_j4u-EYaQm78KGXXyhTIO1-M-bEikDRMFWORt38Y=.2ecdeac6-72ed-4f4e-8785-a7909a8eeacd@github.com>
Message-ID: <wX0GeEQSe_TY_QxX4egKrsvmBt3_wA-cJCHbbR_nyrY=.4713af2b-08bb-4bc9-a215-5018258946b7@github.com>

On Fri, 9 Apr 2021 05:42:37 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : On MacOS 11 Java Frame and JDialog application is freezing  in Full Screen  when the System Preference -> General -> Prefer Tabs is set to "Full Screen". It is also freezing in normal screen when Prefer Tabs is set to "Always".
> It doesn't freeze when the Prefer tabs is set to "never".
> 
> Fix : The default value of allowsAutomaticWindowTabbing is 0/NO in MacOS prior to bigSur(11)  
> (in the AWTWindow.m file),  so the issue is not seen in mac os 10.13 10.14 and 10.15.
> From MacOS 11 onwards  this value is set to 1/YES and the issue is seen.
> This issue can also be reproduced in MacOS 10.15 by setting setAllowsAutomaticWindowTabbing to true in the AWTWindow.m file.
> 
> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release staring from 10.12.
> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default value changed in macos11.
> 
> Test : Added a manual test and tested on MacOS 10.15 and 11.
> All the internal tests run are green.

This pull request has now been integrated.

Changeset: 042f0bdb
Author:    Tejpal Rebari <trebari at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/042f0bdb3568edab4f96b9f7c83cbb0f90db7f18
Stats:     171 lines in 3 files changed: 169 ins; 0 del; 2 mod

8256465: [macos] Java frame and dialog presented full screen freeze application

Reviewed-by: kcr, serb, prr

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

PR: https://git.openjdk.java.net/jdk/pull/3407

From github.com+28651297+mkartashev at openjdk.java.net  Mon Jun  7 10:30:33 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 7 Jun 2021 10:30:33 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v3]
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <G1j933R3v3tPhzarFFno379-bhphH8yE3xq78lONj2M=.a8c69fdd-f0af-44e1-9e88-6226c1b724b6@github.com>

> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.

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

  Changed the check for the XDecoratedPeer target being javax.swing.RootPaneContainer in
  order to avoid unnecessary class loading if it isn't.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4113/files
  - new: https://git.openjdk.java.net/jdk/pull/4113/files/da9fbfd8..c83c7216

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From github.com+28651297+mkartashev at openjdk.java.net  Mon Jun  7 10:30:38 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 7 Jun 2021 10:30:38 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v2]
In-Reply-To: <dqpgWRqa8SwCZWj_vxwq2AqGOfM7oYeRId5MKaqwvnc=.6171380f-8fc8-4e66-8148-20cc0b35e676@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <045A1bR8zcIxC_uDyjUD60wbqvZtwBzygbxpqjaICuw=.dda48bf6-fca4-4f78-8ceb-8bea6c2e18a1@github.com>
 <dqpgWRqa8SwCZWj_vxwq2AqGOfM7oYeRId5MKaqwvnc=.6171380f-8fc8-4e66-8148-20cc0b35e676@github.com>
Message-ID: <N_yqZYXE244XG32JnzgaNfH0hz6ayjmwfzmRkwHruz4=.03a935f5-7f8c-45e8-a902-45957b282062@github.com>

On Fri, 4 Jun 2021 21:36:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the check for the XFramePeer target being javax.swing.RootPaneContainer in
>>   order to avoid unnecessary class loading if it isn't.
>>   
>>   Also updated the test such that robot.createScreenCapture() is not
>>   executed on EDT.
>
> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java line 1327:
> 
>> 1325:         Optional<Boolean> res = Optional.empty();
>> 1326: 
>> 1327:         if (target instanceof javax.swing.RootPaneContainer) {
> 
> Looks like this instanceof will load the Swing as well.

Sorry, missed that one the first time. Corrected now.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From azvegint at openjdk.java.net  Mon Jun  7 11:10:02 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 7 Jun 2021 11:10:02 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode!
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <sveGJ_hCZkzedKCFaU15YdNH9nDYw47CHa8c-am-ieI=.0fa4fde3-92c6-44ea-bda6-8c096c670b2e@github.com>

On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race <prr at openjdk.org> wrote:

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m line 266:

> 264: /*
> 265:  * Class:     sun_awt_CGraphicsDevice
> 266:  * Method:    nativeSetDisplayMode

`nativeResetDisplayMode`?

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Mon Jun  7 15:17:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 15:17:49 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode!
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <O61swnwnVbl_rcBz4KGzv2S1QK5nGnTkI3nRY6-nwTA=.3ba89ce6-dcee-4280-a556-199bb6627179@github.com>

On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race <prr at openjdk.org> wrote:

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

fixed typo in comment

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Mon Jun  7 15:17:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 15:17:48 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

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

  8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4373/files
  - new: https://git.openjdk.java.net/jdk/pull/4373/files/d396b068..d93be8fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From azvegint at openjdk.java.net  Mon Jun  7 16:10:18 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 7 Jun 2021 16:10:18 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
Message-ID: <JEHbzziY8oMZJahKOmS18qCOMFecIp1NqBdv0rwzvtc=.82755c44-c6f4-4586-bc84-39f980fcccd8@github.com>

On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line 44:

> 42:         for (GraphicsDevice d : devices) {
> 43: 
> 44:             if (!d.isDisplayChangeSupported()) {

BTW, do we want to run this test on other platforms?

If so, we need to modify test. Because `isDisplayChangeSupported()` may return true on Windows and Linux only if we have a fullscreen window showing.

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Mon Jun  7 16:17:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 16:17:19 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <JEHbzziY8oMZJahKOmS18qCOMFecIp1NqBdv0rwzvtc=.82755c44-c6f4-4586-bc84-39f980fcccd8@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
 <JEHbzziY8oMZJahKOmS18qCOMFecIp1NqBdv0rwzvtc=.82755c44-c6f4-4586-bc84-39f980fcccd8@github.com>
Message-ID: <uKZJlOrov6R0g8XSK6gmIZn8clj6h1AUurH0q28Digc=.7203fd4a-9087-4ca9-b958-281c1cb0811a@github.com>

On Mon, 7 Jun 2021 16:07:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode
>
> test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line 44:
> 
>> 42:         for (GraphicsDevice d : devices) {
>> 43: 
>> 44:             if (!d.isDisplayChangeSupported()) {
> 
> BTW, do we want to run this test on other platforms?
> 
> If so, we need to modify test. Because `isDisplayChangeSupported()` may return true on Windows and Linux only if we have a fullscreen window showing.

I don't see the harm.

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From maxim.kartashev at jetbrains.com  Mon Jun  7 18:21:24 2021
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Mon, 7 Jun 2021 21:21:24 +0300
Subject: <AWT Dev> VM shutdown upon X server termination
Message-ID: <CAG0Tb0jvFuXaq95eUTzrx-a3L52TdXCLmzFv0mJM1z_1t5fn0g@mail.gmail.com>

When the X server suddenly dies, Xlib would usually (or maybe always)
discover this as an I/O error. It will then call the function installed
with XSetIOErrorHandler() and expects that the function will not return
("the called routine should not return" from
https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html).
If the handler returns, Xlib will simply call ::exit().

AWT installs awt_GraphicsEnv.c`xioerror_handler() as such a function and it
_does_ return. I was wondering if it would be prudent to properly terminate
VM from the handler (with JVM_Halt(), perhaps)? We are getting many reports
of JVM crashes on Linux that seem to be connected with the sudden
disappearance of the X server, but I wasn't able to reproduce this so can't
be sure that this is the issue we are facing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210607/aef1a10b/attachment-0001.htm>

From serb at openjdk.java.net  Mon Jun  7 19:49:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 7 Jun 2021 19:49:16 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
Message-ID: <1MNyq1G5NbVKXAojGUfHyxWPrnHq8A-KeUCdbKqjmn0=.6fb74b0e-b754-4490-8775-f7a460d7fcbe@github.com>

On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 72:

> 70:     public CGraphicsDevice(final int displayID) {
> 71:         this.displayID = displayID;
> 72:         this.initialMode = getDisplayMode();

This probably should be revalidated when this device is invalidated, otherwise deleted device will restore its own old-initial mode, instead of the new-mode for the new device.

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From serb at openjdk.java.net  Mon Jun  7 19:53:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 7 Jun 2021 19:53:18 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
Message-ID: <lQM5El_8LxYs9s1fAIRR3EOP87NYdqDGJVUCb8R4xVA=.46fa0669-197c-4f6f-9db2-aee43d20fe31@github.com>

On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 341:

> 339:                  * that mode reported and it restores all devices, but
> 340:                  * this seems a better compromise than failing to restore
> 341:                  */

Would like to highlight that this tradeoff will break the spec, since we successfully restore the mode which is not in the list of modes.

test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line 67:

> 65:              } finally {
> 66:                  System.out.println("restoring original mode"+odm);
> 67:                  d.setDisplayMode(odm);

I suggest waiting here as well.

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Mon Jun  7 20:22:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 20:22:44 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v3]
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <IA8DHd_yAf0kXZB5rCA-keaegpCd7uutkGIDUR6TL8A=.55a2917d-21db-4acb-bdda-d407bfd81065@github.com>

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

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

  8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4373/files
  - new: https://git.openjdk.java.net/jdk/pull/4373/files/d93be8fa..3a496412

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=01-02

  Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Mon Jun  7 20:22:46 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 20:22:46 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <1MNyq1G5NbVKXAojGUfHyxWPrnHq8A-KeUCdbKqjmn0=.6fb74b0e-b754-4490-8775-f7a460d7fcbe@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
 <1MNyq1G5NbVKXAojGUfHyxWPrnHq8A-KeUCdbKqjmn0=.6fb74b0e-b754-4490-8775-f7a460d7fcbe@github.com>
Message-ID: <s9mEqEVYstcDwf0XIJHjWc0DB3PEaRuYUPiZ3SGyN5Y=.0a476354-ae37-456a-a518-95f897df47c2@github.com>

On Mon, 7 Jun 2021 19:45:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 72:
> 
>> 70:     public CGraphicsDevice(final int displayID) {
>> 71:         this.displayID = displayID;
>> 72:         this.initialMode = getDisplayMode();
> 
> This probably should be revalidated when this device is invalidated, otherwise deleted device will restore its own old-initial mode, instead of the new-mode for the new device.

Ok I've added copying it in invalidate()

> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 341:
> 
>> 339:                  * that mode reported and it restores all devices, but
>> 340:                  * this seems a better compromise than failing to restore
>> 341:                  */
> 
> Would like to highlight that this tradeoff will break the spec, since we successfully restore the mode which is not in the list of modes.

So .. it was in the lsit of modes that the app was handed, and it is a bug that it isn't still there.
But what I've just done is fixed getDIsplayModes() to  include it

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From philip.race at oracle.com  Mon Jun  7 22:53:12 2021
From: philip.race at oracle.com (Philip Race)
Date: Mon, 7 Jun 2021 15:53:12 -0700
Subject: <AWT Dev> VM shutdown upon X server termination
In-Reply-To: <CAG0Tb0jvFuXaq95eUTzrx-a3L52TdXCLmzFv0mJM1z_1t5fn0g@mail.gmail.com>
References: <CAG0Tb0jvFuXaq95eUTzrx-a3L52TdXCLmzFv0mJM1z_1t5fn0g@mail.gmail.com>
Message-ID: <b5299992-a41a-ec4b-df12-2a1419e87519@oracle.com>

So if it returns and exit() is immediately called, how does that cause a 
crash ?
It seems to be just the same as if the handler called exit() directly 
and so did not return.
I would have thought a crash more likely if it didn't return and tried 
to keep the program running,
which might be effectively what you temporarily do if you call JVM_Halt().

-phil.


On 6/7/21 11:21 AM, Maxim Kartashev wrote:
> When the X server suddenly dies, Xlib would usually (or maybe always) 
> discover this as an I/O error. It will then call the function 
> installed with XSetIOErrorHandler() and expects that the function will 
> not return ("the called routine should not return" from 
> https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html 
> <https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html>). 
> If the handler returns, Xlib will simply call ::exit().
>
> AWT installs awt_GraphicsEnv.c`xioerror_handler() as such a function 
> and it _does_ return. I was wondering if it would be prudent to 
> properly terminate VM from the handler (with JVM_Halt(), perhaps)? We 
> are getting many reports of JVM crashes on Linux that seem to be 
> connected with the sudden disappearance of the X server, but I wasn't 
> able to reproduce this so can't be sure that this is the issue we are 
> facing.
>


From github.com+10835776+stsypanov at openjdk.java.net  Tue Jun  8 07:01:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 8 Jun 2021 07:01:53 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v5]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <uxHLTba6MgAAo8vvClv2MatgKGVBdVku-kKDQ-OThE0=.97f382c1-a48f-4feb-8004-5d28e570dbcf@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/7dc5020e..76af35c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=03-04

  Stats: 30371 lines in 444 files changed: 25591 ins; 2648 del; 2132 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From vdyakov at openjdk.java.net  Tue Jun  8 17:12:25 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 8 Jun 2021 17:12:25 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v3]
In-Reply-To: <IA8DHd_yAf0kXZB5rCA-keaegpCd7uutkGIDUR6TL8A=.55a2917d-21db-4acb-bdda-d407bfd81065@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <IA8DHd_yAf0kXZB5rCA-keaegpCd7uutkGIDUR6TL8A=.55a2917d-21db-4acb-bdda-d407bfd81065@github.com>
Message-ID: <S9-8vMICjh24On0rUMBAieDTm5qMQtn6q-vz0mVdKHw=.1c964758-3e3d-48e5-9ece-562bfe1210f4@github.com>

On Mon, 7 Jun 2021 20:22:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

please review @mrserb and @azvegint

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Tue Jun  8 20:06:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 20:06:16 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v2]
In-Reply-To: <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
Message-ID: <OahTIOcOD21-F-gP2Y_1T_g8u6WciBbm_1NhT0ijHwY=.2629025c-8661-4bb7-a3e0-cc655d814212@github.com>

On Fri, 21 May 2021 20:16:41 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second version of the fix

The points I have been trying to make are that
1) We need to make sure that important cleanup happens rather than just bailing
2) Despite Windows + Linux propagating a RTE, I am not sure this is what we want.
   If the RTE is something the *app* decides to throw,  then that's one thing but
   if something went wrong in the bowels of printing the spec says it should be a PrinterException.
   At the very least we should make sure temp files are deleted, any open calls
   to startDoc have been matched with a close ..

Hence my early comment "The exception should not propagate. State may need to be cleaned up. 
If you do anything you would make it the init cause of the PrinterException."
That means if we see an RTE propagated .. that could be a bug.

So I am nor comfortable just "aligning" the behaviour with WIndows and Linux without being
sure they are correct.

In other words, mac was probably catching this to do the clean up part, and that was likely OK
But yes, it probably was wrong not to rethrow as a wrapped (if needed) PrinterException

But although it opens a whole new can of worms I was suggesting you needed to look closely
at windows + linux and not just create a test which verified behaviour I am not sure we want.

I questioned the test etc about RTE because although it is good to test hrowing RTE  you
are verifying it ARRIVES still as an RTE, and I think it should be a PrinterException.

I am open to discussion about why this may be "actually OK" but it has to be better than
"the others are doing it" and it definitely should not be a reason to leave open files/jobs.

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

PR: https://git.openjdk.java.net/jdk/pull/4036

From prr at openjdk.java.net  Tue Jun  8 20:06:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 20:06:17 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v2]
In-Reply-To: <NRjNLmrJjLMnm32ZQBF1cYik3PM1Y5aWSGdHpCyeKEg=.8ec0fee7-b61c-46cc-9044-dd3fcdd91a7a@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
 <O7asXz-60_EMTgNBs3i0glK9DNspl7rOXvJTFbAdtY8=.5dc03be2-e8c0-43cc-b220-75c07cecd113@github.com>
 <NRjNLmrJjLMnm32ZQBF1cYik3PM1Y5aWSGdHpCyeKEg=.8ec0fee7-b61c-46cc-9044-dd3fcdd91a7a@github.com>
Message-ID: <Rg3B_SV8YlUfJlxtkaVWaIxNW6FWJ8ir4j4Y_LjWX7M=.a44358ab-1d80-44f6-97b5-8ca4cf909efb@github.com>

On Mon, 31 May 2021 12:21:59 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 32:
>> 
>>> 30:    @run main/manual ExceptionFromPrintableIsIgnoredTest MAIN RE
>>> 31:    @run main/manual ExceptionFromPrintableIsIgnoredTest EDT PE
>>> 32:    @run main/manual ExceptionFromPrintableIsIgnoredTest EDT RE
>> 
>> wjy is this still manual ?
>
> The test is manual, because the test initiates printing and there is a chance that on a test host a default printer will be some virtual printer which can show the native dialog asking to specify the location of PDF file in which the printed document should be saved, in this case the test will be blocked and will be killed by "jtreg" by a timeout, what is unacceptable for the automatic test which should not slow down the speed of execution of all other automatic tests. For example such a virtual printer on Windows OS can be "Microsoft Print to PDF". By the way, I already explained this reason in one of my replies to your questions in the previous iteration of the code review.

I thought I also explained that the printer keyword means it would only be run if the system has a real printer by virtue of it being set in the jtreg run. You could also do that on a virtual printer if you didn't mind entering the file name

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

PR: https://git.openjdk.java.net/jdk/pull/4036

From serb at openjdk.java.net  Tue Jun  8 20:53:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Jun 2021 20:53:16 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v2]
In-Reply-To: <lQM5El_8LxYs9s1fAIRR3EOP87NYdqDGJVUCb8R4xVA=.46fa0669-197c-4f6f-9db2-aee43d20fe31@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <UWkKPe5v2slMfdeq5bn6Ut8MTCB8jdy_H9Ta6f7sGow=.cc65bfa1-528a-438f-81cf-258561642e8a@github.com>
 <lQM5El_8LxYs9s1fAIRR3EOP87NYdqDGJVUCb8R4xVA=.46fa0669-197c-4f6f-9db2-aee43d20fe31@github.com>
Message-ID: <0sjc5-Ly5vd45iLcUCSo7ainLUgnbnwlWjmgSdFilB0=.753c22f7-da12-49c5-8a62-373d53fd2683@github.com>

On Mon, 7 Jun 2021 19:50:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode
>
> test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line 67:
> 
>> 65:              } finally {
>> 66:                  System.out.println("restoring original mode"+odm);
>> 67:                  d.setDisplayMode(odm);
> 
> I suggest waiting here as well.

I still suggest waiting here, other tests were updated to wait 10 seconds, since on the old systems the last restore may affect the next test.

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From serb at openjdk.java.net  Tue Jun  8 20:53:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Jun 2021 20:53:15 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode!
In-Reply-To: <O61swnwnVbl_rcBz4KGzv2S1QK5nGnTkI3nRY6-nwTA=.3ba89ce6-dcee-4280-a556-199bb6627179@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <O61swnwnVbl_rcBz4KGzv2S1QK5nGnTkI3nRY6-nwTA=.3ba89ce6-dcee-4280-a556-199bb6627179@github.com>
Message-ID: <3UQc9PJsFfG7Idt7pAxMYdSBVQboPUZI37X9i0C6XyU=.129f7c1c-a86f-4aa9-93a2-c920b24f15a4@github.com>

On Mon, 7 Jun 2021 15:13:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> fixed typo in comment

@prrace @victordyakov looks like "removed the rfr label yesterday" due to jcheck failure, so the fix is not under review right now.
" @openjdk openjdk / jcheck
Whitespace error
Column 23: trailing whitespace"

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From serb at openjdk.java.net  Tue Jun  8 21:11:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Jun 2021 21:11:21 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v3]
In-Reply-To: <G1j933R3v3tPhzarFFno379-bhphH8yE3xq78lONj2M=.a8c69fdd-f0af-44e1-9e88-6226c1b724b6@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <G1j933R3v3tPhzarFFno379-bhphH8yE3xq78lONj2M=.a8c69fdd-f0af-44e1-9e88-6226c1b724b6@github.com>
Message-ID: <mISoAVRm2eHoEfRNyLr2Am7Jox-SIjWOiVMhFCtr1AI=.29d4673f-30b4-458b-b13a-0bc4337dd94c@github.com>

On Mon, 7 Jun 2021 10:30:33 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the check for the XDecoratedPeer target being javax.swing.RootPaneContainer in
>   order to avoid unnecessary class loading if it isn't.

Looks fine, I'll run the tests.

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From prr at openjdk.java.net  Tue Jun  8 21:45:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 21:45:43 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v4]
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <2MrK63W_u-2uDzAuiPSKBGNVMeqL_vs4EelU-ifgXww=.e92c8f4b-e029-40f0-930f-ffab8bfdd719@github.com>

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

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

  8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4373/files
  - new: https://git.openjdk.java.net/jdk/pull/4373/files/3a496412..2289c30d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Tue Jun  8 21:45:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 21:45:43 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v3]
In-Reply-To: <S9-8vMICjh24On0rUMBAieDTm5qMQtn6q-vz0mVdKHw=.1c964758-3e3d-48e5-9ece-562bfe1210f4@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <IA8DHd_yAf0kXZB5rCA-keaegpCd7uutkGIDUR6TL8A=.55a2917d-21db-4acb-bdda-d407bfd81065@github.com>
 <S9-8vMICjh24On0rUMBAieDTm5qMQtn6q-vz0mVdKHw=.1c964758-3e3d-48e5-9ece-562bfe1210f4@github.com>
Message-ID: <_4oPaI-IakdoszZMl1WBAUvUMoVAOxwV3_8-rX2ODos=.da31c1a0-c183-4a34-ac29-27dcf872b22f@github.com>

On Tue, 8 Jun 2021 17:08:54 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode
>
> please review @mrserb and @azvegint

@victordyakov @mrserb white space is fixed now

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun  9 10:32:38 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 9 Jun 2021 10:32:38 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v6]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <5DP52RlB_Dtcy30JuehAzoGtvEXryh10kqEYoYZvN9k=.1229b4f2-f7f5-4f0b-9d40-947cbe3672f1@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

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

 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/76af35c6..3a7b5515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=04-05

  Stats: 5577 lines in 149 files changed: 3466 ins; 1405 del; 706 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From serb at openjdk.java.net  Wed Jun  9 19:03:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Jun 2021 19:03:17 GMT
Subject: <AWT Dev> RFR: 8267307: Introduce new client property for XAWT:
 xawt.mwm_decor_title [v3]
In-Reply-To: <G1j933R3v3tPhzarFFno379-bhphH8yE3xq78lONj2M=.a8c69fdd-f0af-44e1-9e88-6226c1b724b6@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
 <G1j933R3v3tPhzarFFno379-bhphH8yE3xq78lONj2M=.a8c69fdd-f0af-44e1-9e88-6226c1b724b6@github.com>
Message-ID: <tRHVA4GqaZvFAsOtjEQZUG9KW4NmU_sIMI66AMPGSOA=.fe780938-730a-404e-b639-4330b328cdca@github.com>

On Mon, 7 Jun 2021 10:30:33 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> This commit introduces a new client property xawt.mwm_decor_title implementing JDK-8267307. The property can be set prior to showing a window or after the window has been displayed, in which case the window will have to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to decorate with anything, even borders or resize handles. With xawt.mwm_decor_title property set to "true", this commit adds the ability to set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs take as "decorate with only a border", thus effectively removing the window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, where it did not have any effect; these two WMs have limited respected for the "decorations" bits of the _MOTIF_WM_HINTS window property.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the check for the XDecoratedPeer target being javax.swing.RootPaneContainer in
>   order to avoid unnecessary class loading if it isn't.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4113

From serb at openjdk.java.net  Wed Jun  9 20:01:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Jun 2021 20:01:32 GMT
Subject: <AWT Dev> RFR: 8268481: Delete JAWT test files for mac
Message-ID: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>

Due to some issues, we need to delete these files. Later this test case will be updated and reintegrated.

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

Commit messages:
 - Revert "8263928: Add JAWT test files for mac"

Changes: https://git.openjdk.java.net/jdk/pull/4440/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4440&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268481
  Stats: 228 lines in 3 files changed: 0 ins; 228 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4440.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4440/head:pull/4440

PR: https://git.openjdk.java.net/jdk/pull/4440

From serb at openjdk.java.net  Wed Jun  9 20:03:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Jun 2021 20:03:17 GMT
Subject: <AWT Dev> RFR: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to
 set display mode! [v4]
In-Reply-To: <2MrK63W_u-2uDzAuiPSKBGNVMeqL_vs4EelU-ifgXww=.e92c8f4b-e029-40f0-930f-ffab8bfdd719@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
 <2MrK63W_u-2uDzAuiPSKBGNVMeqL_vs4EelU-ifgXww=.e92c8f4b-e029-40f0-930f-ffab8bfdd719@github.com>
Message-ID: <s6eR7lYR14EO2Tycw0-2E65n8r3cDZbZDkAWTAHsNFY=.85661d8f-ccd0-4c38-88bd-436b9989d5de@github.com>

On Tue, 8 Jun 2021 21:45:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current mode.
>> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid as now being illegal.
>> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
>> 
>> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card, or not.
>> 
>> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
>> can I find an explanation.
>> 
>> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
>> 
>> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From prr at openjdk.java.net  Wed Jun  9 20:56:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 9 Jun 2021 20:56:23 GMT
Subject: <AWT Dev> Integrated: 8267430:
 GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to
 set display mode!
In-Reply-To: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
References: <JWVi3LIksuW1aGSXbBUTgyV65fS-lWLtGs4uKPImB1s=.47e17881-64e0-4e8a-be68-0e7370eff72b@github.com>
Message-ID: <iPA-TArMrab6DPILN_3y1qpbRuGUCR_jP7al46jhGac=.acd2f8bd-38fa-45ff-8b08-7166b7a7b39f@github.com>

On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race <prr at openjdk.org> wrote:

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

This pull request has now been integrated.

Changeset: 991ca142
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/991ca14279faa7db5d0afe023e666844f5b3b75b
Stats:     142 lines in 3 files changed: 138 ins; 0 del; 4 mod

8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode!

Reviewed-by: serb

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

PR: https://git.openjdk.java.net/jdk/pull/4373

From alitvinov at openjdk.java.net  Wed Jun  9 21:22:55 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Jun 2021 21:22:55 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v3]
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <qcYyd_OEGPole0qW4lKh7rOqHdOmPHyN9p910xkfnfg=.f4010776-67aa-4bc1-b5f0-a26c6709d000@github.com>

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

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

 - Merge remote-tracking branch 'origin/master' into JDK-8262731
 - Second version of the fix
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4036/files
  - new: https://git.openjdk.java.net/jdk/pull/4036/files/47051517..746dc0c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4036&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4036&range=01-02

  Stats: 582865 lines in 4738 files changed: 500326 ins; 67543 del; 14996 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4036/head:pull/4036

PR: https://git.openjdk.java.net/jdk/pull/4036

From prr at openjdk.java.net  Thu Jun 10 00:01:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Jun 2021 00:01:17 GMT
Subject: <AWT Dev> RFR: 8268481: Delete JAWT test files for mac
In-Reply-To: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
References: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
Message-ID: <9MLqZ-Q3S0uTMSETM4VIod_aqhH8He3ov23AX0cFvL8=.814ff840-5e6f-4137-9508-e95f188b37a2@github.com>

On Wed, 9 Jun 2021 19:49:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Due to some issues, we need to delete these files. Later this test case will be updated and reintegrated.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4440

From pbansal at openjdk.java.net  Thu Jun 10 04:09:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 10 Jun 2021 04:09:11 GMT
Subject: <AWT Dev> RFR: 8268481: Delete JAWT test files for mac
In-Reply-To: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
References: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
Message-ID: <oXZLUpX5RivyT0vujXOmWOJNc0xa9C9QqQBbdfI46lo=.108d8b2b-334c-41a7-b756-386d6d49b16d@github.com>

On Wed, 9 Jun 2021 19:49:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Due to some issues, we need to delete these files. Later this test case will be updated and reintegrated.

Marked as reviewed by pbansal (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4440

From github.com+36081106+savoptik at openjdk.java.net  Thu Jun 10 08:07:35 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Thu, 10 Jun 2021 08:07:35 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
Message-ID: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>

8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
This pull request contains solutions for the following tickets:
* JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
* JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
* JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
* JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
* JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
* JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
* JDK-8267388 Create implementation for NSAccessibilityTable protocol.

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

Commit messages:
 - 8267388: Create implementation for NSAccessibilityTable protocol
 - 8267387: Create implementation for NSAccessibilityOutline protocol
 - 8264292: Create implementation for NSAccessibilityList protocol peer
 - 8264303: Create implementation for NSAccessibilityTabGroup protocol peer
 - 8264287: Create implementation for NSAccessibilityComboBox protocol peer
 - 8262031: Create implementation for NSAccessibilityNavigableStaticText protocol
 - 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility

Changes: https://git.openjdk.java.net/jdk/pull/4412/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4412&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267385
  Stats: 4696 lines in 52 files changed: 4526 ins; 108 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4412/head:pull/4412

PR: https://git.openjdk.java.net/jdk/pull/4412

From kizune at openjdk.java.net  Thu Jun 10 08:07:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 10 Jun 2021 08:07:36 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <6tw6VMA2osROvcQocJqcTXywIrP5_qJXHtGJs0kxWPU=.f11c15c4-bd2f-4098-a336-63725a73a9b7@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 728:

> 726:     // Each child takes up three entries in the array: one for itself, one for its role, and one for the recursion level
> 727:     public static Object[] getChildrenAndRolesRecursive(final Accessible a, final Component c, final int whichChildren, final boolean allowIgnored, final int level) {
> 728:         if (a == null) return null;

I am not sure but i think CAccessible is considered a public API so adding public methods to it might require a CSR filling.

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jun 10 08:30:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 10 Jun 2021 08:30:43 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v7]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <LjewJ33cY6vu4Nd1t1HCMN-1rjtzl1rxTwVx-NcCBEg=.31de3f9e-5bbe-4743-87e9-978b09d0bcaf@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? 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 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/3a7b5515..f1c8cc7b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=05-06

  Stats: 4631 lines in 103 files changed: 3649 ins; 401 del; 581 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From serb at openjdk.java.net  Thu Jun 10 09:12:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Jun 2021 09:12:19 GMT
Subject: <AWT Dev> Integrated: 8268481: Delete JAWT test files for mac
In-Reply-To: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
References: <S9WGQ3hpXwiFtNEiPtztS8dzRITiby7zo1Pih7DX5gw=.3a654357-09fd-4515-824c-af66874a4114@github.com>
Message-ID: <ahgNSAenO0jVhubLCruS6qRxHp1UHogs2v8vTV_sKOQ=.33f3ba07-5948-4f45-abbc-7e3c56963f27@github.com>

On Wed, 9 Jun 2021 19:49:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Due to some issues, we need to delete these files. Later this test case will be updated and reintegrated.

This pull request has now been integrated.

Changeset: ea19b044
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea19b0447cf1ec97c0b0a817542ce7ead4f53176
Stats:     228 lines in 3 files changed: 0 ins; 228 del; 0 mod

8268481: Delete JAWT test files for mac

Reviewed-by: prr, pbansal

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

PR: https://git.openjdk.java.net/jdk/pull/4440

From vdyakov at openjdk.java.net  Thu Jun 10 19:39:52 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 10 Jun 2021 19:39:52 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <DTa5HnMjb66QaIUeEPqwoESd_1YadEGUtEsma660cFY=.840bc238-031c-4b02-a90f-01de8936fce0@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

@pbansal please review

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From alitvinov at openjdk.java.net  Fri Jun 11 17:06:24 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Fri, 11 Jun 2021 17:06:24 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

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

  Third version of the fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4036/files
  - new: https://git.openjdk.java.net/jdk/pull/4036/files/746dc0c3..056734b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4036&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4036&range=02-03

  Stats: 42 lines in 2 files changed: 19 ins; 16 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4036/head:pull/4036

PR: https://git.openjdk.java.net/jdk/pull/4036

From alitvinov at openjdk.java.net  Fri Jun 11 18:09:51 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Fri, 11 Jun 2021 18:09:51 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <cptIrfZesP5BnQwbKGGXDrG9oy0FS0xRZ9587q73-8I=.f2e9f528-39c2-4c08-aba6-4d6545d73b64@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Hello Phil,

I created the 3rd version of the fix which should address your remarks about the fix and the regression test. Can you please review the 3rd version of the fix (Webrev 03).

Thank you for provision with your position about different aspects of the fix, regression test and the discovered discrepancies with the specification on Windows OS and Linux OS. I absolutely agree that it is incorrect to implement propagation of RTE through "PrinterJob.print()" without wrapping it into "PrinterException", because RTE is not mentioned in the specification for "PrinterJob.print()" method. The 3rd fix version addresses this mistake from previous fix versions.

Perhaps, it is not very significant issue, that on Windows OS and Linux OS RTE from "Printable.print?(Graphics, PageFormat, int)" is propagated, because in this case the user's code does not follow the specification by throwing RTE from "Printable.print?(Graphics, PageFormat, int)". I do not want to investigate this discovered discrepancy with specification on Windows OS and Linux OS in this fix for a little different issue specific to macOS. If it is currently really necessary I can file a bug or 2 bugs in JBS to address the discovered issue on Windows and Linux.

Thank you for giving me the details about "printer" value for "@key" tag in "jtreg" test, because until that moment I mistakenly thought that it was just a marker used for selection of tests marked with it for running and nothing else.

DIFFERENCES INTRODUCED IN THE 3'RD VERSION OF THE FIX:

THE FIX:
1. "RuntimeException" is wrapped in new "PrinterException" in "CPrinterJob.print(PrintRequestAttributeSet)" to guarantee that the fix can propagate only "PrinterException" from "PrinterJob.print()".

THE REGRESSION TEST:
1. The test is now fully automatic, "manual" is removed from all JTREG "main" actions. I verified it on MACH and locally.

2. I addressed your concerns from previous comments and now no exception is thrown from "ExceptionFromPrintableIsIgnoredTest.runTest" method, so there is no any possibility that AWT thread will be crashed by the exception thrown by the test. Now I just execute "PrinterJob.print()" and store any "Throwable" possibly thrown by that method in the instance variable "private volatile Throwable printError" of the test class. And analyze it always on main thread after completion of execution of "ExceptionFromPrintableIsIgnoredTest.runTest" call.

3. Now the regression test always expects only "PrinterException" to be thrown by "PrinterJob.print()". Since "RuntimeException" is propagated from "PrinterJob.print()" on Windows OS and on Linux OS two test scenarios with "RuntimeException":
- "@run main ExceptionFromPrintableIsIgnoredTest MAIN RE"
- "@run main ExceptionFromPrintableIsIgnoredTest EDT RE"

are not executed by the test on Windows and Linux deliberately, otherwise they are failing. This test restriction is implemented by the "if" condition "if ((exceptionType == TestExceptionType.RE) && !isOSX) {".

Hopefully this version of the fix is more acceptable.

Thank you,
Anton

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

PR: https://git.openjdk.java.net/jdk/pull/4036

From prr at openjdk.java.net  Fri Jun 11 19:49:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Jun 2021 19:49:51 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <Hq8IfS5pQzDDvvY3wgaS9oL1ZahAxjq3DkhfLoWnPoM=.bd72512d-e4d3-4634-b07b-93d50c825069@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Ok. Please file a bug as you mention to bring the other platforms into line.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4036

From avu at openjdk.java.net  Mon Jun 14 06:58:19 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 14 Jun 2021 06:58:19 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
Message-ID: <mzG3oWm95EGqk7GCCr0y_wvb-PJKOQdYefRqKE_RIwc=.e1ee36b7-d948-433e-aa8a-57593aa4ec87@github.com>

On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Set black color for underlying window background to perform correct blending operations in metal with window surface destination

Reimplemented solution using compute shader

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From avu at openjdk.java.net  Mon Jun 14 06:58:18 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 14 Jun 2021 06:58:18 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL [v2]
In-Reply-To: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
Message-ID: <JviXa94f7TQHOFZDZl1b4Px7Q-WIdn_nx5kdmJrYHZ8=.83158023-8b2f-4a8d-8fff-aa392ed1bb9d@github.com>

> Set black color for underlying window background to perform correct blending operations in metal with window surface destination

Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Implemented blit via compute kernel

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

Changes: https://git.openjdk.java.net/jdk/pull/4206/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4206&range=01
  Stats: 289 lines in 4 files changed: 288 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4206/head:pull/4206

PR: https://git.openjdk.java.net/jdk/pull/4206

From alitvinov at openjdk.java.net  Mon Jun 14 13:13:50 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Jun 2021 13:13:50 GMT
Subject: <AWT Dev> RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <Y7cMBO-NtewjxMkh6NGvedbOULhmz6WUM6ltUC4YNMQ=.65cd67f8-a4cd-4bc5-a9ea-93f7d0dce4cf@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Hello Phil. Thank you for approval of the fix. The new bug about the discovered propagation of the RTE on Windows OS and Linux OS is created, it is (https://bugs.openjdk.java.net/browse/JDK-8268675).

Thank you,
Anton

________________________________________
From: prrace ***@***.***>
Sent: 11 June 2021 20:47
To: openjdk/jdk
Cc: Anton Litvinov; Mention
Subject: [External] : Re: [openjdk/jdk] 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" (#4036)

@prrace approved this pull request.

Ok. Please file a bug as you mention to bring the other platforms into line.

?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4036*pullrequestreview-682168475__;Iw!!GqivPVa7Brio!O44TB5FBjFmxmBOMWJaShp0YE2GnSsoKioCVpjjeiWAFttaxMCzjTqiQ8X7BFHWNytY$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AQY7S7FDBITH5EYGP42RUTLTSJR5XANCNFSM44443KWA__;!!GqivPVa7Brio!O44TB5FBjFmxmBOMWJaShp0YE2GnSsoKioCVpjjeiWAFttaxMCzjTqiQ8X7BFC_1zPk$>.

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

PR: https://git.openjdk.java.net/jdk/pull/4036

From alitvinov at openjdk.java.net  Mon Jun 14 13:32:14 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Jun 2021 13:32:14 GMT
Subject: <AWT Dev> Integrated: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print"
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <wTM7hzTJPQSCaLBssMow8o6ZP1negBNqKQZOAdRxQhE=.2f2573e5-3126-4a80-8ba8-99a74c55d440@github.com>

On Fri, 14 May 2021 18:37:46 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

This pull request has now been integrated.

Changeset: c0b4407d
Author:    Anton Litvinov <alitvinov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0b4407d09a7bf9f15553dc5344b1e354b150d57
Stats:     169 lines in 2 files changed: 160 ins; 0 del; 9 mod

8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

Reviewed-by: prr

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

PR: https://git.openjdk.java.net/jdk/pull/4036

From serb at openjdk.java.net  Mon Jun 14 17:28:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Jun 2021 17:28:05 GMT
Subject: <AWT Dev> RFR: 8268620: InfiniteLoopException test may fail on x86
 platforms
Message-ID: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>

Small test update.

This test posts lots of events to EDT from the different threads, and it checks that the robot.waitForIdle() on the main thread will not hang or throw an exception. And this test fails on x86. The post of events are implemented via wait/notifyAll, and the robot.waitForIdle() is also implemented via wait/notifyAll on the same monitor, and on x86 platform, the wait() in the robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it hangs forever.

I do not think this bug is specific to the x86(I tested 8u), it is just accidentally working fine on the mainline.

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

Commit messages:
 - Merge branch 'master' into JDK-8268620
 - Update InfiniteLoopException.java

Changes: https://git.openjdk.java.net/jdk/pull/4488/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4488&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268620
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4488.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4488/head:pull/4488

PR: https://git.openjdk.java.net/jdk/pull/4488

From prr at openjdk.java.net  Mon Jun 14 19:15:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Jun 2021 19:15:53 GMT
Subject: <AWT Dev> RFR: 8268620: InfiniteLoopException test may fail on
 x86 platforms
In-Reply-To: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
References: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
Message-ID: <RIPTWDchk5W2BkK6qPpit3Yer4bL8bIxTeN9_HkQKuQ=.52315468-4068-49f5-8d4c-0c2a12ac94bf@github.com>

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small test update.
> 
> This test posts lots of events to EDT from the different threads, and it checks that the robot.waitForIdle() on the main thread will not hang or throw an exception. And this test fails on x86. The post of events are implemented via wait/notifyAll, and the robot.waitForIdle() is also implemented via wait/notifyAll on the same monitor, and on x86 platform, the wait() in the robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it hangs forever.
> 
> I do not think this bug is specific to the x86(I tested 8u), it is just accidentally working fine on the mainline.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4488

From prr at openjdk.java.net  Mon Jun 14 19:29:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Jun 2021 19:29:53 GMT
Subject: <AWT Dev> RFR: 8240756: [macos] SwingSet2:TableDemo:Printed
 Japanese characters were garbled
In-Reply-To: <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
 <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
Message-ID: <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>

On Fri, 23 Apr 2021 09:45:45 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
>
>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
> 
> Hi Sergey, Thank you for the comments.
> 
> JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function.
> 
> In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition.
> sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
> 
> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way.
> 
> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods.

@toshiona - is this PR dead ?

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

PR: https://git.openjdk.java.net/jdk/pull/3619

From prr at openjdk.java.net  Mon Jun 14 19:34:56 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Jun 2021 19:34:56 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL
In-Reply-To: <mzG3oWm95EGqk7GCCr0y_wvb-PJKOQdYefRqKE_RIwc=.e1ee36b7-d948-433e-aa8a-57593aa4ec87@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <mzG3oWm95EGqk7GCCr0y_wvb-PJKOQdYefRqKE_RIwc=.e1ee36b7-d948-433e-aa8a-57593aa4ec87@github.com>
Message-ID: <-Pxqhwf240WmaFSRHNIlVi4zMzuzunwJyFdep1ZXpl4=.38ff3c04-85e9-41f8-ab36-3d6b3012e0e5@github.com>

On Mon, 14 Jun 2021 06:54:39 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Set black color for underlying window background to perform correct blending operations in metal with window surface destination
>
> Reimplemented solution using compute shader

@avu - Aren't we targeting this to 17 ? Assuming yes, I think you need to submit a new PR against the JDK 17 
stabilsation repo .. and withdraw this one.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From trebari at openjdk.java.net  Tue Jun 15 06:20:48 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 15 Jun 2021 06:20:48 GMT
Subject: <AWT Dev> RFR: 8268620: InfiniteLoopException test may fail on
 x86 platforms
In-Reply-To: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
References: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
Message-ID: <yVD3ZlBflnSdveEfx8qtgM9h-gR_w7yVlNdLdhemnUQ=.8685653c-eff2-4630-8565-d9133d500ed1@github.com>

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small test update.
> 
> This test posts lots of events to EDT from the different threads, and it checks that the robot.waitForIdle() on the main thread will not hang or throw an exception. And this test fails on x86. The post of events are implemented via wait/notifyAll, and the robot.waitForIdle() is also implemented via wait/notifyAll on the same monitor, and on x86 platform, the wait() in the robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it hangs forever.
> 
> I do not think this bug is specific to the x86(I tested 8u), it is just accidentally working fine on the mainline.

Marked as reviewed by trebari (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/4488

From azvegint at openjdk.java.net  Tue Jun 15 13:03:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 15 Jun 2021 13:03:41 GMT
Subject: <AWT Dev> RFR: 8268620: InfiniteLoopException test may fail on
 x86 platforms
In-Reply-To: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
References: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
Message-ID: <esPq9-I1vg_oc_veT5y_G0Q02lzCf-Tjy2LJA7gFxW4=.8dbd85c5-50e3-454d-93cd-b19c590d20c9@github.com>

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small test update.
> 
> This test posts lots of events to EDT from the different threads, and it checks that the robot.waitForIdle() on the main thread will not hang or throw an exception. And this test fails on x86. The post of events are implemented via wait/notifyAll, and the robot.waitForIdle() is also implemented via wait/notifyAll on the same monitor, and on x86 platform, the wait() in the robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it hangs forever.
> 
> I do not think this bug is specific to the x86(I tested 8u), it is just accidentally working fine on the mainline.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4488

From serb at openjdk.java.net  Tue Jun 15 15:32:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 15 Jun 2021 15:32:44 GMT
Subject: <AWT Dev> Integrated: 8268620: InfiniteLoopException test may fail
 on x86 platforms
In-Reply-To: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
References: <26KA8hjvYKk1XDykLBeKcrslCZDPr610v84wWbtQEXo=.03f1af99-486a-404a-88fd-c4306ae1b06b@github.com>
Message-ID: <yxxpIIEmcCwKxIVvymHSzQFHfINuRodfZ5NObjbhJRE=.9e922f6f-4046-42e0-aecc-0ea1a9ce3915@github.com>

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small test update.
> 
> This test posts lots of events to EDT from the different threads, and it checks that the robot.waitForIdle() on the main thread will not hang or throw an exception. And this test fails on x86. The post of events are implemented via wait/notifyAll, and the robot.waitForIdle() is also implemented via wait/notifyAll on the same monitor, and on x86 platform, the wait() in the robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it hangs forever.
> 
> I do not think this bug is specific to the x86(I tested 8u), it is just accidentally working fine on the mainline.

This pull request has now been integrated.

Changeset: 0b09129f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b09129faefb945c2f2c35dab2731961216d054e
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8268620: InfiniteLoopException test may fail on x86 platforms

Reviewed-by: prr, trebari, azvegint

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

PR: https://git.openjdk.java.net/jdk/pull/4488

From avu at openjdk.java.net  Tue Jun 15 17:01:57 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 15 Jun 2021 17:01:57 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences
 on Metal compared to OpenGL [v2]
In-Reply-To: <JviXa94f7TQHOFZDZl1b4Px7Q-WIdn_nx5kdmJrYHZ8=.83158023-8b2f-4a8d-8fff-aa392ed1bb9d@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
 <JviXa94f7TQHOFZDZl1b4Px7Q-WIdn_nx5kdmJrYHZ8=.83158023-8b2f-4a8d-8fff-aa392ed1bb9d@github.com>
Message-ID: <cAKLlQZmwmUiC0yzWUisAfRO0jIboliJgCX9PABJfYY=.960700e5-4f84-46b0-afad-b22b94696429@github.com>

On Mon, 14 Jun 2021 06:58:18 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Set black color for underlying window background to perform correct blending operations in metal with window surface destination
>
> Alexey Ushakov 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 one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Implemented blit via compute kernel

Created separate pull request in jdk17 repo: https://github.com/openjdk/jdk17/pull/62

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From avu at openjdk.java.net  Tue Jun 15 17:01:57 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 15 Jun 2021 17:01:57 GMT
Subject: <AWT Dev> Withdrawn: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
References: <TvdcoI1B0pj49szVv22Kc-cKkyShwRHUVcK4981Fkz4=.31eb97ce-c213-4214-9362-bcbc6dd08788@github.com>
Message-ID: <E0IxckwPMPw8rJBchbSYAofse_2aBkrXpAdOXM2yGYg=.eea199a2-1f38-4450-ba77-045568a5987c@github.com>

On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Set black color for underlying window background to perform correct blending operations in metal with window surface destination

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4206

From avu at openjdk.java.net  Tue Jun 15 17:03:02 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 15 Jun 2021 17:03:02 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
Message-ID: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>

Implemented blit via compute kernel

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

Commit messages:
 - 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

Changes: https://git.openjdk.java.net/jdk17/pull/62/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266079
  Stats: 289 lines in 4 files changed: 288 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Tue Jun 15 17:50:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 15 Jun 2021 17:50:43 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

Marked as reviewed by serb (Reviewer).

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:

> 157:         [computeEncoder endEncoding];
> 158:         [cb commit];
> 159: #endif

This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
Since this affects every blit to the window I suggest running a full test run.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Wed Jun 16 10:37:31 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 16 Jun 2021 10:37:31 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
Message-ID: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>

On Tue, 15 Jun 2021 17:47:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
> 
>> 157:         [computeEncoder endEncoding];
>> 158:         [cb commit];
>> 159: #endif
> 
> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
> Since this affects every blit to the window I suggest running a full test run.

@jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Wed Jun 16 11:59:34 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 16 Jun 2021 11:59:34 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
Message-ID: <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>

On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
>> 
>>> 157:         [computeEncoder endEncoding];
>>> 158:         [cb commit];
>>> 159: #endif
>> 
>> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
>> Since this affects every blit to the window I suggest running a full test run.
>
> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

@avu i have given all test run. I will get back to you once it is done.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From kizune at openjdk.java.net  Wed Jun 16 17:51:48 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 16 Jun 2021 17:51:48 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <4CZCGYIDcZlVhckVi87sZpwUATr3w9yT_7o5eBD1s5U=.1b564e7b-7861-486a-a53e-7ff04084e994@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 372:

> 370:     if ([javaRole isEqualToString:@"pagetablist"]) {
> 371:         newChild = [TabGroupLegacyAccessibility alloc];
> 372:     } else if ([javaRole isEqualToString:@"table"]) {

Do we even need legacy peer implementation in the new classes?

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From vdyakov at openjdk.java.net  Wed Jun 16 18:06:21 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 16 Jun 2021 18:06:21 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <kzH6o-P-P5TfXfYIH-SE2ZhfG9HCAmpNJe-ybydWJSw=.0c32a713-5011-4b2e-bc9a-21d703bac5d4@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

@pbansal  The initial change - to move functionality from JavaComponentAccessibility to CommonComponentAccessibility requires touching up of almost all (if not all) of the new files in this project - this is why too much change being done in one PR as a reason why has been decided to push all the components in one PR go instead of doing things component by component like we did in the past. We just need to spend much more time on this review and the good thing is that this Change will be baked in 18 EA enough time versus 17 which is already on stabilization phase.

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From serb at openjdk.java.net  Wed Jun 16 21:25:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Jun 2021 21:25:38 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 130:

> 128:         if (c != null) {
> 129:             try {
> 130:                 value = EventQueue.isDispatchThread() ? callable.call() : LWCToolkit.invokeAndWait(callable, c);

When this method is called on EDT?

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 556:

> 554:                     ((JList) parent).setSelectedIndex(i);
> 555:                     return;
> 556:                 }

Looks like the a11y interface miss "setSelectedIndex" method? The code above will not work for the custom component which uses the "AccessibleJListChild" a11y object?

src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 50:

> 48: #define JAVA_AX_ALL_CHILDREN (-1)
> 49: #define JAVA_AX_SELECTED_CHILDREN (-2)
> 50: #define JAVA_AX_VISIBLE_CHILDREN (-3)

Why not mark them as @native in the CAccessibility  and use constants generated by the javac?

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m line 79:

> 77:     if (values == NULL) {
> 78:         // Note: Java will not be on the stack here so a java exception can't happen and no need to call ExceptionCheck.
> 79:         NSLog(@"%s failed calling GetDoubleArrayElements", __FUNCTION__);

Please clarify the comment above.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 44:

> 42:     jclass clsInfo = (*env)->GetObjectClass(env, axContext);
> 43:     DECLARE_METHOD_RETURN(jm_getAccessibleRowCount, clsInfo, "getAccessibleRowCount", "()I", 0);
> 44:     jint javaRowsCount = (*env)->CallIntMethod(env, axContext, jm_getAccessibleRowCount);

Do we need to check the java exception here and in other similar cases? This code is executed on appkit?

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 155:

> 153: - (NSArray *)accessibilitySelectedChildren
> 154: {
> 155:     return [self accessibilitySelectedRows];

Does it mean that the children of the table are rows and columns and not "cells".? How it will work if only one cell is selected?

test/jdk/java/awt/a11y/AccessibleJComboboxTest.java line 30:

> 28:  * @summary Create implementation for NSAccessibilityComboBox protocol peer
> 29:  * @author Artem.Semenov at jetbrains.com
> 30:  * @run main/manual AccessibleJComboboxTest

On what platforms these tests are supposed to work?

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From jdv at openjdk.java.net  Thu Jun 17 07:10:10 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 07:10:10 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136:

> 134:         NSUInteger w = computePipelineState.threadExecutionWidth;
> 135: 
> 136:         // Workaround for some OS/device bug reporting incorrect maxTotalThreadsPerThreadgroup

@avu Do we know in which hardware we have this issue? Also do we have any reference to Apple bug?
Also if we use thread group as 1 what is the performance impact in such hardware?

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Thu Jun 17 07:15:12 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 07:15:12 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
 <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>
Message-ID: <L6wARnjCs-1NRUPoEbMw54Ab8HOPY0iV3v3XV5lRmpk=.44f47b2a-76d2-450a-892d-a5d43052fb1e@github.com>

On Wed, 16 Jun 2021 11:57:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository
>
> @avu i have given all test run. I will get back to you once it is done.

Automated jtreg/JCK test run is green.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From tnakamura at openjdk.java.net  Thu Jun 17 09:29:07 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 17 Jun 2021 09:29:07 GMT
Subject: <AWT Dev> RFR: 8240756: [macos] SwingSet2:TableDemo:Printed
 Japanese characters were garbled [v2]
In-Reply-To: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
Message-ID: <gSWVk7c86gLoQBXz4BUgx_lBDXMlpcX52cte4mf96ss=.134edd2c-4630-4df4-b0e3-ba1d31328a1c@github.com>

> Hi,
> 
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
> 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. 
> 
> This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path.
> 
> Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice.
> Tested java/awt and javax/swing on MacOS BigSur, and there was no regression.
> 
> Regards,
> Toshio Nakamura

Toshio Nakamura 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:

 - 2nd proposal
 - Revert previous change
 - Merge branch 'master' into 8240756
   merge master
 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3619/files
  - new: https://git.openjdk.java.net/jdk/pull/3619/files/9d99458c..c2910791

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=00-01

  Stats: 1152276 lines in 9449 files changed: 556262 ins; 566916 del; 29098 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619

PR: https://git.openjdk.java.net/jdk/pull/3619

From tnakamura at openjdk.java.net  Thu Jun 17 09:29:08 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 17 Jun 2021 09:29:08 GMT
Subject: <AWT Dev> RFR: 8240756: [macos] SwingSet2:TableDemo:Printed
 Japanese characters were garbled
In-Reply-To: <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
 <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
 <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>
Message-ID: <ggQJztCX7uUW2RXvz_c0B7OANyJMn_FHCHjnEwbq7Yo=.bc94ec7c-2d94-4031-b13b-3c2f0542894d@github.com>

On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race <prr at openjdk.org> wrote:

>>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
>> 
>> Hi Sergey, Thank you for the comments.
>> 
>> JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function.
>> 
>> In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition.
>> sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
>> 
>> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way.
>> 
>> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods.
>
> @toshiona - is this PR dead ?

@prrace 
I'm deeply sorry for the long delay.
I completely changed the patch to use a different layer (SwingUtilities2.java).

> The immediately next method in this file, drawGlyphVector(..) surely would have the same problem ?

Yes, I had to say the bottom methods (Core Graphics Framework's CGContextShowGlyphsWithAdvances and CGContextShowGlyphsAtPoint) seem no capability to handle multi fonts.

> And then the drawChars method too ?

No. If we can use Unicode codes, fallback mechanism can work.

> Does this not in fact affect all code points for which the slot != 0 ?

Yes. I believe all slot !=0 glyphs have the issue.

> Do we really want to print all code points from slot > 0 as shapes ? 

No, it's a kind of workaround. I thought the effects of the change can be minimized.

> And if this code isn't expecting to handle composite fonts, how did we get here with one ?
> Or maybe the problem is that the printing path code needs to handle this downstream not upstream ?

The new version changed the branching conditions. If it's MacOS, that won't branch to the printing path, which uses Glyph codes.

Well, I still couldn't create an automate test.

I appreciate any advices.

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

PR: https://git.openjdk.java.net/jdk/pull/3619

From jdv at openjdk.java.net  Thu Jun 17 09:44:14 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 09:44:14 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>
Message-ID: <VHriLswBqHagFxgiPOv22RexH1Xf4AMUe7K55dCx_-s=.021519f6-1622-46cc-b9b8-ce4802c6095d@github.com>

On Thu, 17 Jun 2021 07:06:24 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136:
> 
>> 134:         NSUInteger w = computePipelineState.threadExecutionWidth;
>> 135: 
>> 136:         // Workaround for some OS/device bug reporting incorrect maxTotalThreadsPerThreadgroup
> 
> @avu Do we know in which hardware we have this issue? Also do we have any reference to Apple bug?
> Also if we use thread group as 1 what is the performance impact in such hardware?

Forced maxTotalThreadsPerThreadgroup to 1 and tested in Intel SoC 2015 Macbook Pro, as expected i see almost ~50% reduction in FPS numbers in many use cases in RenderPerfTest. This final blit hits common operation and we would be able to make better decision whether this performance reduction is okay or not based on hardware in which we are seeing Apple bug.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Thu Jun 17 10:21:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 10:21:09 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <bA2208vnJVqsnRNOJgNlaL_-9TqHO1faPe36byX-h28=.8d268720-4493-42c4-8415-e715cc4a98ee@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

With this patch shaped windows with translucent/color background are showing only black background. In manual JCK shaped window test also this difference in behaviour is seen.

This behaviour difference can be checked using Ruler.java test case attached in https://bugs.openjdk.java.net/browse/JDK-8267963

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From aghaisas at openjdk.java.net  Thu Jun 17 11:30:12 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 17 Jun 2021 11:30:12 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <SuL-tRkrTJOgpmcUgoVjLS6lsYFjG9CviTGsHj2kFa4=.4cae3fe0-9992-47fe-ae8e-ecd12838beb6@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

What I have observed with this patch is - It does not break all shaped or translucent windows - but, a manual JCK test does show the black background.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Thu Jun 17 13:00:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 17 Jun 2021 13:00:11 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
Message-ID: <RR4jJ7Q2sbfF6Rt8QpRu2_Akla5pfbozd0HeSVpV_tM=.c124052f-f409-458e-97ab-8c4d5bf9c7b7@github.com>

On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
>> 
>>> 157:         [computeEncoder endEncoding];
>>> 158:         [cb commit];
>>> 159: #endif
>> 
>> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
>> Since this affects every blit to the window I suggest running a full test run.
>
> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

@avu If all our automated tests are green but we still have some issues, then an additional automated test needs to be added.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From azvegint at openjdk.java.net  Thu Jun 17 16:08:57 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 17 Jun 2021 16:08:57 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v3]
In-Reply-To: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
Message-ID: <gAdA-J7gfm3Z4GbPwx8KbnIIHX5rMyh7EvGxC0krEw8=.ee594799-8212-496c-86c0-944fcfcc40f6@github.com>

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.

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

  update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/a265fc99..b5432e78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From azvegint at openjdk.java.net  Thu Jun 17 17:33:48 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 17 Jun 2021 17:33:48 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v4]
In-Reply-To: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
Message-ID: <55jeY_MsaJCzIKXw1athgxdtSbisV6GVPBd2VQEk3fo=.33d3ed78-eea2-4d71-9007-0d15bd602a20@github.com>

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.

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

  header fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/b5432e78..312abff4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From prr at openjdk.java.net  Thu Jun 17 20:34:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Jun 2021 20:34:29 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v4]
In-Reply-To: <55jeY_MsaJCzIKXw1athgxdtSbisV6GVPBd2VQEk3fo=.33d3ed78-eea2-4d71-9007-0d15bd602a20@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
 <55jeY_MsaJCzIKXw1athgxdtSbisV6GVPBd2VQEk3fo=.33d3ed78-eea2-4d71-9007-0d15bd602a20@github.com>
Message-ID: <XOWqelQs5TkW30UuLrzqCEnsCW6wYjojeExvvbiuJMc=.df5cd5e6-eaa0-4d92-8301-be1fb6a2951a@github.com>

On Thu, 17 Jun 2021 17:33:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
>> 
>> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   header fix

src/java.desktop/share/classes/java/awt/Taskbar.java line 325:

> 323: 
> 324:     /**
> 325:      * Suggests the system to change this application's icon to the provided {@code image}.

Suggests -> Requests

src/java.desktop/share/classes/java/awt/Taskbar.java line 341:

> 339:     /**
> 340:      * Obtains an image of this application's icon.
> 341:      * <p>

As discussed off-line, preface this with "@apiNote"

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From azvegint at openjdk.java.net  Thu Jun 17 20:49:59 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 17 Jun 2021 20:49:59 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v5]
In-Reply-To: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
Message-ID: <jOwCXH1DolcClljx4KVCEWNt6mgzGW1j4RW7bXaqyWM=.62b5d0a0-0069-4e6f-a6b4-aab5930d7d13@github.com>

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.

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

  @apiNote added, Suggests -> Requests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/312abff4..4e5273e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3250&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From azvegint at openjdk.java.net  Thu Jun 17 20:54:27 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 17 Jun 2021 20:54:27 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v4]
In-Reply-To: <XOWqelQs5TkW30UuLrzqCEnsCW6wYjojeExvvbiuJMc=.df5cd5e6-eaa0-4d92-8301-be1fb6a2951a@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
 <55jeY_MsaJCzIKXw1athgxdtSbisV6GVPBd2VQEk3fo=.33d3ed78-eea2-4d71-9007-0d15bd602a20@github.com>
 <XOWqelQs5TkW30UuLrzqCEnsCW6wYjojeExvvbiuJMc=.df5cd5e6-eaa0-4d92-8301-be1fb6a2951a@github.com>
Message-ID: <e11Qv-OwB2G1IA7nahoEv85PTd8VPVTja26z6q0Z8w4=.8af95e56-c826-4637-9173-0d84393735fa@github.com>

On Thu, 17 Jun 2021 20:31:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   header fix
>
> src/java.desktop/share/classes/java/awt/Taskbar.java line 341:
> 
>> 339:     /**
>> 340:      * Obtains an image of this application's icon.
>> 341:      * <p>
> 
> As discussed off-line, preface this with "@apiNote"

updated

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From prr at openjdk.java.net  Thu Jun 17 21:11:27 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Jun 2021 21:11:27 GMT
Subject: <AWT Dev> RFR: 8264125: Specification of Taskbar::getIconImage
 doesn't mention that the returned image might not be equal to the
 Taskbar::setIconImage one. (eg on Mac OS) [v5]
In-Reply-To: <jOwCXH1DolcClljx4KVCEWNt6mgzGW1j4RW7bXaqyWM=.62b5d0a0-0069-4e6f-a6b4-aab5930d7d13@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
 <jOwCXH1DolcClljx4KVCEWNt6mgzGW1j4RW7bXaqyWM=.62b5d0a0-0069-4e6f-a6b4-aab5930d7d13@github.com>
Message-ID: <0A1qif4jSIFhF7GAtked5Jyph-U2dycchoYkD-Dj81Y=.172d0956-615b-4f12-ba01-2b644178a1a2@github.com>

On Thu, 17 Jun 2021 20:49:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
>> 
>> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @apiNote added, Suggests -> Requests

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From avu at openjdk.java.net  Mon Jun 21 18:00:37 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 21 Jun 2021 18:00:37 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <j0N0mujnw8_9jyBo59F1JRcDmlv1nhMQqb42Ne53Rf0=.0542ca07-75cb-4c5e-a368-1e046f4ebfdb@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

Just found the more simple solution to this problem: we can still use old blit code and keep MTLLayer opacity property in sync with contentView of the window (CWraper.setOpaque).

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Wed Jun 23 12:15:03 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 23 Jun 2021 12:15:03 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v2]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>

> Implemented blit via compute kernel

Alexey Ushakov 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:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep MTLLayer opacity in sync with window content view

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/4d1b80ff..3eef431e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=00-01

  Stats: 56 lines in 4 files changed: 4 ins; 50 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From azvegint at openjdk.java.net  Sat Jun 26 16:01:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 26 Jun 2021 16:01:06 GMT
Subject: <AWT Dev> Integrated: 8264125: Specification of
 Taskbar::getIconImage doesn't mention that the returned image might not be
 equal to the Taskbar::setIconImage one. (eg on Mac OS)
In-Reply-To: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
References: <k4kKWsnbnR_UBnHkd2iPEB9d06Pp9WwfnR-4ScjIwBk=.b948d97b-e6ec-4e3a-ace5-b13b93c99637@github.com>
Message-ID: <0gncBSpHERD-g2CoQTNaqZ2H1Dlz_qRkodD5djL72Vk=.e030b45e-b26d-428d-9dda-c38b8d96281d@github.com>

On Mon, 29 Mar 2021 18:57:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which supports this feature), but I want to save some options if we decide to rework this.

This pull request has now been integrated.

Changeset: 51a1299b
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51a1299b68fb3a2e58de20209745c89f1d5f9ed3
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

Reviewed-by: kizune, prr

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

PR: https://git.openjdk.java.net/jdk/pull/3250

From javalists at cbfiddle.com  Sun Jun 27 17:24:17 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 27 Jun 2021 10:24:17 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event thread
 in JDK 17
Message-ID: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>

I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).

It?s a fairly complicated situation.

On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.

The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.

Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.

If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.

But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.

With run loops on both threads, what would cause the deadlock?

[Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]

I would appreciate any suggestions of what might be going wrong or how to track it down.

  Alan


From javalists at cbfiddle.com  Mon Jun 28 12:51:17 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Jun 2021 05:51:17 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
Message-ID: <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>

Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.

If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.

It also sounds like a gratuitous change.



> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
> 
> It?s a fairly complicated situation.
> 
> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
> 
> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
> 
> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
> 
> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
> 
> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
> 
> With run loops on both threads, what would cause the deadlock?
> 
> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
> 
> I would appreciate any suggestions of what might be going wrong or how to track it down.
> 
>  Alan
> 


From mik3hall at gmail.com  Mon Jun 28 13:29:11 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 28 Jun 2021 08:29:11 -0500
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
Message-ID: <801F404D-840B-4039-8472-3466B78898D4@gmail.com>



> On Jun 28, 2021, at 7:51 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
> 
> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
> 
> It also sounds like a gratuitous change.

Since AWT stopped using it, how supported is JavaNativeFoundation going forward for the JDK? Not that this means it?s ok to break other code using it without some reason.

There is directly? 
performSelectorOnMainThread
You can even do a java callback from the selector to do java on the main thread. I had some code going back to Apple Java to do that. 

From javalists at cbfiddle.com  Mon Jun 28 14:03:53 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Jun 2021 07:03:53 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
Message-ID: <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>

You can call performSelectorOnMainThread directly, but you have to know the name of the AWT/Java run loop to avoid the deadlock situations that I have encountered.

The name of the run loop needs to be part of the public API.

By the way, upcalls from AppKit to get accessibility information has been a source of problems for a long time. I don?t suppose there is any way that Java can respond to these requests without running code on the AWT event thread?



> On Jun 28, 2021, at 6:29 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 28, 2021, at 7:51 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>> 
>> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>> 
>> It also sounds like a gratuitous change.
> 
> Since AWT stopped using it, how supported is JavaNativeFoundation going forward for the JDK? Not that this means it?s ok to break other code using it without some reason.
> 
> There is directly? 
> performSelectorOnMainThread
> You can even do a java callback from the selector to do java on the main thread. I had some code going back to Apple Java to do that. 


From mik3hall at gmail.com  Mon Jun 28 14:16:03 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 28 Jun 2021 09:16:03 -0500
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
 <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
Message-ID: <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>



> On Jun 28, 2021, at 9:03 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> You can call performSelectorOnMainThread directly, but you have to know the name of the AWT/Java run loop to avoid the deadlock situations that I have encountered.
> 
> The name of the run loop needs to be part of the public API.

I haven?t successfully done much with the native run loop. I didn?t quite follow your deadlock either. What was it blocked on? It almost sounded like three starvation where the thread just never got run for some reason. Or you aren?t sure what the deadlock is on? I did get into deadlocks trying to do a OS X native watch service  using kqueue that I never figured out.  
 Which public API? JavaNativeFoundation?

> 
> By the way, upcalls from AppKit to get accessibility information has been a source of problems for a long time. I don?t suppose there is any way that Java can respond to these requests without running code on the AWT event thread?

Again native I have done hasn?t involved anything to do with AppKit so I?m not sure what you?re looking for here either. 

From javalists at cbfiddle.com  Mon Jun 28 14:30:01 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Jun 2021 07:30:01 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
 <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
 <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>
Message-ID: <BFADB34D-F11A-43C1-90C0-57B0D6C495EA@cbfiddle.com>

My code (#2) running on the AWT thread is blocked trying to perform selector on main thread waiting YES. It is blocked because it does not specify that it can be run under the javaRunLoopMode. It specifies the AWTRunLoopMode, which is the old name. That name is supplied by JavaNativeFoundation.

The main thread is blocked waiting for an upcall to Java to get accessibility information, which is blocked waiting for code to run on the AWT thread.

Neither thread can proceed until the other one completes its operation. Hence, a deadlock.

In both cases, ?blocked? is a soft block, because both threads are running a nested run loop, but the conditions for exiting those run loops are not met.

The run loop name used by AWT needs to be part of the public API of the JDK.



> On Jun 28, 2021, at 7:16 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 28, 2021, at 9:03 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> You can call performSelectorOnMainThread directly, but you have to know the name of the AWT/Java run loop to avoid the deadlock situations that I have encountered.
>> 
>> The name of the run loop needs to be part of the public API.
> 
> I haven?t successfully done much with the native run loop. I didn?t quite follow your deadlock either. What was it blocked on? It almost sounded like three starvation where the thread just never got run for some reason. Or you aren?t sure what the deadlock is on? I did get into deadlocks trying to do a OS X native watch service  using kqueue that I never figured out.  
> Which public API? JavaNativeFoundation?
> 
>> 
>> By the way, upcalls from AppKit to get accessibility information has been a source of problems for a long time. I don?t suppose there is any way that Java can respond to these requests without running code on the AWT event thread?
> 
> Again native I have done hasn?t involved anything to do with AppKit so I?m not sure what you?re looking for here either. 


From mik3hall at gmail.com  Mon Jun 28 14:43:47 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 28 Jun 2021 09:43:47 -0500
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <BFADB34D-F11A-43C1-90C0-57B0D6C495EA@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
 <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
 <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>
 <BFADB34D-F11A-43C1-90C0-57B0D6C495EA@cbfiddle.com>
Message-ID: <76A96B3A-A805-4D60-9EF1-59757613E3D4@gmail.com>



> On Jun 28, 2021, at 9:30 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> My code (#2) running on the AWT thread is blocked trying to perform selector on main thread waiting YES. It is blocked because it does not specify that it can be run under the javaRunLoopMode. It specifies the AWTRunLoopMode, which is the old name. That name is supplied by JavaNativeFoundation.

Sorry for mostly noise on this.
I?m again not familiar with the JNF that requires the run loop name.

> 
> The main thread is blocked waiting for an upcall to Java to get accessibility information, which is blocked waiting for code to run on the AWT thread.
> 
> Neither thread can proceed until the other one completes its operation. Hence, a deadlock.

> 
> In both cases, ?blocked? is a soft block, because both threads are running a nested run loop, but the conditions for exiting those run loops are not met.

OK. 

> 
> The run loop name used by AWT needs to be part of the public API of the JDK.

Offhand I see no reason AWT discontinuing use of JNF itself would require this name change. If 3rd party code requires the run loop name and the jdk continues to have such a name without JNF they should have it available somewhere. 

JNF itself without AWT using it seems to me will probably not have a lot of ongoing support and could be difficult to continue using. I had a little trouble a little while ago where I no longer had a framework that provided it and had to resort to using what the Xcode SDK provided. If that is discontinued? 



From javalists at cbfiddle.com  Mon Jun 28 14:50:08 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Jun 2021 07:50:08 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <76A96B3A-A805-4D60-9EF1-59757613E3D4@gmail.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
 <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
 <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>
 <BFADB34D-F11A-43C1-90C0-57B0D6C495EA@cbfiddle.com>
 <76A96B3A-A805-4D60-9EF1-59757613E3D4@gmail.com>
Message-ID: <6B88D7DE-ED92-4D9C-97D7-50EEBC6EC9F1@cbfiddle.com>

To avoid this deadlock, the run loop name is required when using the NSObject method performSelectorOnMainThread:withObject:waitUntilDone:modes: <https://developer.apple.com/documentation/objectivec/nsobject/1411637-performselectoronmainthread>

JNF calls this method with the ?old? run loop name.

> On Jun 28, 2021, at 7:43 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I?m again not familiar with the JNF that requires the run loop name.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210628/8bfb2735/attachment.htm>

From mik3hall at gmail.com  Mon Jun 28 14:53:19 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 28 Jun 2021 09:53:19 -0500
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <6B88D7DE-ED92-4D9C-97D7-50EEBC6EC9F1@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <801F404D-840B-4039-8472-3466B78898D4@gmail.com>
 <A5C3181F-32C1-46EC-BC62-CD791D61DFFE@cbfiddle.com>
 <1E725C05-E36C-415E-B0A2-CF233FA30E41@gmail.com>
 <BFADB34D-F11A-43C1-90C0-57B0D6C495EA@cbfiddle.com>
 <76A96B3A-A805-4D60-9EF1-59757613E3D4@gmail.com>
 <6B88D7DE-ED92-4D9C-97D7-50EEBC6EC9F1@cbfiddle.com>
Message-ID: <1B9E2F3E-2CE8-4AE1-9E28-98B26B5B2024@gmail.com>



> On Jun 28, 2021, at 9:50 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> To avoid this deadlock, the run loop name is required when using the NSObject method performSelectorOnMainThread:withObject:waitUntilDone:modes: <https://developer.apple.com/documentation/objectivec/nsobject/1411637-performselectoronmainthread>
> 
> JNF calls this method with the ?old? run loop name.

My use was without modes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210628/7d46880c/attachment-0001.htm>

From serb at openjdk.java.net  Mon Jun 28 22:48:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Jun 2021 22:48:05 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v2]
In-Reply-To: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
Message-ID: <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>

On Wed, 23 Jun 2021 12:15:03 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov 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:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m line 349:

> 347:         if ([window.contentView.layer isKindOfClass:[CAMetalLayer class]]) {
> 348:             [window.contentView.layer setOpaque:(BOOL)opaque];
> 349:         }

This class "CWrapper" is intended to be a simple wrapper on top of cocoa methods, the changed method above is expected to call the "NSWindow#setOpaque" only. So you need to place "window.contentView.layer setOpaque" in some other place(native or java).

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From github.com+36081106+savoptik at openjdk.java.net  Tue Jun 29 13:29:02 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 29 Jun 2021 13:29:02 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
Message-ID: <pjTvFQhmI0GQl3bMAiHlDQkCh_7XDKglBZLMDBWRIu0=.58fa917e-63ad-45bd-8642-2fad8d0da503@github.com>

On Wed, 16 Jun 2021 20:48:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> test/jdk/java/awt/a11y/AccessibleJComboboxTest.java line 30:
> 
>> 28:  * @summary Create implementation for NSAccessibilityComboBox protocol peer
>> 29:  * @author Artem.Semenov at jetbrains.com
>> 30:  * @run main/manual AccessibleJComboboxTest
> 
> On what platforms these tests are supposed to work?

These tests can be applied wherever a11y support is implemented and running.

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From serb at openjdk.java.net  Tue Jun 29 14:37:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Jun 2021 14:37:06 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <pjTvFQhmI0GQl3bMAiHlDQkCh_7XDKglBZLMDBWRIu0=.58fa917e-63ad-45bd-8642-2fad8d0da503@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
 <pjTvFQhmI0GQl3bMAiHlDQkCh_7XDKglBZLMDBWRIu0=.58fa917e-63ad-45bd-8642-2fad8d0da503@github.com>
Message-ID: <9evnrK4Ur3dBuLtlkClLLvK_1rXAFycE-wjM1tmRnwU=.4bc677a3-ff73-44e2-93d5-da934c3bd000@github.com>

On Tue, 29 Jun 2021 13:26:29 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> test/jdk/java/awt/a11y/AccessibleJComboboxTest.java line 30:
>> 
>>> 28:  * @summary Create implementation for NSAccessibilityComboBox protocol peer
>>> 29:  * @author Artem.Semenov at jetbrains.com
>>> 30:  * @run main/manual AccessibleJComboboxTest
>> 
>> On what platforms these tests are supposed to work?
>
> These tests can be applied wherever a11y support is implemented and running.

Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be reported as a bug. So if on some supported platforms these tests will fail it is better to update the "tags" or the problemlist before integration. Otherwise, people will report new bugs after.

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From github.com+36081106+savoptik at openjdk.java.net  Tue Jun 29 15:04:07 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 29 Jun 2021 15:04:07 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <4CZCGYIDcZlVhckVi87sZpwUATr3w9yT_7o5eBD1s5U=.1b564e7b-7861-486a-a53e-7ff04084e994@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <4CZCGYIDcZlVhckVi87sZpwUATr3w9yT_7o5eBD1s5U=.1b564e7b-7861-486a-a53e-7ff04084e994@github.com>
Message-ID: <DFe4h-ztl4BnHaItVfvImpBeDItCLgKDl5OMYNJSlYM=.86889536-35ad-41e3-94a5-0c9ec7578336@github.com>

On Wed, 16 Jun 2021 17:49:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 372:
> 
>> 370:     if ([javaRole isEqualToString:@"pagetablist"]) {
>> 371:         newChild = [TabGroupLegacyAccessibility alloc];
>> 372:     } else if ([javaRole isEqualToString:@"table"]) {
> 
> Do we even need legacy peer implementation in the new classes?

The new TabGroup is also named TabGroupAccessibility, so as not to get out of the naming, the old class is renamed for this, otherwise the building will fail.

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

PR: https://git.openjdk.java.net/jdk/pull/4412

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:50:52 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:50:52 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v8]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <F5VdMXD1NkeXdtXQdY-UO7shOqTcf1ewN6Z1cODgHSg=.ab11f8a5-c205-4eea-afaa-d86fe88acf9e@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? 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 eight additional commits since the last revision:

 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/f1c8cc7b..4ec7c829

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06-07

  Stats: 56052 lines in 1127 files changed: 32406 ins; 19375 del; 4271 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From vdyakov at openjdk.java.net  Wed Jun 30 16:51:04 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 30 Jun 2021 16:51:04 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <IlzmYq5-hqvbfWONmSN1BodQhoBQemnYOnvj2EICIDk=.35fff82e-92d9-4e92-8a54-c7e8c3b94cc3@github.com>

On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
> This pull request contains solutions for the following tickets:
> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.

@pbansal please review

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

PR: https://git.openjdk.java.net/jdk/pull/4412