From asemenov at openjdk.org  Sat Apr  1 10:23:17 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sat, 1 Apr 2023 10:23:17 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
In-Reply-To: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
References: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
Message-ID: <SZk2MOoghS78X4UxXENxC4v8ZH8s74vrSF4m8Hu_iYU=.0c84742a-02a7-43d5-900f-e36f77ae87b7@github.com>

On Fri, 31 Mar 2023 11:54:40 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
> 
> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
> 
> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
> 
> So, added a fix similar to slider demo for combobox in tabledemo.

Looks good to me.

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

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13268#pullrequestreview-1367841090


From jwaters at openjdk.org  Sat Apr  1 14:37:20 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 1 Apr 2023 14:37:20 GMT
Subject: RFR: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
 [v2]
In-Reply-To: <kpYDdWQq-Xgu5HiMGpNlQXiJ8V4VTeVLUSYZsgIXlvM=.a683a262-eecd-4df9-9540-2b8cb6150ec1@github.com>
References: <hLO1XpFm8t4rxoWxbSDKCRgOB0RYoiIXLclspkO6Bic=.72af2cbc-ba70-4806-b7b5-f3fea67eee26@github.com>
 <kpYDdWQq-Xgu5HiMGpNlQXiJ8V4VTeVLUSYZsgIXlvM=.a683a262-eecd-4df9-9540-2b8cb6150ec1@github.com>
Message-ID: <sza_kuP_JbFku5Utsia5k5uDyT7_RI7IDaZqkV2ik9U=.e571a1fd-b1e6-4c63-93a8-24e0d926ba15@github.com>

On Fri, 31 Mar 2023 21:27:08 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> Builds successfully with GCC 7
>> 
>> 
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment clarifying noexcept-type is only required for GCC 7

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13253#pullrequestreview-1367869349


From duke at openjdk.org  Sat Apr  1 14:40:31 2023
From: duke at openjdk.org (Joshua Cao)
Date: Sat, 1 Apr 2023 14:40:31 GMT
Subject: Integrated: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
In-Reply-To: <hLO1XpFm8t4rxoWxbSDKCRgOB0RYoiIXLclspkO6Bic=.72af2cbc-ba70-4806-b7b5-f3fea67eee26@github.com>
References: <hLO1XpFm8t4rxoWxbSDKCRgOB0RYoiIXLclspkO6Bic=.72af2cbc-ba70-4806-b7b5-f3fea67eee26@github.com>
Message-ID: <F1ZoHeHZGPmo6hPP09Fa_c5P_l9oLxYX6DaoPYN7VHg=.441690b9-ebf8-44e9-8fc9-124dbfe48ce3@github.com>

On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao <duke at openjdk.org> wrote:

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This pull request has now been integrated.

Changeset: 34e66ce1
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34e66ce1ef2decc81557a362d6242313e98417fa
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8304295: harfbuzz build fails with GCC 7 after JDK-8301998

Reviewed-by: shade, erikj, serb, jwaters

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

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


From duke at openjdk.org  Sun Apr  2 07:21:17 2023
From: duke at openjdk.org (M4ximumPizza)
Date: Sun, 2 Apr 2023 07:21:17 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name [v2]
In-Reply-To: <ktL9Nf3AxmeLOf7czbYjWtivm771gAjaQtk8oJh_hzU=.49aa024a-c446-434b-8d5f-1fde5ec4665b@github.com>
References: <IDIEllqEEcqa1Uc_L0lNjND-waxLbtvsBG1YyXyrONU=.ad59c557-25b9-4ed4-8aa6-4eac06007601@github.com>
 <ktL9Nf3AxmeLOf7czbYjWtivm771gAjaQtk8oJh_hzU=.49aa024a-c446-434b-8d5f-1fde5ec4665b@github.com>
Message-ID: <EzT6MPm1lnhAt790YzxxnYRCK1Yqa9E3YubmlQ22rbc=.77d634cb-67a0-4036-b4ec-01f79f2c3b2f@github.com>

On Fri, 31 Mar 2023 17:08:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
>> 
>> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
>> 
>> The solution works correctly for screen magnifier as well as voice over. 
>> 
>> A manual test case is added to verify the fix.
>> 
>> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test instruction update

Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13271#pullrequestreview-1368033163


From duke at openjdk.org  Sun Apr  2 10:45:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 2 Apr 2023 10:45:16 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
Message-ID: <WyLHsfjE2Wr-lnXhYsY5JuCZkn5GVxHTxS3vZLSeCiE=.a249a5a8-8c57-4d7d-9b0a-af372c19824c@github.com>

On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. 
> 
> The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging:
> 
> 
> <jvmarg value="-Xdebug"/>
> <jvmarg value="-Xnoagent"/>
> <jvmarg value="-Djava.compiler=none"/>
> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
> 
> 
> They should instead just do:
> 
> 
> <jvmarg value="-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=${jpda.address}"/>
> 
> 
> Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout.
> 
> `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/`

This PR is a blocking the removal of the `java.compiler` system property.

It would be great to get a review for this low-risk change :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1493295202


From abhiscxk at openjdk.org  Mon Apr  3 05:39:34 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Apr 2023 05:39:34 GMT
Subject: Integrated: 8283404: [macos] a11y : Screen magnifier does not show
 JMenu name
In-Reply-To: <IDIEllqEEcqa1Uc_L0lNjND-waxLbtvsBG1YyXyrONU=.ad59c557-25b9-4ed4-8aa6-4eac06007601@github.com>
References: <IDIEllqEEcqa1Uc_L0lNjND-waxLbtvsBG1YyXyrONU=.ad59c557-25b9-4ed4-8aa6-4eac06007601@github.com>
Message-ID: <uI_DAiIeQ4DhtSgr3WKFe7gZPKGrS4KBudQmpS1cs9M=.6959066c-8dec-4043-95ad-9d5efa66a7fd@github.com>

On Fri, 31 Mar 2023 15:27:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
> 
> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
> 
> The solution works correctly for screen magnifier as well as voice over. 
> 
> A manual test case is added to verify the fix.
> 
> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.

This pull request has now been integrated.

Changeset: ecec611a
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecec611af6c6314d7a834392f38468ad3f390e2d
Stats:     112 lines in 2 files changed: 109 ins; 0 del; 3 mod

8283404: [macos] a11y : Screen magnifier does not show JMenu name

Reviewed-by: serb

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

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


From abhiscxk at openjdk.org  Mon Apr  3 06:57:10 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Apr 2023 06:57:10 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo. [v2]
In-Reply-To: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
References: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
Message-ID: <ESZwplcX_ie-J7x7gTqDel_SlIDM-gN4S6dsO-z6d98=.59c00f5f-5817-4b29-9b66-5282530c0faa@github.com>

> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
> 
> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
> 
> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
> 
> So, added a fix similar to slider demo for combobox in tabledemo.

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

  Copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13268/files
  - new: https://git.openjdk.org/jdk/pull/13268/files/70aca9e0..5d254ef7

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

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

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


From abhiscxk at openjdk.org  Mon Apr  3 06:57:13 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Apr 2023 06:57:13 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
In-Reply-To: <6qLFJWs35roSQMpztdOeM8Rsg01g6toVYHDyGMKoHEA=.531db65a-9389-4185-a6c7-4c33d9584000@github.com>
References: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
 <6qLFJWs35roSQMpztdOeM8Rsg01g6toVYHDyGMKoHEA=.531db65a-9389-4185-a6c7-4c33d9584000@github.com>
Message-ID: <v265Rc_lO5dM6ocNc_ET2vtA5IPSBB0pjdQsUPcmVO0=.1a4bcaa5-fb01-49f7-b2de-8ff8a63f1bfd@github.com>

On Fri, 31 Mar 2023 22:01:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, please update the dates in the copyright block.

Copyright year updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/13268#issuecomment-1493774418


From tr at openjdk.org  Mon Apr  3 07:20:24 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Apr 2023 07:20:24 GMT
Subject: RFR: 8257455: javax/swing/Security/6378709/TimerHack.java and
 javax/swing/JFileChooser/4163841/AcceptAllFileFilterTest.java fails in CI
In-Reply-To: <Au03ElOWtjsewnxL5PozbxPdiU0TtPwWNWWDgTjs8uE=.e6db2373-c2c2-4416-8447-7df6aa1677af@github.com>
References: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
 <UzkXiXy9V1H3wm-pl1mgSzr2i0-iGamObdqvMXOex0g=.63cdef01-f8d1-4388-be7c-0dc5613a38fa@github.com>
 <kS3i648Rw2hj2j58NIz3jXhMEE77Nh4-2eQazCOuH2k=.9993ded7-a45b-4f94-986e-a169035f96c2@github.com>
 <Au03ElOWtjsewnxL5PozbxPdiU0TtPwWNWWDgTjs8uE=.e6db2373-c2c2-4416-8447-7df6aa1677af@github.com>
Message-ID: <QHa_Y_gSCsk7HPZy5kRMkZxO6lDy5svfDkoYLESEeLQ=.6cde7d46-1863-4820-800f-280832672598@github.com>

On Mon, 20 Mar 2023 19:13:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb U had mentioned about reproducing the bug 5 out of 2000 times in jbs, any chance u remember where did u run? On physical/OCI Oracle linux CI system or any other?
>
> The JBS issue is closed. "?? Failed to retrieve information on issue 8257455"

@mrserb I ran sample test program on CI machine of OCI OL as suggested by @prsadhuk yet unable to reproduce the issue. As I was mentioning that u had mentioned about the bug reproduction in JBS (which is closed), this is your observations which u had mentioned - 

> I have run the headless tests in 8u and these two tests fail for the same reason 5 times for 2000 test runs:
> 
> closed/javax/swing/Security/6378709/TimerHack.java
> closed/javax/swing/JFileChooser/4163841/AcceptAllFileFilterTest.java
> 
> STATUS:java.util.ConcurrentModificationException
> at java.util.SubList.checkForComodification(AbstractList.java:769)
> at java.util.SubList.listIterator(AbstractList.java:695)
> at java.util.AbstractList.listIterator(AbstractList.java:299)
> at java.util.Collections$SynchronizedList.listIterator(Collections.java:2443)
> at java.util.AbstractList.equals(AbstractList.java:519)
> at java.util.Collections$SynchronizedList.equals(Collections.java:2412)
> at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(BasicDirectoryModel.java:310)
> at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(BasicDirectoryModel.java:288)
> at sun.awt.shell.ShellFolderManager$DirectInvoker.invoke(ShellFolderManager.java:113)
> at sun.awt.shell.ShellFolder.invoke(ShellFolder.java:518)
> at sun.awt.shell.ShellFolder.invoke(ShellFolder.java:504)
> at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run0(BasicDirectoryModel.java:288)
> at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run(BasicDirectoryModel.java:241)`.

By any chance will u be able to recollect how u were able to reproduce it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13012#discussion_r1155566837


From dcherepanov at openjdk.org  Mon Apr  3 10:03:22 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 3 Apr 2023 10:03:22 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
Message-ID: <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>

On Fri, 31 Mar 2023 19:03:50 GMT, Phil Race <prr at openjdk.org> wrote:

> that's a good point. If the window is created and later iconifiied (for example) and then this notification comes in, will it be missed ?

Such notifications won't be ignored as isVisible() returns true for iconified windows
Verified the scenario:
 - window displayed (WWindowPeer.initialize() calls updateIconImages())
 - window iconified
 - changed DPI setting (WWindowPeer.updateGC() calls updateIconImages())
 - window de-iconified (with properly updated icon)

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

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1494024137


From dcherepanov at openjdk.org  Mon Apr  3 10:03:24 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 3 Apr 2023 10:03:24 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <iJ7QBSvFcb9XOx15HumNCRfSIyApTRmzNgsMBpY2vZE=.8ccd901a-98f1-401a-a3fd-d4d5f78a2655@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>
 <iJ7QBSvFcb9XOx15HumNCRfSIyApTRmzNgsMBpY2vZE=.8ccd901a-98f1-401a-a3fd-d4d5f78a2655@github.com>
Message-ID: <vYZzOSWrNWeDlLMGzeV27rtNX83VuC9noCZ-ONFKOQQ=.3c4db8ad-d05a-4e83-a2be-c0bd4e046fab@github.com>

On Fri, 31 Mar 2023 19:00:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 605:
>> 
>>> 603:         if (((Window)target).isVisible()) {
>>> 604:             updateIconImages();
>>> 605:         }
>> 
>> Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?
>> 
>> Are you sure that it is not possible to trigger the next "trace" in the application w/o using "updateIconImages"?
>> 
>> 	at sun.java2d.loops.GraphicsPrimitiveMgr.initIDs(java.desktop at 21-ea/Native Method)
>> 	- waiting on the Class initialization monitor for sun.java2d.loops.Blit
>> 	at sun.java2d.loops.GraphicsPrimitiveMgr.<clinit>(java.desktop at 21-ea/GraphicsPrimitiveMgr.java:56)
>> 	at sun.java2d.loops.DrawLine.locate(java.desktop at 21-ea/DrawLine.java:51)
>> 	at sun.java2d.SurfaceData.makeRenderLoops(java.desktop at 21-ea/SurfaceData.java:884)
>> 	at sun.awt.image.BufImgSurfaceData.getSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:412)
>> 	- locked <0x00000000c3fdd920> (a java.lang.Class for sun.awt.image.BufImgSurfaceData)
>> 	at sun.awt.image.BufImgSurfaceData.initSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:397)
>> 	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:256)
>> 	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:74)
>> 	at sun.awt.image.BufImgSurfaceManager.<init>(java.desktop at 21-ea/BufImgSurfaceManager.java:55)
>> 	at sun.awt.image.SurfaceManager.getManager(java.desktop at 21-ea/SurfaceManager.java:79)
>> 	at sun.java2d.SurfaceData.getPrimarySurfaceData(java.desktop at 21-ea/SurfaceData.java:275)
>> 	at sun.java2d.SunGraphicsEnvironment.createGraphics(java.desktop at 21-ea/SunGraphicsEnvironment.java:132)
>> 	at java.awt.image.BufferedImage.createGraphics(java.desktop at 21-ea/BufferedImage.java:1183)
>> 	at sun.awt.SunToolkit.getScaledIconImage(java.desktop at 21-ea/SunToolkit.java:1032)
>> 	at sun.awt.SunToolkit.getScaledIconData(java.desktop at 21-ea/SunToolkit.java:1046)
>> 	at sun.awt.windows.WWindowPeer.updateIconImages(java.desktop at 21-ea/WWindowPeer.java:468)
>> 	at sun.awt.windows.WWindowPeer.updateGC(java.desktop at 21-ea/WWindowPeer.java:603)
>
> It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization

> Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?

updateIconImages() will still be called from WWindowPeer.initialize() when we show a new window

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13263#discussion_r1155745077


From dcherepanov at openjdk.org  Mon Apr  3 10:03:25 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 3 Apr 2023 10:03:25 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <vYZzOSWrNWeDlLMGzeV27rtNX83VuC9noCZ-ONFKOQQ=.3c4db8ad-d05a-4e83-a2be-c0bd4e046fab@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>
 <iJ7QBSvFcb9XOx15HumNCRfSIyApTRmzNgsMBpY2vZE=.8ccd901a-98f1-401a-a3fd-d4d5f78a2655@github.com>
 <vYZzOSWrNWeDlLMGzeV27rtNX83VuC9noCZ-ONFKOQQ=.3c4db8ad-d05a-4e83-a2be-c0bd4e046fab@github.com>
Message-ID: <JGxlvQZfWYpKFBgpBrKrF22_hpPU2qulISSjQ8K0Z3U=.730ba60f-617b-42f8-bd8c-c8bc9cce4d3b@github.com>

On Mon, 3 Apr 2023 09:58:18 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization
>
>> Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?
> 
> updateIconImages() will still be called from WWindowPeer.initialize() when we show a new window

> It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization

Right, the deadlock might be possible in other scenarios. But it manifests itself more frequently after JDK-8276849 and the change fixes the regression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13263#discussion_r1155747797


From duke at openjdk.org  Mon Apr  3 10:21:58 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 3 Apr 2023 10:21:58 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window
Message-ID: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>

This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.

Testing:
Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

Commit messages:
 - 8305427: Whitespace removed
 - 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window

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

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


From aghaisas at openjdk.org  Mon Apr  3 12:20:57 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 3 Apr 2023 12:20:57 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
Message-ID: <hzOMx5ufbIbRaBYTnkgO6ujTufGVu3zEXO_691n0_A8=.5f24083c-d2ee-4548-909d-697f08d0ae30@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

I modified the patch to add back `blitCommandQueue` and tested. Below is the comparison between performance results for a build without this PR & a build with (this PR + adding back `blitCommandQueue`)

- on x64 based systems : Swingmark performance is back to normal, but, one of the J2DBenchmark test shows 20% degradation.
- on aarch64 based systems : Swingmark performance still indicates  -15%  (It was -20% without adding back the `blitCommandQueue`


This testing indicates that there is an additional performance hit due to the change in logic apart from `blitCommandQueue` removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1494220410


From aghaisas at openjdk.org  Mon Apr  3 12:27:56 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 3 Apr 2023 12:27:56 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
Message-ID: <f79v6oiWGuIiXC3KCxAJEDH6h1jGv6WdNfMB4Ubfigs=.ab2b100a-d4df-40e3-8946-94b71237549d@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

I suggest we fix this bug on by either of the two options below-
- Option 1 : Recreating the CVDisplaylink on screen sleep/wake events
- Option 2 : As noted by you as a JBS comment - `Actually, the simple hack to resolve this particular issue is to replace this call with CVDisplayLinkCreateWithCGDisplay(CGMainDisplayID(), &displayLink)`

I have implemented and tested Option 1. I have not tried Option 2 yet.


The code refactoring that you have done can be done as a separate JBS issue if needed in future. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1494229820


From rriggs at openjdk.org  Tue Apr  4 00:23:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 00:23:07 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v2]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

Roger Riggs 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 8304912-use-os-desktop
 - Use OperatingSystem.isAix
 - Remove unused os.arch system property
 - Apply OperatingSystem enum instead of os.name to java.desktop module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/b8cd2240..7f93ecbf

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

  Stats: 21757 lines in 527 files changed: 9811 ins; 9926 del; 2020 mod
  Patch: https://git.openjdk.org/jdk/pull/13213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13213/head:pull/13213

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


From tr at openjdk.org  Tue Apr  4 07:44:07 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Apr 2023 07:44:07 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon
In-Reply-To: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
Message-ID: <Z2Rw7Gy6XxP5SxNbzQQUpe0Ofl2orZfeWSWvjVBra44=.11228327-1a85-4064-a44c-d02d0c31d319@github.com>

On Thu, 23 Mar 2023 06:17:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
> 
> This is what can be seen in windows system setting
> 
> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
> 
> and notepad
> 
> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
> 
> We have currently
> 
> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
> 
> 
> and after fix
> 
> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)

Fix is working as expected. Looks Good to me.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13153#pullrequestreview-1370385129


From abhiscxk at openjdk.org  Tue Apr  4 07:48:11 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Apr 2023 07:48:11 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header
In-Reply-To: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
Message-ID: <mC03EtAIflsH7y7duytfA0fGJnY5gsEJQ2FyHf4VThQ=.7b965269-983d-4c00-942c-ffcb235c0f7b@github.com>

On Fri, 24 Mar 2023 10:34:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
> 
> So, inline with check done for `viewIndexForColumn `
> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
> a similar check is added when `viewIndexForColumn `is called

Please split the long line and update the copyright year.

test/jdk/javax/swing/JTableHeader/JTableHeaderExceptionTest.java line 37:

> 35: import java.awt.event.ActionEvent;
> 36: import java.awt.event.InputEvent;
> 37: import javax.swing.*;

Wild import can be removed.

test/jdk/javax/swing/JTableHeader/JTableHeaderExceptionTest.java line 91:

> 89: 
> 90:     Point loc;
> 91:     public DragTestTable(DragTestTableModel model){

Please add a space here `public DragTestTable(DragTestTableModel model) {`

test/jdk/javax/swing/JTableHeader/JTableHeaderExceptionTest.java line 99:

> 97:             @Override
> 98:             public void actionPerformed(ActionEvent e) {
> 99:                 //loc = menu.getLocationOnScreen();

Commented line can be removed.

test/jdk/javax/swing/JTableHeader/JTableHeaderExceptionTest.java line 113:

> 111:         private Object columnNames[];
> 112: 
> 113:         public DragTestTableModel(Object rowData[][], Object columnNames[]){

Please add a space here `public DragTestTableModel(Object rowData[][], Object columnNames[]) {`

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

PR Comment: https://git.openjdk.org/jdk/pull/13172#issuecomment-1495502429
PR Review Comment: https://git.openjdk.org/jdk/pull/13172#discussion_r1156819246
PR Review Comment: https://git.openjdk.org/jdk/pull/13172#discussion_r1156820545
PR Review Comment: https://git.openjdk.org/jdk/pull/13172#discussion_r1156821312
PR Review Comment: https://git.openjdk.org/jdk/pull/13172#discussion_r1156823739


From dcherepanov at openjdk.org  Tue Apr  4 07:48:08 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 4 Apr 2023 07:48:08 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <JGxlvQZfWYpKFBgpBrKrF22_hpPU2qulISSjQ8K0Z3U=.730ba60f-617b-42f8-bd8c-c8bc9cce4d3b@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>
 <iJ7QBSvFcb9XOx15HumNCRfSIyApTRmzNgsMBpY2vZE=.8ccd901a-98f1-401a-a3fd-d4d5f78a2655@github.com>
 <vYZzOSWrNWeDlLMGzeV27rtNX83VuC9noCZ-ONFKOQQ=.3c4db8ad-d05a-4e83-a2be-c0bd4e046fab@github.com>
 <JGxlvQZfWYpKFBgpBrKrF22_hpPU2qulISSjQ8K0Z3U=.730ba60f-617b-42f8-bd8c-c8bc9cce4d3b@github.com>
Message-ID: <oxNdSYVfRa6D00WTV3TpQEqZ8-0GpPdtDJbJczdkx0g=.d6935c95-c233-4862-b7a9-d66b301f28fc@github.com>

On Mon, 3 Apr 2023 10:00:45 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>>> Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?
>> 
>> updateIconImages() will still be called from WWindowPeer.initialize() when we show a new window
>
>> It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization
> 
> Right, the deadlock might be possible in other scenarios. But it manifests itself more frequently after JDK-8276849 and the change fixes the regression.

> updateIconImages() will still be called from WWindowPeer.initialize() when we show a new window

It's worth mentioning that WindowPeer.initialize() is called on the same thread as setVisible() (i.e. the main thread for the scenario reported in the bug) and so the call to updateIconImages() seems safe

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13263#discussion_r1156859385


From psadhukhan at openjdk.org  Tue Apr  4 08:04:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Apr 2023 08:04:14 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header [v2]
In-Reply-To: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
Message-ID: <ZfuvUOjDZHWoZViln0Zdh3d-tQYxKTDrc1rtlPlDi-8=.1bbc9d7c-ec9b-4368-9e3a-22a13e123338@github.com>

> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
> 
> So, inline with check done for `viewIndexForColumn `
> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
> a similar check is added when `viewIndexForColumn `is called

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

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13172/files
  - new: https://git.openjdk.org/jdk/pull/13172/files/2fff1178..a8d1338a

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

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

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


From duke at openjdk.org  Tue Apr  4 09:38:07 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Tue, 4 Apr 2023 09:38:07 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window
In-Reply-To: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
Message-ID: <oT35X0Wwq4I9kTXgJ9CkwtaZs4oFnH3XYErqmkiJHx0=.49eac31e-ac9d-40c1-9515-9a1a05834227@github.com>

On Mon, 3 Apr 2023 10:00:21 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

Any volunteers for a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/13293#issuecomment-1495653932


From psadhukhan at openjdk.org  Tue Apr  4 10:02:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Apr 2023 10:02:21 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header [v3]
In-Reply-To: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
Message-ID: <W7KR5IMB7Zgcf2h-lacKntaMBVvzGo7iRb4K-s0BUrU=.c8215f66-fd54-4a35-a825-a12b3cfb37d2@github.com>

> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
> 
> So, inline with check done for `viewIndexForColumn `
> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
> a similar check is added when `viewIndexForColumn `is called

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13172/files
  - new: https://git.openjdk.org/jdk/pull/13172/files/a8d1338a..130baf1a

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

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

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


From psadhukhan at openjdk.org  Tue Apr  4 10:09:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Apr 2023 10:09:14 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header [v4]
In-Reply-To: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
Message-ID: <tplqOez0uYFnHONCnycMtl13THNbrg52S3zzZIQp5q8=.ddaf0501-c6b5-4836-8e46-e380575b2f38@github.com>

> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
> 
> So, inline with check done for `viewIndexForColumn `
> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
> a similar check is added when `viewIndexForColumn `is called

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13172/files
  - new: https://git.openjdk.org/jdk/pull/13172/files/130baf1a..0014c724

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

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

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


From abhiscxk at openjdk.org  Tue Apr  4 10:09:17 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Apr 2023 10:09:17 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header [v3]
In-Reply-To: <W7KR5IMB7Zgcf2h-lacKntaMBVvzGo7iRb4K-s0BUrU=.c8215f66-fd54-4a35-a825-a12b3cfb37d2@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
 <W7KR5IMB7Zgcf2h-lacKntaMBVvzGo7iRb4K-s0BUrU=.c8215f66-fd54-4a35-a825-a12b3cfb37d2@github.com>
Message-ID: <4sbM5ihDDXpjQZYmzAGO-CsWLDXZpC3QA2pVKpKP4u8=.b05cc2e5-b74c-492d-a8c3-2596d54f82f8@github.com>

On Tue, 4 Apr 2023 10:02:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
>> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
>> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
>> 
>> So, inline with check done for `viewIndexForColumn `
>> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
>> a similar check is added when `viewIndexForColumn `is called
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Test verified. Looks good to me.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13172#pullrequestreview-1370629853


From avu at openjdk.org  Tue Apr  4 10:12:17 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 4 Apr 2023 10:12:17 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
Message-ID: <XHWc-Vpo_azrH5SsjSyEqYfYyY7VO-OOsPQvEkjKx8E=.175425dc-90f5-4f7c-81c8-ae771af79905@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

OK, let's try Option 1. It still may be useful to recreate CVDisplaylink on the fly, for example if macOS switch GPU from internal to discrete one. I suppose my changes could be adjusted with this approach and pushed as a separate PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1495699417


From avu at openjdk.org  Tue Apr  4 10:12:18 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 4 Apr 2023 10:12:18 GMT
Subject: Withdrawn: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
Message-ID: <a8LuDuq0TKxAX7cpWZdJBckDm1R8rbDsEAodpoh8Bj8=.f47d5413-c589-432d-9611-e26a322b2140@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

This pull request has been closed without being integrated.

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

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


From dmarkov at openjdk.org  Tue Apr  4 15:54:03 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 4 Apr 2023 15:54:03 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
Message-ID: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>

Port the fix from the upstream/HarfBuzz repo.

More info can be obtained here:
https://github.com/harfbuzz/harfbuzz/discussions/4188 
https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

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

Commit messages:
 - 8305527: HarfBuzz: Remove trailing comma from the enum in hb-paint.h

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

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


From honkar at openjdk.org  Tue Apr  4 16:04:42 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Apr 2023 16:04:42 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
Message-ID: <YJnDsllR2XbsDWmoOYP_GAHqaJk4MVZQf3x1hdkEVzk=.a824f7db-4839-413f-8ff9-b2f812f643af@github.com>

On Tue, 4 Apr 2023 15:46:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Port the fix from the upstream/HarfBuzz repo.
> 
> More info can be obtained here:
> https://github.com/harfbuzz/harfbuzz/discussions/4188 
> https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

Marked as reviewed by honkar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13328#pullrequestreview-1371316148


From bpb at openjdk.org  Tue Apr  4 17:08:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Apr 2023 17:08:14 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v2]
In-Reply-To: <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
Message-ID: <3YQtyJ5J0aqrmqH7alJvZiMQy-on0NPjr5fKf8PEFUI=.3c63a4a2-bed8-431e-b5c4-55e4eb9b8945@github.com>

On Tue, 4 Apr 2023 00:23:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs 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 8304912-use-os-desktop
>  - Use OperatingSystem.isAix
>  - Remove unused os.arch system property
>  - Apply OperatingSystem enum instead of os.name to java.desktop module

Looks fine modulo any cleanup to be performed subsequently.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13213#pullrequestreview-1371420348


From serb at openjdk.org  Tue Apr  4 17:36:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 17:36:10 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
Message-ID: <T6SgvI-WVZY-1XK_lAyaJ7CLEbtWl098i6BONSaCQb0=.32370d5b-2c52-46c7-be4c-6b08a07c4b1b@github.com>

On Tue, 4 Apr 2023 15:46:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Port the fix from the upstream/HarfBuzz repo.
> 
> More info can be obtained here:
> https://github.com/harfbuzz/harfbuzz/discussions/4188 
> https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13328#pullrequestreview-1371467485


From prr at openjdk.org  Tue Apr  4 17:44:07 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Apr 2023 17:44:07 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
Message-ID: <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>

On Tue, 4 Apr 2023 15:46:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Port the fix from the upstream/HarfBuzz repo.
> 
> More info can be obtained here:
> https://github.com/harfbuzz/harfbuzz/discussions/4188 
> https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

I don't see why we need this in mainline. I'd prefer to not have it unless we need it.

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13328#pullrequestreview-1371479862


From rriggs at openjdk.org  Tue Apr  4 19:40:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:40:05 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v2]
In-Reply-To: <3YQtyJ5J0aqrmqH7alJvZiMQy-on0NPjr5fKf8PEFUI=.3c63a4a2-bed8-431e-b5c4-55e4eb9b8945@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
 <3YQtyJ5J0aqrmqH7alJvZiMQy-on0NPjr5fKf8PEFUI=.3c63a4a2-bed8-431e-b5c4-55e4eb9b8945@github.com>
Message-ID: <x5ZQlyJNYuO8Y72XCD5kju-RDG2c1jDbz9kpdYk4I9E=.df01593c-0988-4100-8777-03dab78b12f1@github.com>

On Tue, 4 Apr 2023 17:04:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Looks fine modulo any cleanup to be performed subsequently.

Tracked with [JDK-8305606](https://bugs.openjdk.org/browse/JDK-8305606)

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

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1496496309


From aturbanov at openjdk.org  Tue Apr  4 21:49:07 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 21:49:07 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v2]
In-Reply-To: <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
Message-ID: <HkKMM7eSFWnFJklBM5SdoBgxjX3JvoCwujB2nyztH9M=.3dc1ebfc-1c22-4594-8b4e-238c699c94e4@github.com>

On Tue, 4 Apr 2023 00:23:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs 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 8304912-use-os-desktop
>  - Use OperatingSystem.isAix
>  - Remove unused os.arch system property
>  - Apply OperatingSystem enum instead of os.name to java.desktop module

src/java.desktop/share/classes/sun/font/FontUtilities.java line 71:

> 69:                 isLinux = OperatingSystem.isLinux();
> 70: 
> 71:                 isMacOSX = OperatingSystem.isMacOS(); // TODO: MacOSX

I think this `TODO` is not actual anymore

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1157800085


From serb at openjdk.org  Tue Apr  4 22:00:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 22:00:06 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
 <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
Message-ID: <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>

On Tue, 4 Apr 2023 17:41:47 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't see why we need this in mainline. I'd prefer to not have it unless we need it.

One reason is that It will be easy to backport to the old versions where the old compilers are used.

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1496652980


From aturbanov at openjdk.org  Tue Apr  4 22:00:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 22:00:09 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v2]
In-Reply-To: <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <sDmXsI9R5Db2xUkvkOfPqFDGlVHjoLSovyCP21XzcQ0=.349b8d56-6694-4185-8db5-e4d7fab58f6c@github.com>
Message-ID: <HWnp5oCDg8NEE1olhQfR4CpC7GVLjeaaMHOEMZ3zA8s=.ef002f73-3f84-4eeb-a758-5768af501f54@github.com>

On Tue, 4 Apr 2023 00:23:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs 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 8304912-use-os-desktop
>  - Use OperatingSystem.isAix
>  - Remove unused os.arch system property
>  - Apply OperatingSystem enum instead of os.name to java.desktop module

Found another couple of places:

https://github.com/openjdk/jdk/blob/7cf24d1c06142a3bab9cce5cd0ba34b8bbccf00f/src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java#L641
https://github.com/openjdk/jdk/blob/7cf24d1c06142a3bab9cce5cd0ba34b8bbccf00f/src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java#L78

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

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1496652582


From serb at openjdk.org  Tue Apr  4 22:53:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 22:53:09 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
References: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
Message-ID: <BTxbrVq9V5eKaFVuMjoDMEq5Pf31OFPTa0sURNVzAuY=.fe81f879-aeb4-4c1a-9bc0-c82422c8d986@github.com>

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

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

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13149#pullrequestreview-1371891285


From serb at openjdk.org  Tue Apr  4 23:12:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 23:12:07 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo. [v2]
In-Reply-To: <ESZwplcX_ie-J7x7gTqDel_SlIDM-gN4S6dsO-z6d98=.59c00f5f-5817-4b29-9b66-5282530c0faa@github.com>
References: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
 <ESZwplcX_ie-J7x7gTqDel_SlIDM-gN4S6dsO-z6d98=.59c00f5f-5817-4b29-9b66-5282530c0faa@github.com>
Message-ID: <u17CFataFppJWqLhwZQkjvpaaQQAg3qtomjWeijfk7w=.352f8611-aab1-4519-8e64-5c7940a48c80@github.com>

On Mon, 3 Apr 2023 06:57:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
>> 
>> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
>> 
>> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
>> 
>> So, added a fix similar to slider demo for combobox in tabledemo.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13268#pullrequestreview-1371910248


From serb at openjdk.org  Tue Apr  4 23:17:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 23:17:09 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows) [v2]
In-Reply-To: <Kbaq4IEesSm3OV-lwXa2zORkugq942f4lzv_vVxdWF8=.890e93ee-921f-4d48-b181-4218e49c5288@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
 <Kbaq4IEesSm3OV-lwXa2zORkugq942f4lzv_vVxdWF8=.890e93ee-921f-4d48-b181-4218e49c5288@github.com>
Message-ID: <pJmCra4p11QT61inNSBD0T0ZiC6nNZDmvuULlmQPzn4=.af1c3a5b-8f65-4743-a909-a5c4b7c20ac2@github.com>

On Wed, 15 Mar 2023 18:59:09 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301616: Drag & maximize to another monitor places window incorrectly (Windows)

Let's check how it will work.

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

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12367#pullrequestreview-1371913014


From dnguyen at openjdk.org  Tue Apr  4 23:25:05 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Apr 2023 23:25:05 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon
In-Reply-To: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
Message-ID: <BWrSpslSTMevPo6U_dbp4aO4gz533y3sfcId25DU9rk=.d629e492-af14-4aa4-a557-e69b2f0250e5@github.com>

On Thu, 23 Mar 2023 06:17:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
> 
> This is what can be seen in windows system setting
> 
> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
> 
> and notepad
> 
> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
> 
> We have currently
> 
> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
> 
> 
> and after fix
> 
> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)

Tested changes and confirmed it works as expected. I noticed the focus still shows for Metal & Motif. Should Metal be updated to reflect the same change?

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

Marked as reviewed by dnguyen (Author).

PR Review: https://git.openjdk.org/jdk/pull/13153#pullrequestreview-1371917970


From abhiscxk at openjdk.org  Wed Apr  5 04:31:14 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Apr 2023 04:31:14 GMT
Subject: Integrated: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
In-Reply-To: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
References: <UCF9JhSRMAQycYLZ1qnopKBSwK4I_Sf7gvw8b-DOcPA=.f9f049f7-4ecf-4a9e-9229-165a4aa36df2@github.com>
Message-ID: <BSet5x7zUKPxr_t9AX9ZXGfpI76VjkaFaHN9ZbT8V3o=.3cdbb642-5017-4fce-b039-7035940d01ef@github.com>

On Fri, 31 Mar 2023 11:54:40 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
> 
> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
> 
> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
> 
> So, added a fix similar to slider demo for combobox in tabledemo.

This pull request has now been integrated.

Changeset: 0ec3d2e3
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ec3d2e36364a284df9f636e34ab47da7ff786f3
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

7124527: [macosx] SwingSet2, label is not read by VoiceOver when focus is on textfield for Internalframe and Table demo.

Reviewed-by: asemenov, serb

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

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


From tr at openjdk.org  Wed Apr  5 04:48:08 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 5 Apr 2023 04:48:08 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon
In-Reply-To: <BWrSpslSTMevPo6U_dbp4aO4gz533y3sfcId25DU9rk=.d629e492-af14-4aa4-a557-e69b2f0250e5@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
 <BWrSpslSTMevPo6U_dbp4aO4gz533y3sfcId25DU9rk=.d629e492-af14-4aa4-a557-e69b2f0250e5@github.com>
Message-ID: <hlT6emauc6yxQlMbNgTUZ1yvyoWIl1peXLWU5DHXP84=.e79d6c3d-b5d4-40c5-be1d-9d2e5b028221@github.com>

On Tue, 4 Apr 2023 23:22:13 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Tested changes and confirmed it works as expected. I noticed the focus still shows for Metal & Motif. Should Metal be updated to reflect the same change?

Yeah, it's because the fix is Windows OS specific (Changes applied in Windows L&F).

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

PR Comment: https://git.openjdk.org/jdk/pull/13153#issuecomment-1496910123


From aghaisas at openjdk.org  Wed Apr  5 05:39:07 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 5 Apr 2023 05:39:07 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header [v4]
In-Reply-To: <tplqOez0uYFnHONCnycMtl13THNbrg52S3zzZIQp5q8=.ddaf0501-c6b5-4836-8e46-e380575b2f38@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
 <tplqOez0uYFnHONCnycMtl13THNbrg52S3zzZIQp5q8=.ddaf0501-c6b5-4836-8e46-e380575b2f38@github.com>
Message-ID: <icBeg37ty75c7ITQwxhlb4ZxQ7pJT3CrZ2k4tyojIfA=.e675b449-8091-4378-ae53-ae35d4836e8c@github.com>

On Tue, 4 Apr 2023 10:09:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
>> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
>> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
>> 
>> So, inline with check done for `viewIndexForColumn `
>> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
>> a similar check is added when `viewIndexForColumn `is called
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13172#pullrequestreview-1372182640


From psadhukhan at openjdk.org  Wed Apr  5 05:45:26 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Apr 2023 05:45:26 GMT
Subject: Integrated: 8068824: Exception thrown in JTableHeader after clicking
 on popupmenu opened with right-click on header
In-Reply-To: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
References: <mj7m051TPM-kaIS1uOq1uKcSDOoVvaIKnScQA3nk_3E=.5c4c4db1-920c-4a05-9555-b28c96403ab8@github.com>
Message-ID: <hP0gXjb5O_cdysd0cvxiHVQdUsBYo8Zs9DbcfN_t-KM=.4ae89e68-be47-4e3b-9b60-6d08157536bd@github.com>

On Fri, 24 Mar 2023 10:34:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
> This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
> which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)
> 
> So, inline with check done for `viewIndexForColumn `
> https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
> a similar check is added when `viewIndexForColumn `is called

This pull request has now been integrated.

Changeset: b659c353
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b659c35395fd3ac284a8fccfc04a4adf97438fb5
Stats:     171 lines in 3 files changed: 158 ins; 0 del; 13 mod

8068824: Exception thrown in JTableHeader after clicking on popupmenu opened with right-click on header

Reviewed-by: abhiscxk, aghaisas

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

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


From mkartashev at openjdk.org  Wed Apr  5 08:28:08 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 5 Apr 2023 08:28:08 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
Message-ID: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>

Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.

On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.

A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

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

Commit messages:
 - 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions

Changes: https://git.openjdk.org/jdk/pull/13346/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305578
  Stats: 48 lines in 3 files changed: 42 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13346/head:pull/13346

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


From serb at openjdk.org  Wed Apr  5 09:09:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 5 Apr 2023 09:09:14 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <ityXcTPFx_sk-zvzhc2YirLu6pYiFG52e6OfrzYo3MY=.f145f196-2d48-40bc-b7b8-a702d7cbf90e@github.com>

On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

What exact operation is slow?

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1497161488


From dmarkov at openjdk.org  Wed Apr  5 09:11:15 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 5 Apr 2023 09:11:15 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
 <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
 <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>
Message-ID: <Ja6sWzpR8Jh25NfDzzc5vlXOzUMGFVoPNXcTbUllxDg=.f1590064-eff0-4f85-ace8-a31c109f2292@github.com>

On Tue, 4 Apr 2023 21:56:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I don't see why we need this in mainline. I'd prefer to not have it unless we need it.

I believe it is better to have all JDK branches in sync if it's possible. 
This change is harmless and as Sergey mentioned it would simplify backport process.

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1497164814


From mkartashev at openjdk.org  Wed Apr  5 09:24:14 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 5 Apr 2023 09:24:14 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <ityXcTPFx_sk-zvzhc2YirLu6pYiFG52e6OfrzYo3MY=.f145f196-2d48-40bc-b7b8-a702d7cbf90e@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <ityXcTPFx_sk-zvzhc2YirLu6pYiFG52e6OfrzYo3MY=.f145f196-2d48-40bc-b7b8-a702d7cbf90e@github.com>
Message-ID: <xd3PckA6E3d04Ew1THTj0ZlM6cCwOhLiIdVdvAkKHto=.b8537c37-2fe8-4c14-addc-b0a31468106b@github.com>

On Wed, 5 Apr 2023 09:06:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What exact operation is slow?

`X11GraphicsDevice.pGetBounds()`; I didn't measure further down.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1497180738


From duke at openjdk.org  Wed Apr  5 11:47:06 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Wed, 5 Apr 2023 11:47:06 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v2]
In-Reply-To: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
Message-ID: <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>

> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  8305427: code formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13293/files
  - new: https://git.openjdk.org/jdk/pull/13293/files/14e2c8b5..1905d463

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

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

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


From duke at openjdk.org  Wed Apr  5 13:45:29 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 13:45:29 GMT
Subject: Integrated: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
Message-ID: <8Yc4iv0s1X1ENM0xHCycFd-w9Ox1SDjkfIJQpGHPCeI=.b324ba50-0c52-4859-ad9d-340b3c583b76@github.com>

On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.

This pull request has now been integrated.

Changeset: f69d88c5
Author:    Nikita Gubarkov <nikita.gubarkov at jetbrains.com>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f69d88c57f98472c483a7dcedcfd5afb0dbd3930
Stats:     14 lines in 1 file changed: 14 ins; 0 del; 0 mod

8301616: Drag & maximize to another monitor places window incorrectly (Windows)

Reviewed-by: avu, aivanov, serb

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

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


From jdowland at openjdk.org  Wed Apr  5 14:08:22 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Wed, 5 Apr 2023 14:08:22 GMT
Subject: RFR: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
Message-ID: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>

This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350

`java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.

Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.

One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.

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

Commit messages:
 - 8304350: Font.getStringBounds calculates wrong width for TextAttribute.TRACKING other than 0.0

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

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


From duke at openjdk.org  Wed Apr  5 14:15:57 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 14:15:57 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v19]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <d7gctcuoa0TFJMyY8HGA8GNPsDVJ2CyOSz3UzxSIFcQ=.d3a520ad-21f8-4f7a-9bb9-4d8bae3e990e@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Moved tests to separate directory.
 - Get rid of charsToGlyphs[NS] boilerplate.
 - Removed getGlyphVectorOutline - it's unused and broken
 - ?
   
   - Removed font fallback hacks.
   - Changed composite font glyph code encoding scheme, refactored to use Font2D instead of PhysicalFont.
   - New Emoji logical font type with 2 underlying physical fonts.
 - Merge branch 'master' into JDK-8269806
 - Dynamic loading of ftcolor.h symbols on Linux.
 - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
 - Add braces to ifs.
 - Make tests headful.
 - Merge branch 'master' into JDK-8269806
 - ... and 21 more: https://git.openjdk.org/jdk/compare/2e59d21e...c1b8f9b2

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

Changes: https://git.openjdk.org/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=18
  Stats: 3786 lines in 74 files changed: 2553 ins; 785 del; 448 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/4798/head:pull/4798

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


From duke at openjdk.org  Wed Apr  5 14:16:01 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 14:16:01 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
Message-ID: <EDX-y0rcUnseZi2zSDkNAY8kBv_nuZVEqZfSX4gnNE0=.79e1e9ca-106d-404e-82c3-88da11743a32@github.com>

On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Dynamic loading of ftcolor.h symbols on Linux.
>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>  - Add braces to ifs.
>  - Make tests headful.
>  - Merge branch 'master' into JDK-8269806
>  - Remove ftcolor.c
>  - Skip tests if required font is absent
>  - Fix pointer to jlong conversion on x86
>  - Merge branch 'master' into JDK-8269806
>  - Merge branch 'master' into JDK-8269806
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

New update:
- Composite fonts can now be nested, holding list of Font2Ds instead of PhysicalFonts. This gives more flexibility for implementing complex font fallback approaches and is necessary to implement proper emoji+VS fallback on Windows. Glyph code encoding was changed to support this, previously glyph code occupied 24 low bits and slot was encoded in 8 high bits, now slot is encoded in low bits instead (number of bits is dynamic) and glyph code is shifted, which allows stacking of glyph codes for nested composite mappers.
- Removed Windows fontconfig hacks in favor of the new EmojiFont.
- Refactored charsToGlyphs & charsToGlyphsNS copy-paste in mapper classes.
- Moved emoji tests to separate directory.

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

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


From duke at openjdk.org  Wed Apr  5 14:31:34 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 14:31:34 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v20]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <r2342xyr5gxyL71JaSgboy4UlWRzrDLg68QD4La_g44=.0ce24218-a6de-4464-a536-6535949fbe51@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

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

  EmojiFont CRLF -> LF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/c1b8f9b2..624af032

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=18-19

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

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


From duke at openjdk.org  Wed Apr  5 15:00:17 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 15:00:17 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <npeQElnVpZRPusQ8OHYJqy7pWxdyGrj7NQZFcS6J3Hk=.3a159747-a577-4a2b-9992-b49b13101666@github.com>

On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

I am currently working on a patch for per-monitor scale on Linux and this feature is a crucial dependency for me.
Having independent monitor scales require changing userspace conversion function the way it's done on Windows, so that it depends on screen bounds, so repeatedly getting fresh bounds on each scaleUpX/scaleUpY/scaleDownX/scaleDownY call is unacceptable.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1497632713


From duke at openjdk.org  Wed Apr  5 16:02:21 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 16:02:21 GMT
Subject: RFR: 8305666: Add system property for fair AWT lock
Message-ID: <FVKOMEGLy18sellibnEH5l5CMHTbXp4fSN3ccgifyok=.9a2af404-338d-4c85-b473-0ee94cd2f423@github.com>

There are freezes reported on some Linux configurations which are believed to may be caused by the toolkit thread quickly reacquiring AWT_LOCK while polling for events, which starves EDT waiting on that lock.
Adding new `awt.lock.fair` system property can help diagnosing such issues.

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

Commit messages:
 - 8305666: Add system property for fair AWT lock

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

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


From rriggs at openjdk.org  Wed Apr  5 16:06:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 16:06:25 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
Message-ID: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>

Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
The enumeration values are defined to match those used in the build.
The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
Note that `amd64` and `x86_64` in the build are represented by `X64`.
The values of the system property `os.arch` is unchanged.

The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

Commit messages:
 - 8304915: Create jdk.internal.util.Architecture enum and apply

Changes: https://git.openjdk.org/jdk/pull/13357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304915
  Stats: 279 lines in 10 files changed: 265 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From duke at openjdk.org  Wed Apr  5 16:26:15 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 16:26:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>

On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:

> 75:      * {@return {@code true} if the current architecture is IA64}
> 76:      */
> 77:     public static boolean isIA64() {

Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized?

I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158748071


From erikj at openjdk.org  Wed Apr  5 16:40:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Apr 2023 16:40:06 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <ayNmGsyResKyCueqD6aTS5L0uh70jHoyOkiB5GLRmcM=.fcc4dc7e-cc0f-4056-a16e-c08d47603bcb@github.com>

On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Looks good from a build point of view.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373301135


From duke at openjdk.org  Wed Apr  5 17:11:08 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 5 Apr 2023 17:11:08 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not detected
 on Windows
Message-ID: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>

`data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.

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

Commit messages:
 - 8305667: Some fonts installed in user directory are not detected on Windows

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

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


From rriggs at openjdk.org  Wed Apr  5 17:18:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 17:18:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
Message-ID: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>

On Wed, 5 Apr 2023 16:23:08 GMT, Glavo <duke at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:
> 
>> 75:      * {@return {@code true} if the current architecture is IA64}
>> 76:      */
>> 77:     public static boolean isIA64() {
> 
> Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized?
> 
> I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet.

Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names.
Using all upper case would make them consistent with the Enum names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158801096


From jjg at openjdk.org  Wed Apr  5 17:38:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 17:38:12 GMT
Subject: RFR: JDK-8305593: Add @spec tags in java.desktop
Message-ID: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>

Please review a docs-only change to add `@spec` tags into `java.desktop` public API files

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

Commit messages:
 - JDK-8305593: Add @spec tags in java.desktop

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

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


From duke at openjdk.org  Wed Apr  5 17:41:04 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 17:41:04 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
In-Reply-To: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <t3MnPRyEwHwsVMPhYfAjaSQ4LYfELEj_zXHGu5KurWM=.fd0179d1-e84b-4af1-82b2-bcf89ed1355f@github.com>
 <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com>
Message-ID: <cOIMF34EcOAPchse1nXXFwDxxu9RGREACA050iTI-PE=.e1126679-6315-4837-9880-ee576bf7c29c@github.com>

On Wed, 5 Apr 2023 17:15:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names. Using all upper case would make them consistent with the Enum names.

What I mean is, should we rename these methods? Because they are really ugly.

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L91

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L105

https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L112

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158823225


From rriggs at openjdk.org  Wed Apr  5 18:53:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 18:53:12 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v2]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Rename isXXX method to be uppercase architecture names matching the enum.
  Refactor the is64Bit method to be a static method for the current runtime.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/0c61382d..bef30f96

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

  Stats: 72 lines in 5 files changed: 35 ins; 13 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From duke at openjdk.org  Wed Apr  5 18:55:19 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 18:55:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v2]
In-Reply-To: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com>
Message-ID: <qN_H6ys21NPr-SV_uL2LNiA5RHizrE0sLvoq8or-Py4=.f33b71d1-f48b-413f-82cd-86a951d07d3f@github.com>

On Wed, 5 Apr 2023 18:53:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename isXXX method to be uppercase architecture names matching the enum.
>   Refactor the is64Bit method to be a static method for the current runtime.

src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:

> 83:      */
> 84:     @ForceInline
> 85:     public static boolean isRISCV() {

I think it should be named `isRISCV64` because RISC-V also has a 32-bit variant, so the name `isRISCV` may cause confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158897476


From rriggs at openjdk.org  Wed Apr  5 19:05:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 19:05:03 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v3]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <bUOhtX5Ni80FR0ljiFP_l76p_1Jh82sBTRmlv3B1j1E=.0c2b8db4-76cf-405d-8ecc-a7e3e2a09c67@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Correct name of isRISCV64 method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/bef30f96..3349b46d

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

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

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


From dnguyen at openjdk.org  Wed Apr  5 19:06:15 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 5 Apr 2023 19:06:15 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon
In-Reply-To: <hlT6emauc6yxQlMbNgTUZ1yvyoWIl1peXLWU5DHXP84=.e79d6c3d-b5d4-40c5-be1d-9d2e5b028221@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
 <BWrSpslSTMevPo6U_dbp4aO4gz533y3sfcId25DU9rk=.d629e492-af14-4aa4-a557-e69b2f0250e5@github.com>
 <hlT6emauc6yxQlMbNgTUZ1yvyoWIl1peXLWU5DHXP84=.e79d6c3d-b5d4-40c5-be1d-9d2e5b028221@github.com>
Message-ID: <0mBTaccv0PbC0T2WcG9H8bYjly3Vm4TUHABhMp_rWlo=.8599848a-c215-4c4e-9eb3-a81f24ce2629@github.com>

On Wed, 5 Apr 2023 04:44:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Tested changes and confirmed it works as expected. I noticed the focus still shows for Metal & Motif. Should Metal be updated to reflect the same change?
> 
> Yeah, it's because the fix is Windows OS specific (Changes applied in Windows L&F).

Looks good to me then.

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

PR Comment: https://git.openjdk.org/jdk/pull/13153#issuecomment-1497979122


From rriggs at openjdk.org  Wed Apr  5 19:20:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 19:20:08 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Correct spelling of isAARCH64 in WIndows AttachProviderImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/3349b46d..8916dcae

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

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

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


From duke at openjdk.org  Wed Apr  5 20:35:17 2023
From: duke at openjdk.org (Bernd)
Date: Wed, 5 Apr 2023 20:35:17 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:

> 46:         // might be running in a 32-bit VM on a 64-bit platform.
> 47:         // addressSize will be correctly 32
> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {

Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:

> 75:      */
> 76:     @ForceInline
> 77:     public static boolean isARM() {

It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)

test/jdk/jdk/internal/util/ArchTest.java line 58:

> 56:     @Test
> 57:     public void nameVsCurrent() {
> 58:         String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT);

Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158982643
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158988981
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158993835


From rriggs at openjdk.org  Wed Apr  5 20:43:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 20:43:27 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>

On Wed, 5 Apr 2023 20:25:43 GMT, Bernd <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:
> 
>> 46:         // might be running in a 32-bit VM on a 64-bit platform.
>> 47:         // addressSize will be correctly 32
>> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {
> 
> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159001239


From rriggs at openjdk.org  Wed Apr  5 20:52:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 20:52:15 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <Y-C9ir5RmytyeZPaxBlFdMIk7QkKdXsO2yLDNK-515o=.b60f5eae-2707-41a2-9e13-93c42500bcf6@github.com>

On Wed, 5 Apr 2023 20:31:43 GMT, Bernd <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> test/jdk/jdk/internal/util/ArchTest.java line 58:
> 
>> 56:     @Test
>> 57:     public void nameVsCurrent() {
>> 58:         String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT);
> 
> Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)?

That's a different set of twisty build and native source files, I'll create an issue to re-visit that.
It may not change too much, the native code needs to initialize `os.arch` very early.
[JDK-8305676](https://bugs.openjdk.org/browse/JDK-8305676)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159009755


From duke at openjdk.org  Wed Apr  5 21:21:07 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 21:21:07 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
Message-ID: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>

On Wed, 5 Apr 2023 20:40:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:
>> 
>>> 46:         // might be running in a 32-bit VM on a 64-bit platform.
>>> 47:         // addressSize will be correctly 32
>>> 48:         if (Architecture.isX64() && ADDRESS_SIZE == 64) {
>> 
>> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
>
> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
> But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.

> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime

Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159032441


From duke at openjdk.org  Wed Apr  5 21:40:16 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 5 Apr 2023 21:40:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
Message-ID: <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>

On Wed, 5 Apr 2023 20:28:17 GMT, Bernd <duke at openjdk.org> wrote:

> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)

I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense.

For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159047360


From jvernee at openjdk.org  Wed Apr  5 23:42:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 23:42:13 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

test/jdk/java/foreign/TestUnsupportedLinker.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @ignore architecture can not be overridden by setting os.arch - delete test

FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159130445


From jvernee at openjdk.org  Wed Apr  5 23:50:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Apr 2023 23:50:05 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
Message-ID: <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>

On Wed, 5 Apr 2023 21:18:43 GMT, Glavo <duke at openjdk.org> wrote:

>> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies.  ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
>> But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.
>
>> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
> 
> Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture.

Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` is the runtime platform in this case, but the VM variant can still be 32 bits.

Since `Architecture.isX64` seems to be the target arch of the VM, I'm think that when running a 32-bit VM on a amd64 would result in `isX64` being `false`? (In that case, only the `isX64` check should be enough)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159142830


From duke at openjdk.org  Thu Apr  6 03:27:18 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 03:27:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

Per?@Glavo?s [comment][GH?13357#r1159047360]:

[GH?13357#r1159047360]: https://github.com/openjdk/jdk/pull/13357#discussion_r1159047360

src/java.base/share/classes/jdk/internal/util/Architecture.java line 37:

> 35: public enum Architecture {
> 36:     X64(),        // Represents AMD64 and X86_64
> 37:     X86(),

Suggestion:

    X86_64(),        // Represents AMD64 and X86_64
    X86_32(),

src/java.base/share/classes/jdk/internal/util/Architecture.java line 39:

> 37:     X86(),
> 38:     IA64(),
> 39:     ARM(),

Suggestion:

    ARM32(),

src/java.base/share/classes/jdk/internal/util/Architecture.java line 53:

> 51:      */
> 52:     @ForceInline
> 53:     public static boolean isX64() {

Suggestion:

    public static boolean isX86_64() {

src/java.base/share/classes/jdk/internal/util/Architecture.java line 61:

> 59:      */
> 60:     @ForceInline
> 61:     public static boolean isX86() {

Suggestion:

    public static boolean isX86_32() {

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

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373996601
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242846
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242963
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245067
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245163


From duke at openjdk.org  Thu Apr  6 03:27:21 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 03:27:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <sT3Awtma89tTplYplOqA3gP6chUCMu12WMcjB2BPyuw=.515492b6-3cad-4006-a053-fcca6f1d5b31@github.com>
Message-ID: <7EnGBAROZJ-eiWhNUPPVUL2oPQDWGF_7Dd7sPT_ihNs=.c3317c6f-0986-4ba8-8bb2-62cd2b2ba390@github.com>

On Wed, 5 Apr 2023 21:36:57 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:
>> 
>>> 75:      */
>>> 76:     @ForceInline
>>> 77:     public static boolean isARM() {
>> 
>> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)
>
>> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove)
> 
> I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense.
> 
> For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used.

Suggestion:

    public static boolean isARM32() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159243677


From psadhukhan at openjdk.org  Thu Apr  6 06:54:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 6 Apr 2023 06:54:57 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon [v2]
In-Reply-To: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
Message-ID: <fhu54Oc4UKG-uYb0A3XWI8CPUyWGQnLnZINlaEuPjMs=.b19d0f1e-e3da-4fb8-98e7-76590fce6a28@github.com>

> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
> 
> This is what can be seen in windows system setting
> 
> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
> 
> and notepad
> 
> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
> 
> We have currently
> 
> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
> 
> 
> and after fix
> 
> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)

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

  Test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13153/files
  - new: https://git.openjdk.org/jdk/pull/13153/files/4fbd354f..6ed26392

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

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

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


From psadhukhan at openjdk.org  Thu Apr  6 07:01:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 6 Apr 2023 07:01:15 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon [v3]
In-Reply-To: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
Message-ID: <5biHFP0PwllKWV_Wb7HOMK_6DSwI_UB2bhdZldd5D7w=.0e4f2114-28fe-4b8f-8b85-2f949f178cfa@github.com>

> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
> 
> This is what can be seen in windows system setting
> 
> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
> 
> and notepad
> 
> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
> 
> We have currently
> 
> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
> 
> 
> and after fix
> 
> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)

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

  Test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13153/files
  - new: https://git.openjdk.org/jdk/pull/13153/files/6ed26392..60a13228

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

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

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


From pminborg at openjdk.org  Thu Apr  6 07:39:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Apr 2023 07:39:17 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 114:

> 112: 
> 113:     /**
> 114:      * {@return return the current architecture}

Suggestion :

{@return the current architecture}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159396971


From pminborg at openjdk.org  Thu Apr  6 07:45:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Apr 2023 07:45:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.

Why 2018?

src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:

> 83:      */
> 84:     @ForceInline
> 85:     public static boolean isRISCV64() {

Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159404227
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159402728


From duke at openjdk.org  Thu Apr  6 08:02:19 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:02:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <DI1Ik8MSwOL9Iol8Z-7wwkTeVIihP6b4WIfXgKjQ5IQ=.1dc38421-ada7-4837-849d-05d617827316@github.com>
Message-ID: <X3waE5jxXJlMlgiSW1tQXtYyxNGeUz8pfYN6JFv9gco=.d846bec5-8362-41fa-999d-7ad28a486831@github.com>

On Thu, 6 Apr 2023 07:36:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 114:
> 
>> 112: 
>> 113:     /**
>> 114:      * {@return return the current architecture}
> 
> Suggestion :
> 
> {@return the current architecture}.

Suggestion:

     * {@return the current architecture}.


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

@minborg
You?need to?use:

Suggestion:

     * {@return the current architecture}.



For?**GitHub** to?recognise?it as?a?suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159422715


From duke at openjdk.org  Thu Apr  6 08:08:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:08:23 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
Message-ID: <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>

On Thu, 6 Apr 2023 07:40:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:
> 
>> 83:      */
>> 84:     @ForceInline
>> 85:     public static boolean isRISCV64() {
> 
> Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?

`Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159428913


From duke at openjdk.org  Thu Apr  6 08:08:20 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Apr 2023 08:08:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 26:

> 24: 
> 25: import jdk.internal.vm.annotation.ForceInline;
> 26: 

Suggestion:

import jdk.internal.vm.annotation.ForceInline;
import jdk.internal.vm.annotation.Stable;

src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:

> 45: 
> 46:     // Cache a copy of the array for lightweight indexing
> 47:     private static final Architecture[] archValues = Architecture.values();

This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
Suggestion:

    private static final @Stable Architecture[] archValues = Architecture.values();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159426832
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159424057


From duke at openjdk.org  Thu Apr  6 08:16:19 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 08:16:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
 <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
Message-ID: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>

On Wed, 5 Apr 2023 23:46:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` can be `amd64`, the runtime platform, in this case, but the VM variant can still be 32 bits.

`os.arch` is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.

But as mentioned above, the size of the address can be independent of these. 

Linux x32 ABI is an ABI for the x86-64 architecture, which uses unique features of 64-bit architectures such as 64-bit registers, but it uses 32-bit addresses.

Although OpenJDK does not support such a platform, technically speaking, it is still necessary to distinguish between architecture bits and address bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159438411


From avu at openjdk.org  Thu Apr  6 09:53:27 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 6 Apr 2023 09:53:27 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <hzOMx5ufbIbRaBYTnkgO6ujTufGVu3zEXO_691n0_A8=.5f24083c-d2ee-4548-909d-697f08d0ae30@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
 <hzOMx5ufbIbRaBYTnkgO6ujTufGVu3zEXO_691n0_A8=.5f24083c-d2ee-4548-909d-697f08d0ae30@github.com>
Message-ID: <kYfcNFyCmI76K6YVNtYyvHyVRHKZfZTXTy7h0NijeNM=.7a074979-2e45-4b64-9fd3-75f0c8f5c8f6@github.com>

On Mon, 3 Apr 2023 12:18:34 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> on x64 based systems : Swingmark performance is back to normal, but, one of the J2DBenchmark test shows 20% degradation.

@aghaisas what particular test showed the regression, I've tested x64 and aarch64 macs with different tests from J2DBench and haven't found regressions yet. Also, could you provide your J2DBench options file?

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

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1498787461


From mike at hydraulic.software  Thu Apr  6 11:05:19 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Thu, 6 Apr 2023 13:05:19 +0200
Subject: Could anyone take a look at quality-of-life bug JDK-8258918?
Message-ID: <CAGv+2bMSSvOcob8LscNvu30u9apwYaB_uMuR0foYUMua9vx9qQ@mail.gmail.com>

Developing GUI apps on macOS can be a bit annoying due to slow startup
and screen flashes due to GPU switching. Last week I dug in and found
the solution turned out to be the following JDK patch:

diff --git a/make/data/bundle/cmdline-Info.plist
b/make/data/bundle/cmdline-Info.plist
index 7d6af359128..ebaaee7e827 100644
--- a/make/data/bundle/cmdline-Info.plist
+++ b/make/data/bundle/cmdline-Info.plist
@@ -12,6 +12,8 @@
         <string>@@BUILD_VERSION@@</string>
         <key>NSMicrophoneUsageDescription</key>
         <string>The application is requesting access to the
microphone.</string>
+        <key>NSSupportsAutomaticGraphicsSwitching</key>   <!-- avoids
flashing for unpackaged JavaFX apps -->
+        <true/>
         @@EXTRA@@
 </dict>
 </plist>

I found JDK-8258918 about it, but not much has happened since 2021.

This patch really makes a big difference to how enjoyable it is to do
desktop work with Java on macOS, and it's a two line fix (+a few more
for the release notes). Although the issue goes away if you properly
package your app by including this plist key, that doesn't help during
development which is also the time you're most likely restarting your
app the most. My enjoyment level went up a lot since applying this
patch but of course that requires you to do a custom build of the JDK,
which is a bit much for most GUI devs.

The main risk is that it would reduce performance unexpectedly, so
would need a release note. However, the current setting also reduces
performance in the form of lower battery life and slow startup. For me
this one setting makes as much difference as all of AppCDS so it's
definitely worth it! Could someone maybe look at making the change
(this patch is too small to be copyrightable but I signed the Oracle
CLA in the past anyway).

thanks,
-mike


From avu at openjdk.org  Thu Apr  6 11:34:13 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 6 Apr 2023 11:34:13 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows
In-Reply-To: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
Message-ID: <gLVDo89sa5WD7FTsNn9TC5CazzNdpDvyqoS-KUp0Sj8=.b2285ec3-23a4-47ca-b0a5-cf4795827c68@github.com>

On Wed, 5 Apr 2023 17:03:45 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.

Looks good

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13359#pullrequestreview-1374677291


From aghaisas at openjdk.org  Thu Apr  6 12:03:15 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 6 Apr 2023 12:03:15 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
References: <Pr6TnirJSuSnjwukJfZ3cUqIVvijx4JbxGQlu3qlAEw=.fd682e3e-bc23-4487-95b1-ca4db8fb34b3@github.com>
Message-ID: <O2LKc8GPmUzCKUN6UNLSAxSUDdi3hcbXpPLlspQEOBw=.5ff43786-695e-4fb2-9a31-7ddd654e8bcf@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

Those are the test batches run on internal servers.
I will see if I can construct and share the J2DBench option file that shows the difference.

The results that prompted my review comments-

**J2DBench test related to opaque image rendering **
------------------------------------------------------

Compared to the current mainline metal rendering pipeline performance -

| Architecture | Your fix | Your fix + adding back BlitCommandQueue |
| ------------ | ------------- | ------------- |
| x64  | -88% degradation  | -20% degradation  |
| aarch64 | -4% degradation | -1% degradation (negligible) |



**Swingmark test** shows -
------------------------------------------------------
| Architecture | Your fix | Your fix + adding back BlitCommandQueue |
| ------------ | ------------- | ------------- |
| x64  | > -100% degradation  | Equal to mainline  |
| aarch64 | -20% degradation  | -15% degradation |

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

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1498951287


From jvernee at openjdk.org  Thu Apr  6 12:32:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Apr 2023 12:32:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com>
 <nLwwrSP70xk9K8LB8A12aWZYjI6XVDCa51x7DR9OoVk=.baed90d9-9f56-479c-8af5-8d1c7749f889@github.com>
 <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com>
 <No3cTS4RYljpCXCUS6hzxAnnvZpYgpco5JNBkU7Vpgw=.4dddf75c-5703-4955-b126-73ea99004a82@github.com>
 <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com>
Message-ID: <RIoft18UIqYlHjwybyOYApGv8h94sp2V0_yJRBNp5uE=.793455d2-0e07-4e22-b3e3-89dd651029c0@github.com>

On Thu, 6 Apr 2023 08:11:45 GMT, Glavo <duke at openjdk.org> wrote:

> os.arch is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.

Okay, I could have sworn we had to add the `ADDRESS_SIZE` check because of this issue where a 32-bit VM running on x64 would erroneously select the x64 ABIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159734833


From rriggs at openjdk.org  Thu Apr  6 13:34:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:34:13 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
Message-ID: <sepxAFSgYMetWe8oTnqeZHFSUZVZM_CO99-QFmj8lYI=.7f2c4ce3-86a3-4937-9322-acd6fa5549a5@github.com>

On Thu, 6 Apr 2023 03:17:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 37:
> 
>> 35: public enum Architecture {
>> 36:     X64(),        // Represents AMD64 and X86_64
>> 37:     X86(),
> 
> Suggestion:
> 
>     X86_64(),        // Represents AMD64 and X86_64
>     X86_32(),

The underscores are too ugly and X86 and X64 are well accepted names for those architectures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159804212


From rriggs at openjdk.org  Thu Apr  6 13:34:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:34:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <CcdC-dn_yOzKYNQ5L2jhMZwRe_x5q59mxo6RpTIDs-E=.e1c302d4-3c5e-4892-9a52-e2f7efe2d246@github.com>
Message-ID: <WOwDnuubxA88fWJ5Xn0u_B6xS1G6pjAbHYSC9l8WDb4=.d1b0a0f0-a0b9-44ae-8072-29faf84f7358@github.com>

On Wed, 5 Apr 2023 23:39:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> test/jdk/java/foreign/TestUnsupportedLinker.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @ignore architecture can not be overridden by setting os.arch - delete test
> 
> FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28

I'll drop the changes to foreign to avoid conflicts with PR #13079.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159801845


From rriggs at openjdk.org  Thu Apr  6 13:41:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:41:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
Message-ID: <iS3fMy_lLdnJ4ouROyFQ9hyBk0YIg16idCaWq7pWQoY=.a57c5f92-8a89-4cfd-b3d9-7365810b45f4@github.com>

On Thu, 6 Apr 2023 07:41:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Why 2018?

Copy/paste error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159813009


From jpai at openjdk.org  Thu Apr  6 13:41:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 13:41:24 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
Message-ID: <MiQD6AQa57VKQSBc-OsOiFLEEmMga3F0UdxOQp5SUgU=.0281f55f-5e7c-4e9c-a8a3-30f886a826b3@github.com>

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/util/Architecture.java line 42:

> 40:     AARCH64(),
> 41:     RISCV64(),
> 42:     S390X(),

Hello Roger, in a recent unrelated discussion, @RealLucy noted here https://github.com/openjdk/jdk/pull/13228#issuecomment-1488650865 that `s390x` denotes the arch and operating system combination and `s390` on the other hand represents the architecture. So should this enum value instead be `S390`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159810942


From rriggs at openjdk.org  Thu Apr  6 13:41:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 13:41:26 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <yFfP_oPn6GzKwA6avyNt3STIz49hjD1Gv5YSb2A-CgU=.52dd7fca-5f64-4665-8a06-e0272aa82c7d@github.com>
 <la0VOIRB7qmN9Y0_mUCl9-8oloBAW9ZW4vZ0ddAHgqo=.d9490bcb-a45d-4cac-a09c-683ee1c80f75@github.com>
Message-ID: <GsIzbdOe1YK90czP28gCz7GNhSrkh5cxw6yuU87M2qw=.b22c61be-3446-4355-9ec7-0f148f331b9c@github.com>

On Thu, 6 Apr 2023 08:05:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 85:
>> 
>>> 83:      */
>>> 84:     @ForceInline
>>> 85:     public static boolean isRISCV64() {
>> 
>> Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ?
>
> `Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT.

The `isXXX` is lighterweight and easier to read.  
With current compiler technology, it can result in dead code elimination.
The HotSpot compiler reduces `(Architecture.current() == Architecture.X)` at runtime.  
Project Leyden may enable dead code based on evaluating more complex expressions as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159811629


From rriggs at openjdk.org  Thu Apr  6 14:11:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 14:11:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <LoWlJFwsXXbDwr7WfOPP49CDMOnE3aU7vD7VILWDQkE=.07eb72c5-7bcc-4d9a-9518-14ce48dd2d63@github.com>
Message-ID: <icOZtPetzIY9nTxlxASs1i4P-fprSHWpsSEubEcUYvE=.44380123-6097-4609-8dc6-74b3a9be386f@github.com>

On Thu, 6 Apr 2023 03:17:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 39:
> 
>> 37:     X86(),
>> 38:     IA64(),
>> 39:     ARM(),
> 
> Suggestion:
> 
>     ARM32(),

I'm inclined to drop the enum value and isArm method because they are legacy and are not being used in OpenJDK sources.  This could also apply to IA64. 
They can be added if needed and otherwise are just unused bulk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159852394


From psadhukhan at openjdk.org  Thu Apr  6 14:22:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 6 Apr 2023 14:22:17 GMT
Subject: RFR: 4825182: DefaultBoundedRangeModel.setMinimum() changes extent
 unnecessarily
Message-ID: <zHp80OVLg5z1_ctDda9Zc8ZXMgVwaBP3xfKla_B91so=.06c9528e-5f79-4bd4-bb00-c0f36f10a94e@github.com>

[DefaultBoundedRangeModel spec](https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/javax/swing/DefaultBoundedRangeModel.html#%3Cinit%3E(int,int,int,int))
set maximum, minimun., extent as per the constraint "min <= value <= value+extent <= max"
Now, when DefaultBoundedRangeModel.setMinimum() is called with same "value" then because of the integer overflow in `setMinimum` method, it causes the `extent `to become 0.

Fix the integer overflow and make sure the extent is not changed unncessarily

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

Commit messages:
 - 4825182: DefaultBoundedRangeModel.setMinimum() changes extent unnecessarily

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

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


From aghaisas at openjdk.org  Thu Apr  6 14:24:22 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 6 Apr 2023 14:24:22 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if created
 during display sleep
Message-ID: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>

Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.

Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

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

Commit messages:
 - Recreate CVDisplayLink on screen sleep/wakeup events

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

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


From duke at openjdk.org  Thu Apr  6 15:31:14 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 6 Apr 2023 15:31:14 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
Message-ID: <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>

On Thu, 6 Apr 2023 08:00:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:
> 
>> 45: 
>> 46:     // Cache a copy of the array for lightweight indexing
>> 47:     private static final Architecture[] archValues = Architecture.values();
> 
> This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
> Suggestion:
> 
>     private static final @Stable Architecture[] archValues = Architecture.values();

Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159957027


From rriggs at openjdk.org  Thu Apr  6 16:29:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 16:29:09 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v4]
In-Reply-To: <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <AHv28VpSr3N2QQfgnWjRb10EDHio9mCo0pX-KHgYP2o=.f5ca31e6-b8c0-431a-a1ce-8e7375bcdb75@github.com>
 <RLXITzKGMBGDGi0WLRNF4I4ztakWC96rvnmZHQxFzBY=.1381d600-b541-4daa-996e-3ca6f4e257f6@github.com>
 <TVg8nM0cVwBPeGov7T6m-gl1Bhb9U598OYJKB6UfiyI=.801efaf7-8fd7-4d40-9b34-50e124e75a67@github.com>
Message-ID: <vbNizO04e07ExQof6jN2gwc5nX-ZHKqOyTnEV9z8AXQ=.6740715b-a821-4890-9627-a13372d1ac67@github.com>

On Thu, 6 Apr 2023 15:27:49 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:
>> 
>>> 45: 
>>> 46:     // Cache a copy of the array for lightweight indexing
>>> 47:     private static final Architecture[] archValues = Architecture.values();
>> 
>> This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable:
>> Suggestion:
>> 
>>     private static final @Stable Architecture[] archValues = Architecture.values();
>
> Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property.

The use here is not particularly performance sensitive. So it doesn't provide much value.
In this case, it allows each array element to be considered stable.

>From the @Stable javadoc:

 * Fields which are declared {@code final} may also be annotated as stable.
 * Since final fields already behave as stable values, such an annotation
 * conveys no additional information regarding change of the field's value, but
 * still conveys information regarding change of additional components values if
 * the type of the field is an array type (as described above).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160018375


From rriggs at openjdk.org  Thu Apr  6 17:17:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 17:17:35 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Revert changes to Foreign API to avoid class with another PR
  Rename S390X to S390, representing just the s390 architecture
  Removed ARM and IA64 enum values; they are unused; they can be added later if needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/8916dcae..105ce605

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

  Stats: 58 lines in 5 files changed: 5 ins; 32 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From rriggs at openjdk.org  Thu Apr  6 18:43:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 18:43:07 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v3]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <bLUsfHRG5yBfdkTbs-Vez207p2cYxUlFDakcAaXB1Hg=.0817ffbc-5013-4ba9-ba3a-acbcf85915c9@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

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

  Update copyright
  Replaced a few more uses of os.name.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/7f93ecbf..8f0b918e

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

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

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


From alanb at openjdk.org  Thu Apr  6 18:47:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 18:47:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
Message-ID: <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>

On Thu, 6 Apr 2023 17:17:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to Foreign API to avoid class with another PR
>   Rename S390X to S390, representing just the s390 architecture
>   Removed ARM and IA64 enum values; they are unused; they can be added later if needed

src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51:

> 49:             !Architecture.isAARCH64()) {
> 50:             throw new RuntimeException(
> 51:                 "This provider is not supported on this processor architecture: " + Architecture.current());

Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the  attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160140379


From rriggs at openjdk.org  Thu Apr  6 19:06:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:06:16 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v6]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <rg324NqOtoFCh3AhKz2rWKjq45ShY5Kk17RdHGGtiZU=.df9e078c-052c-4485-9e19-3d6734ebc873@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove obsolete conditions in Windows AttachProviderImpl.
  All platforms and architectures that can be built support attach.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/105ce605..ab084c27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=04-05

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

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


From rriggs at openjdk.org  Thu Apr  6 19:06:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:06:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
 <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
Message-ID: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>

On Thu, 6 Apr 2023 18:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to Foreign API to avoid class with another PR
>>   Rename S390X to S390, representing just the s390 architecture
>>   Removed ARM and IA64 enum values; they are unused; they can be added later if needed
>
> src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51:
> 
>> 49:             !Architecture.isAARCH64()) {
>> 50:             throw new RuntimeException(
>> 51:                 "This provider is not supported on this processor architecture: " + Architecture.current());
> 
> Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the  attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160154277


From alanb at openjdk.org  Thu Apr  6 19:15:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 19:15:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v5]
In-Reply-To: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <RNCT_0qrYIiGhIqeW400LQizY12I8E3KUfh7miWaPCs=.97b3db84-d3f1-4d8f-bb16-b4230e4da670@github.com>
 <pXO1Amr7Pdib4u5KY4MJ_u7k72PpfbXy8-mKbjD7erw=.d2e7b6c5-8e98-47c1-af92-dca2b4fb7d83@github.com>
 <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com>
Message-ID: <y48cQRq1AcsvBI3l28dcA4KbXtayFp-vQONNKNONu2Q=.d525a706-aaad-4a30-9676-2065e816df91@github.com>

On Thu, 6 Apr 2023 19:01:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed.

Good, that makes it simpler and it means the qualified export can be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160162760


From rriggs at openjdk.org  Thu Apr  6 19:25:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 19:25:19 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove unneeded qualified export from java.base to jdk.attach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/ab084c27..52ca4a70

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

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

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


From duke at openjdk.org  Thu Apr  6 19:58:21 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 19:58:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:

> 98:      */
> 99:     public static Architecture current() {
> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];

I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.

Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160193842


From rriggs at openjdk.org  Thu Apr  6 20:27:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:27:22 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
Message-ID: <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>

On Thu, 6 Apr 2023 19:55:07 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:
> 
>> 98:      */
>> 99:     public static Architecture current() {
>> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];
> 
> I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.
> 
> Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?

There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.

The template file used in the implementation could be renamed to be more agnostic to OS or arch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160226259


From stuefe at openjdk.org  Thu Apr  6 20:31:21 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 6 Apr 2023 20:31:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

What about PPC (big endian)? Used on AIX? 

On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499585079


From stuefe at openjdk.org  Thu Apr  6 20:42:18 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 6 Apr 2023 20:42:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

Another question, how does this work with Zero?

I know e.g. Debian maintains a broad range of Zero JVMs on different target CPUs. Things like ia64 and parisc. What is the os.arch value on those, and how will this work with the limited set of enums we replace it with?

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499594972


From rriggs at openjdk.org  Thu Apr  6 20:42:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:42:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
Message-ID: <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>

On Thu, 6 Apr 2023 20:28:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What about PPC (big endian)? Used on AIX?

I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`.

> 
> On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).

For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates.

For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499597036


From duke at openjdk.org  Thu Apr  6 20:45:21 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 20:45:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
Message-ID: <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>

On Thu, 6 Apr 2023 20:24:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 100:
>> 
>>> 98:      */
>>> 99:     public static Architecture current() {
>>> 100:         return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL];
>> 
>> I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream.
>> 
>> Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added  to the enum to represent other architectures that are not of concern?
>
> There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
> The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
> Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.
> 
> The template file used in the implementation could be renamed to be more agnostic to OS or arch.

I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. 

Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all:

https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40

Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160242246


From rriggs at openjdk.org  Thu Apr  6 20:53:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:53:18 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <MKuFpznU5E4HZbE1eLsTk9EGJvH5AvrBpDDrVVvMQz0=.9d894a93-b4bf-4e84-9178-6cf2b08e0049@github.com>
Message-ID: <uvmDQLXP0-JK7qjEGK80qRpwYD8G0b0MtEJBY6KEsKY=.31e25922-0f8e-4693-af7c-3d40dea07753@github.com>

On Thu, 6 Apr 2023 20:38:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Another question, how does this work with Zero?

Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499606550


From rriggs at openjdk.org  Thu Apr  6 20:59:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Apr 2023 20:59:22 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
Message-ID: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>

On Thu, 6 Apr 2023 20:42:26 GMT, Glavo <duke at openjdk.org> wrote:

>> There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
>> The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
>> Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.
>> 
>> The template file used in the implementation could be renamed to be more agnostic to OS or arch.
>
> I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. 
> 
> Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all:
> 
> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
> 
> Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough.

The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. 

What did you use as the example that would not compile on the other architecture?
Did you make the other changes to the build that would be needed for a new architecture?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160252604


From duke at openjdk.org  Thu Apr  6 21:20:20 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 6 Apr 2023 21:20:20 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
Message-ID: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>

On Thu, 6 Apr 2023 20:56:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> What did you use as the example that would not compile on the other architecture? 

https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40

I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.

> Did you make the other changes to the build that would be needed for a new architecture?

I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 

According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?

For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160266038


From prr at openjdk.org  Thu Apr  6 22:47:58 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Apr 2023 22:47:58 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169:

> 167:         // Load the appropriate DLLs
> 168:         boolean is32on64 = false;
> 169:         if (Architecture.isX86()) {

This would be another coupling of java.desktop into java.base internals and I don't think it worth it.
Particularly because this check is obsolete !
It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit.
We don't even have  the file it is looking for in the build - even if someone did a 32 bit build.
Instead of making this change a bug should be filed to remove this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160314934


From duke at openjdk.org  Thu Apr  6 23:39:44 2023
From: duke at openjdk.org (Karl T)
Date: Thu, 6 Apr 2023 23:39:44 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon [v3]
In-Reply-To: <5biHFP0PwllKWV_Wb7HOMK_6DSwI_UB2bhdZldd5D7w=.0e4f2114-28fe-4b8f-8b85-2f949f178cfa@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
 <5biHFP0PwllKWV_Wb7HOMK_6DSwI_UB2bhdZldd5D7w=.0e4f2114-28fe-4b8f-8b85-2f949f178cfa@github.com>
Message-ID: <GAwUkbfnbJzDNwwxibxM19vqsswbklLygD2m8I7kbsk=.961939b6-8ac1-4e62-8cd8-cf31dcc592bb@github.com>

On Thu, 6 Apr 2023 07:01:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
>> 
>> This is what can be seen in windows system setting
>> 
>> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
>> 
>> and notepad
>> 
>> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
>> 
>> We have currently
>> 
>> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
>> 
>> 
>> and after fix
>> 
>> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test added

? ? ? 

This is a bad idea IMHO.
If you remove focus rect from radiobutton and checkbox, **how can the user see where the focus is**? He can not!

And why removing focus rect only for radiobutton and checkbox, but not for button, slider, list, tree, table, etc?
There are a lot of components that show focus rect. It makes no sense to remove it from one component, but not from others.


>... however it seems Windows does not draw focus rect for radiobutton at all ...

This is not true.

Windows 11 Explorer file properties:

![grafik](https://user-images.githubusercontent.com/5604048/230511043-e177fad2-f439-4f66-80d2-12124252a866.png)

Windows 11 System settings (the rounded rectangle is the focus indicator; it is hidden by default, but shown when pressing TAB key):

![grafik](https://user-images.githubusercontent.com/5604048/230511293-a4a3f76c-1ded-4f93-8218-c43a65b5655d.png)

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

PR Comment: https://git.openjdk.org/jdk/pull/13153#issuecomment-1499758791


From honkar at openjdk.org  Thu Apr  6 23:56:40 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Apr 2023 23:56:40 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due to
 wrong mouse position
Message-ID: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>

This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`.
As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event.

Following is the event log before and after fix.

**Before fix:**

1st mouse move
2nd mouse move
Frame-1 Mouse Event
Frame-2 Mouse Event
java.awt.Point[x=29,y=29]


**After fix:**

1st mouse move
2nd mouse move
Frame-1 Mouse Event
3rd mouse move
Frame-2 Mouse Event
java.awt.Point[x=50,y=50]


Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition.

The updated test fix is checked on multiple uiScales including fractional scales for windows platform.
CI testing works as expected on all platforms.

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

Commit messages:
 - GetMousePositionWithPopup test update

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

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


From prr at openjdk.org  Fri Apr  7 01:39:44 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 01:39:44 GMT
Subject: RFR: JDK-8305593: Add @spec tags in java.desktop
In-Reply-To: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
References: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
Message-ID: <orhhTOWmlvfH2R-T6Q1dSxWZYp8wjGUFG9st6I7QQGg=.30dfdb41-0d68-4ae3-93cb-43cdbf8c2061@github.com>

On Wed, 5 Apr 2023 17:29:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files

src/java.desktop/share/classes/java/awt/Desktop.java line 591:

> 589:      * subprocess
> 590:      * @spec https://www.rfc-editor.org/info/rfc2368
> 591:      *      RFC 2368: The mailto URL scheme

The javadoc above references ietf.org. This tag references rfc-editor.org. It seems odd to use two different URLs
in the same method specification for the same RFC. I would have thought the ietf one better to use .. although it should be updated to https

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 227:

> 225:      * @spec https://www.rfc-editor.org/info/rfc1951
> 226:      *      RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 227:      */

OK. So why are you preferring this rfc-editor.org site ?
Seems we should get that cleared up before I look further

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1160372976
PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1160373170


From prr at openjdk.org  Fri Apr  7 01:47:58 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 01:47:58 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v3]
In-Reply-To: <bLUsfHRG5yBfdkTbs-Vez207p2cYxUlFDakcAaXB1Hg=.0817ffbc-5013-4ba9-ba3a-acbcf85915c9@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <bLUsfHRG5yBfdkTbs-Vez207p2cYxUlFDakcAaXB1Hg=.0817ffbc-5013-4ba9-ba3a-acbcf85915c9@github.com>
Message-ID: <ibKyw4m_rkLGsfMvIz16cWrtBDSBSw4zbEbUFfEFCGg=.9485f7ad-29fe-4731-a7d5-5c191f4ac0e0@github.com>

On Thu, 6 Apr 2023 18:43:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright
>   Replaced a few more uses of os.name.

So if we want to get rid of all the getProperty (etc) calls and unify it then  the way I'd prefer to do this is via a single channel inside the desktop module.
So change everything to use that pre-existing sun.awt.OSInfo class.
Modifying that as necessary. Then that class can be the SINGLE place that has a direct dependency on this java.base internal and we can more easily drop it if required.
Meanwhile I also think there's a better than 50:50 chance someone will add new uses of System.getProperty .. whatever the solution is. So whack-a-mole-away.

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

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1499831355


From prr at openjdk.org  Fri Apr  7 02:12:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:12:53 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
Message-ID: <48dealGmfwU6m9dKdOEs-aiiVt5fconzd880Qu94Y8A=.e2e0f829-dde5-4109-a177-facbd3305237@github.com>

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

The single java.desktop change looks OK, so when anyone approves the rest that's implicitly approved.

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

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1375751794


From prr at openjdk.org  Fri Apr  7 02:17:49 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:17:49 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
Message-ID: <z_svjd9Cx0w4BBGsjikk7x9V4m6Onk-5XGlcTBHgh_Q=.a93567bd-4148-4bd3-9d73-c4be5fc5dd64@github.com>

On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. 
> 
> The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging:
> 
> 
> <jvmarg value="-Xdebug"/>
> <jvmarg value="-Xnoagent"/>
> <jvmarg value="-Djava.compiler=none"/>
> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
> 
> 
> They should instead just do:
> 
> 
> <jvmarg value="-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=${jpda.address}"/>
> 
> 
> Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout.
> 
> `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/`

No one has maintained these in a long time.
Did you manually verify all of these with a recent netbeans?

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

PR Review: https://git.openjdk.org/jdk/pull/13101#pullrequestreview-1375753764


From prr at openjdk.org  Fri Apr  7 02:19:46 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:19:46 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: <xJ41r0O1QBd_W0G3yMbfUZgYw9NNZUMj1NtZvs8T5O8=.d96bea63-03f2-481a-a152-1287f5214732@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
 <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
 <UmLA7WYiCTTB56uM33zYmqn3QSJQqMNRHr9w3LZ_rS0=.790af5e6-c700-44f5-a56c-2b916ceeaf2f@github.com>
 <xJ41r0O1QBd_W0G3yMbfUZgYw9NNZUMj1NtZvs8T5O8=.d96bea63-03f2-481a-a152-1287f5214732@github.com>
Message-ID: <o4JLoa3SUIExBkF10R22g1gUWsZTBVCaelFBIuetkXs=.838134db-e6df-44db-94d0-22f03ddf0efc@github.com>

On Mon, 27 Mar 2023 05:48:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Deleting the SwingApplet looks fine.

Ditto.

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

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1499858428


From prr at openjdk.org  Fri Apr  7 02:19:48 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:19:48 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: <OvTey4pnUCN2V2hJG46ugjabo25Lni9sSuo3QYemANI=.f6189e81-8175-478e-a3e5-3cf4d97494f1@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
 <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
 <fdnthrVE2CQP3Hq2uDd2ekTjE-YGJsDem1FD0S57QdY=.6c7bc44c-6e21-4422-b322-cd70627fb58e@github.com>
 <OvTey4pnUCN2V2hJG46ugjabo25Lni9sSuo3QYemANI=.f6189e81-8175-478e-a3e5-3cf4d97494f1@github.com>
Message-ID: <5YOnVc-YZvuwrUglCzO0JROT06q7TOC2nKKazUmk9hA=.2a1d8ba5-6e45-4bf4-bac4-5f35bb3317cd@github.com>

On Tue, 28 Mar 2023 08:37:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > These were demo/sample code in JDK 5.
> 
> @mrserb would you please confirm if your review approval applies to `SwingApplet` only or the whole PR? As it stands, it is not clear to me whether this PR is approved or not. Thanks!

I am pretty sure Alan was approving the whole lot of them.

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

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1499858579


From prr at openjdk.org  Fri Apr  7 02:22:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:22:45 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <Kj6uoZ_oGv1d2JqczqewQroCMQ9JWD8HRkepH9jmq9U=.758e1fa4-ff98-4a36-b05c-9e298178bcdd@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <ysFbtVtG2WDwak7IAICXp_DUltY6HoK6vz08qhaLocg=.4a6e6a1b-7416-4e5a-bc3a-8df4c1b842dd@github.com>
 <Kj6uoZ_oGv1d2JqczqewQroCMQ9JWD8HRkepH9jmq9U=.758e1fa4-ff98-4a36-b05c-9e298178bcdd@github.com>
Message-ID: <rewC4WntAuLkGWkH9EeCoVmcgxyL_XLO4LFxBrmpubo=.8e7afb34-fb24-4022-b31b-ed666d85347d@github.com>

On Wed, 22 Mar 2023 14:47:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> @prrace Do you know any news about possibility to bundle some free/open fonts like https://dejavu-fonts.github.io/License.html?

I think it quite unlikely it will get traction.
Regardless of licensing 3rd party *anything* in JDK is a maintenance task.

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1499859791


From prr at openjdk.org  Fri Apr  7 02:35:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 02:35:45 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <V2cMYDzSZ_9xs0ku2TI2jaqpYRlS7L26CFjex9Fm0LA=.98392083-3945-4bb8-999b-e5527e6fcf46@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <1Sp7LyzwGBYBj0Ebplp8dQsNgMK76w9dy3ZwogjR7L4=.0b260e5f-0c78-4862-b1eb-9ec56671c127@github.com>
 <V2cMYDzSZ_9xs0ku2TI2jaqpYRlS7L26CFjex9Fm0LA=.98392083-3945-4bb8-999b-e5527e6fcf46@github.com>
Message-ID: <fFNR-oVMM-Bv-RIG2m8jOrBFa3iz14e3rGozw4dSkoo=.7fbc21ec-eee1-48a0-9ae4-17f147b7770d@github.com>

On Thu, 16 Mar 2023 09:15:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 1256:
>> 
>>> 1254:         if (head == null) {
>>> 1255:             throw new RuntimeException("Fontconfig head is null, check your fonts or fonts configuration");
>>> 1256:         }
>> 
>> should it be unspecified RuntimeException or InternalError?
>
> Hi Sergey, when looking through  the java.desktop codebase I see both used quite a lot,  so probably both would be okay.

I interpret InternalError as meaning something wrong with the JDK itself, not something in the environment causing
a problem, so RTE would be fine here.

But this NPE is coming from a field (head) that is initialised by code that reads a binary font configuration file.
Are you quite sure you've diagnosed the root of the problem ? Or that this message is really in the right place ?

What does -Dsun.java2d.debugfonts=true reveal ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13045#discussion_r1160391507


From prr at openjdk.org  Fri Apr  7 04:39:49 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 04:39:49 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
Message-ID: <wWsiTxCLUc_3UV-XNsP5hCwwMclNzaqMjrxFucP2ssw=.a1bbc853-5e8c-4640-bd36-f5067e217b4c@github.com>

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.
> 
> Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

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

> 100: 
> 101:     [self stopDisplayLink];
> 102: }

I'm assuming this is something we should have done already to save wasted work ?
i.e if the screen is asleep, we don't need to be connected to it and updating windows ?
But I see the same stopDisplayLink call in the wakeup code ... any issues with the extra call there ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13375#discussion_r1160429562


From psadhukhan at openjdk.org  Fri Apr  7 04:47:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Apr 2023 04:47:44 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only
 icon [v3]
In-Reply-To: <5biHFP0PwllKWV_Wb7HOMK_6DSwI_UB2bhdZldd5D7w=.0e4f2114-28fe-4b8f-8b85-2f949f178cfa@github.com>
References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>
 <5biHFP0PwllKWV_Wb7HOMK_6DSwI_UB2bhdZldd5D7w=.0e4f2114-28fe-4b8f-8b85-2f949f178cfa@github.com>
Message-ID: <-RIomwGD4d1XrWbmJeMnva8f0bI9GIYYeuj9wjwHhNw=.d8136c58-4dbb-4cc9-b594-aed4d3cd19e2@github.com>

On Thu, 6 Apr 2023 07:01:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text
>> 
>> This is what can be seen in windows system setting
>> 
>> ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)
>> 
>> and notepad
>> 
>> ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)
>> 
>> We have currently
>> 
>> ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)
>> 
>> 
>> and after fix
>> 
>> ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test added

OK. I see the focusrect when TAB is pressed and it makes sense to show the focusrect to indicate where's the focus..I got misled by default no focusrect on the system settings.
I guess back to the original bug, then we have to draw the focus for only icons (without text) too but I couldn't find any system settings with that, how they behave..Did you happen to see any such settings?

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

PR Comment: https://git.openjdk.org/jdk/pull/13153#issuecomment-1499929281


From prr at openjdk.org  Fri Apr  7 04:50:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 04:50:45 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due
 to wrong mouse position
In-Reply-To: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
References: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
Message-ID: <WvJ5FspO3nNrR2AH2bMNvNDIi7mzmh72ZLcZOF2GPxo=.8a250221-da6b-4364-829f-b2063d1a2084@github.com>

On Thu, 6 Apr 2023 23:50:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`.
> As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event.
> 
> Following is the event log before and after fix.
> 
> **Before fix:**
> 
> 1st mouse move
> 2nd mouse move
> Frame-1 Mouse Event
> Frame-2 Mouse Event
> java.awt.Point[x=29,y=29]
> 
> 
> **After fix:**
> 
> 1st mouse move
> 2nd mouse move
> Frame-1 Mouse Event
> 3rd mouse move
> Frame-2 Mouse Event
> java.awt.Point[x=50,y=50]
> 
> 
> Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition.
> 
> The updated test fix is checked on multiple uiScales including fractional scales for windows platform.
> CI testing works as expected on all platforms.

test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java line 113:

> 111:                 frame2.setBounds(120, 120, 120, 120);
> 112:                 frame2.setVisible(true);
> 113:             }

So are you confident the requested location will be honoured ?
I seem to remember a test framework fix in which you had to work quite hard to be sure of the real location.
And the implied "170-120=50" might be clearer if we had variables not just literal numbers ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13380#discussion_r1160432986


From prr at openjdk.org  Fri Apr  7 04:57:46 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 04:57:46 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
References: <vWLelUuqotvZkB-yFaqZun6U-9DAdbq2OCIguDzE0Gs=.a02661cb-8cff-4633-ab26-cf76f7f3529f@github.com>
Message-ID: <L9SEoR7nmNrGXZbZwtxp_oQCQ6ASq8VednuA7cDbhxA=.1f8f31a2-07af-47a8-b06e-0967dc5d5f9d@github.com>

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

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

Sorry, but this proposed change which comes with no test seems completely not worth it for
whatever benefit there might be (none that I can see). Please withdraw it. 

Also go to https://openjdk.org/groups/client-libs/ and read the section
"Guidelines on what kinds of changes we would like to see - or not see"

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13149#pullrequestreview-1375821717


From prr at openjdk.org  Fri Apr  7 05:29:46 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:29:46 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
Message-ID: <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>

On Thu, 16 Mar 2023 08:33:35 GMT, ??? <duke at openjdk.org> wrote:

>> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea
>> Type: Bug
>> Component: client-libs
>> Sub-Component: java.awt:i18n
>> Affected Version: 8,9,15,16
>> Priority: P3
>> Status: Open
>> Resolution: Unresolved
>> OS: linux
>> CPU: x86_64
>
> ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea

Provide a complete description and explanation of what you are doing, and why it is is the correct solution and
what testing you have done and what testing you have NOT done and what the risks are - including to apps not using an IM
In other words, whilst you (I hope) understand how you decided this was the right solution (and weren't just copying
what someone proposed in the bug report), reviewers would like to hear from YOU. Not just see code.
So spend time writing it up properly and clearly.

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

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


From prr at openjdk.org  Fri Apr  7 05:31:44 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:31:44 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
Message-ID: <YytRchf9njQPjj5BpN7XCCsT499wkMa_wAAa-cobTX8=.8430de1d-2bd3-4688-9a04-e8f4ca7e2e2d@github.com>

On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. 
> 
> The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging:
> 
> 
> <jvmarg value="-Xdebug"/>
> <jvmarg value="-Xnoagent"/>
> <jvmarg value="-Djava.compiler=none"/>
> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
> 
> 
> They should instead just do:
> 
> 
> <jvmarg value="-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=${jpda.address}"/>
> 
> 
> Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout.
> 
> `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/`

I'd be just as happy if you deleted all of these like you propose  in 8304501 ..

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1499950990


From prr at openjdk.org  Fri Apr  7 05:35:43 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:35:43 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <Ja6sWzpR8Jh25NfDzzc5vlXOzUMGFVoPNXcTbUllxDg=.f1590064-eff0-4f85-ace8-a31c109f2292@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
 <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
 <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>
 <Ja6sWzpR8Jh25NfDzzc5vlXOzUMGFVoPNXcTbUllxDg=.f1590064-eff0-4f85-ace8-a31c109f2292@github.com>
Message-ID: <w3LN5bOoM91IO3eTA9meqPabHWfLmrN3sOVc4jdEV44=.654095c3-7b52-4f98-aa01-861491059f36@github.com>

On Wed, 5 Apr 2023 09:08:42 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> > I don't see why we need this in mainline. I'd prefer to not have it unless we need it.
> 
> I believe it is better to have all JDK branches in sync if it's possible. This change is harmless and as Sergey mentioned it would simplify backport process.

We'll get it anyway when we upgrade .. that's why we only apply changes that are accepted upstream.
And if we upgrade to a version that pre-dates it then we'll have to manually re-apply it for no reason.
It is just unnecessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1499953229


From prr at openjdk.org  Fri Apr  7 05:39:42 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:39:42 GMT
Subject: RFR: 4825182: DefaultBoundedRangeModel.setMinimum() changes extent
 unnecessarily
In-Reply-To: <zHp80OVLg5z1_ctDda9Zc8ZXMgVwaBP3xfKla_B91so=.06c9528e-5f79-4bd4-bb00-c0f36f10a94e@github.com>
References: <zHp80OVLg5z1_ctDda9Zc8ZXMgVwaBP3xfKla_B91so=.06c9528e-5f79-4bd4-bb00-c0f36f10a94e@github.com>
Message-ID: <QvZJMtcTPahGTifYYP4n64a87kVCN1fFWjH3ejc-Y-s=.e9e13974-88d1-4a7a-bc06-c4a312443943@github.com>

On Thu, 6 Apr 2023 14:15:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [DefaultBoundedRangeModel spec](https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/javax/swing/DefaultBoundedRangeModel.html#%3Cinit%3E(int,int,int,int))
> set maximum, minimun., extent as per the constraint "min <= value <= value+extent <= max"
> Now, when DefaultBoundedRangeModel.setMinimum() is called with same negative "value" then because of the integer overflow in `setMinimum` method, it causes the `extent `to become 0.
> 
> Fix the integer overflow and make sure the extent is not changed unncessarily.
> All jtreg/jck tests are ok.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13374#pullrequestreview-1375841213


From prr at openjdk.org  Fri Apr  7 05:47:44 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:47:44 GMT
Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility
In-Reply-To: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
References: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
Message-ID: <GWdSXfpYMDYdlfLrSkcA2IT4kj2Tfyd9cAYDgao-osU=.9a477680-0ee9-4cd8-92a6-c275a00905b4@github.com>

On Wed, 8 Mar 2023 18:20:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the jdk.accessibility module.
> 
> Thanks,
> Xuelei

Looks reasonable .. how did you test it ? Please do NOT tell me its obvious and safe.
@azuev-java please review.

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

PR Review: https://git.openjdk.org/jdk/pull/12929#pullrequestreview-1375844915


From prr at openjdk.org  Fri Apr  7 05:56:43 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 05:56:43 GMT
Subject: RFR: 8305666: Add system property for fair AWT lock
In-Reply-To: <FVKOMEGLy18sellibnEH5l5CMHTbXp4fSN3ccgifyok=.9a2af404-338d-4c85-b473-0ee94cd2f423@github.com>
References: <FVKOMEGLy18sellibnEH5l5CMHTbXp4fSN3ccgifyok=.9a2af404-338d-4c85-b473-0ee94cd2f423@github.com>
Message-ID: <qlHTeAQGXyLn0NQZ4j_xiZn8AkzjeMvQnc0mApKDUgo=.77a64668-c71d-42f8-9ff1-b352e5ffeac3@github.com>

On Wed, 5 Apr 2023 15:54:53 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> There are freezes reported on some Linux configurations which are believed to may be caused by the toolkit thread quickly reacquiring AWT_LOCK while polling for events, which starves EDT waiting on that lock.
> Adding new `awt.lock.fair` system property can help diagnosing such issues.

fair :-) enough/

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13356#pullrequestreview-1375849655


From stuefe at openjdk.org  Fri Apr  7 06:05:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 06:05:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
Message-ID: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>

On Thu, 6 Apr 2023 21:17:25 GMT, Glavo <duke at openjdk.org> wrote:

>> The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. 
>> 
>> What did you use as the example that would not compile on the other architecture?
>> Did you make the other changes to the build that would be needed for a new architecture?
>
>> What did you use as the example that would not compile on the other architecture? 
> 
> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
> 
> I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.
> 
>> Did you make the other changes to the build that would be needed for a new architecture?
> 
> I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 
> 
> According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?
> 
> For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.

@Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160459041


From duke at openjdk.org  Fri Apr  7 06:28:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 06:28:46 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: <5YOnVc-YZvuwrUglCzO0JROT06q7TOC2nKKazUmk9hA=.2a1d8ba5-6e45-4bf4-bac4-5f35bb3317cd@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
 <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
 <fdnthrVE2CQP3Hq2uDd2ekTjE-YGJsDem1FD0S57QdY=.6c7bc44c-6e21-4422-b322-cd70627fb58e@github.com>
 <OvTey4pnUCN2V2hJG46ugjabo25Lni9sSuo3QYemANI=.f6189e81-8175-478e-a3e5-3cf4d97494f1@github.com>
 <5YOnVc-YZvuwrUglCzO0JROT06q7TOC2nKKazUmk9hA=.2a1d8ba5-6e45-4bf4-bac4-5f35bb3317cd@github.com>
Message-ID: <Q0MtfaW7buMOFiIiB4GwgGiOa4wfDetNY4qicqsf2bs=.9c5d5be8-7a4d-4ca5-ad7f-6411d9021762@github.com>

On Fri, 7 Apr 2023 02:17:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I am pretty sure Alan was approving the whole lot of them.

Phil,

Thanks, but it seems Alan did not actually approve anything, he simply left an infomational note.

We still only have the approval from Sergey, and it is still not clear what he approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1499983142


From duke at openjdk.org  Fri Apr  7 06:31:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 06:31:45 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <z_svjd9Cx0w4BBGsjikk7x9V4m6Onk-5XGlcTBHgh_Q=.a93567bd-4148-4bd3-9d73-c4be5fc5dd64@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
 <z_svjd9Cx0w4BBGsjikk7x9V4m6Onk-5XGlcTBHgh_Q=.a93567bd-4148-4bd3-9d73-c4be5fc5dd64@github.com>
Message-ID: <ltQVj0MpPuVrt30VAhGXb3jRlru6wYy4G1AAG2-nZOA=.212bc2a2-53f2-46b8-ae70-31cccb817832@github.com>

On Fri, 7 Apr 2023 02:14:40 GMT, Phil Race <prr at openjdk.org> wrote:

> No one has maintained these in a long time. Did you manually verify all of these with a recent netbeans?

Yes, I downloaded the most recent Netbeans from Apache and verified I could run the debugging tasks. I'm no Netbeans expert, but I feel convinced that I tested it and that it worked. It did fail when I tried with some invalid options.

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1499984401


From stuefe at openjdk.org  Fri Apr  7 06:35:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 06:35:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
Message-ID: <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>

On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > What about PPC (big endian)? Used on AIX?
> 
> I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`.
> 
> > On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests).
> 
> For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates.
> 
> For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`.

What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?

os.arch for AIX is "ppc64". It is even used in our codebase, see https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java#L51

> > Another question, how does this work with Zero?
> 
> Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture.

Sorry, I was not clear. Zero is the vehicle to get the OpenJDK to build and run on hardware we don't directly support. It is not only used in bootstrapping but finds surprisingly broad use, e.g., for Debian wich itself supports a wide range of platforms and tries to provide java on all of them. 

For these JDKs, IIUC, os.arch would have the value of the target architecture ("PA-RISC", "mips", "alpha" etc). These platforms would be at a disadvantage now, as @Glavo pointed out: since OPENJDK_TARGET_CPU is fed from uname: https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/make/RunTestsPrebuilt.gmk#L182, they will have a name that expands to an enum that is not compilable. So all of these platforms will get build errors.

I understand your intention to keep this patch simple, and that you want to limit the enum value. I also like enums. I wonder whether it would be possible to have an enum value "other" and map unknown architectures to that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499986742


From duke at openjdk.org  Fri Apr  7 06:46:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 06:46:45 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <YytRchf9njQPjj5BpN7XCCsT499wkMa_wAAa-cobTX8=.8430de1d-2bd3-4688-9a04-e8f4ca7e2e2d@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
 <YytRchf9njQPjj5BpN7XCCsT499wkMa_wAAa-cobTX8=.8430de1d-2bd3-4688-9a04-e8f4ca7e2e2d@github.com>
Message-ID: <W54wHJjYdBwtN3pQjI6gHsP4p2mD20lVUgAjsRA29mA=.0d1d6093-43bb-434e-abf4-c2fa209ead80@github.com>

On Fri, 7 Apr 2023 05:28:27 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd be just as happy if you deleted all of these like you propose in 8304501 ..

Would this require some broader discussion and a concenus?

Or could we simply withdraw this PR and instead broaden the scope of #13098 to remove all Netbeans projects?

If these are just dead files with no current or future use, them perhaps it is better to let them go.

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1499993141


From xuelei at openjdk.org  Fri Apr  7 07:06:47 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 7 Apr 2023 07:06:47 GMT
Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility
In-Reply-To: <GWdSXfpYMDYdlfLrSkcA2IT4kj2Tfyd9cAYDgao-osU=.9a477680-0ee9-4cd8-92a6-c275a00905b4@github.com>
References: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
 <GWdSXfpYMDYdlfLrSkcA2IT4kj2Tfyd9cAYDgao-osU=.9a477680-0ee9-4cd8-92a6-c275a00905b4@github.com>
Message-ID: <UJXjRpHOgKVTLYIAEGBRjqCIu87QwsiE_SK9jxsEZak=.5ba662d3-032e-453c-95cb-d2f802e418ed@github.com>

On Fri, 7 Apr 2023 05:45:05 GMT, Phil Race <prr at openjdk.org> wrote:

> how did you test it ?
The existing regression tests will be used for the testing.  I will ask for a Mach5 testing if approved.  Hopefully, the current regression test coverage is sufficient.  I have no plan to add new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/12929#issuecomment-1500005670


From alanb at openjdk.org  Fri Apr  7 07:34:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 07:34:46 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: <Q0MtfaW7buMOFiIiB4GwgGiOa4wfDetNY4qicqsf2bs=.9c5d5be8-7a4d-4ca5-ad7f-6411d9021762@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
 <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
 <fdnthrVE2CQP3Hq2uDd2ekTjE-YGJsDem1FD0S57QdY=.6c7bc44c-6e21-4422-b322-cd70627fb58e@github.com>
 <OvTey4pnUCN2V2hJG46ugjabo25Lni9sSuo3QYemANI=.f6189e81-8175-478e-a3e5-3cf4d97494f1@github.com>
 <5YOnVc-YZvuwrUglCzO0JROT06q7TOC2nKKazUmk9hA=.2a1d8ba5-6e45-4bf4-bac4-5f35bb3317cd@github.com>
 <Q0MtfaW7buMOFiIiB4GwgGiOa4wfDetNY4qicqsf2bs=.9c5d5be8-7a4d-4ca5-ad7f-6411d9021762@github.com>
Message-ID: <VeIh09KdWS-hu03ds_iAlSM3Ite5LNKOOIi3tV72X4E=.d74b2417-d2c6-4efd-985e-2e9709af0ed7@github.com>

On Fri, 7 Apr 2023 06:26:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Thanks, but it seems Alan did not actually approve anything, he simply left an infomational note.
> 
> We still only have the approval from Sergey, and it is still not clear what he approved.

Right, I just added a note as I remember these demos from JDK 5. I think you are okay to integrate this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1500025220


From alanb at openjdk.org  Fri Apr  7 07:45:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 07:45:55 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
Message-ID: <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>

On Fri, 7 Apr 2023 06:33:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> 
> os.arch for AIX is "ppc64".

So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500032422


From duke at openjdk.org  Fri Apr  7 07:54:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 07:54:45 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <W54wHJjYdBwtN3pQjI6gHsP4p2mD20lVUgAjsRA29mA=.0d1d6093-43bb-434e-abf4-c2fa209ead80@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
 <YytRchf9njQPjj5BpN7XCCsT499wkMa_wAAa-cobTX8=.8430de1d-2bd3-4688-9a04-e8f4ca7e2e2d@github.com>
 <W54wHJjYdBwtN3pQjI6gHsP4p2mD20lVUgAjsRA29mA=.0d1d6093-43bb-434e-abf4-c2fa209ead80@github.com>
Message-ID: <5sGKyqAt7tGswUbynrcjGJz0ST5FQ3wLLGTc2Vh7d9E=.9a71e288-1128-4cfb-a456-17e87dffdd57@github.com>

On Fri, 7 Apr 2023 06:44:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Or could we simply withdraw this PR and instead broaden the scope of #13098 to remove all Netbeans projects?

As #13098 is now  integrated, it would now make more sense to create a seperate PR for a removal of these projects.

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1500039019


From duke at openjdk.org  Fri Apr  7 08:47:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 08:47:45 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
Message-ID: <6tJzMjDTSF-a2z1_12RGC7HWmt-JUiq21nagM50C57M=.09e10d10-3d7c-4922-9ccd-91edf73faf15@github.com>

On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. 
> 
> The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging:
> 
> 
> <jvmarg value="-Xdebug"/>
> <jvmarg value="-Xnoagent"/>
> <jvmarg value="-Djava.compiler=none"/>
> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
> 
> 
> They should instead just do:
> 
> 
> <jvmarg value="-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=${jpda.address}"/>
> 
> 
> Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout.
> 
> `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/`

After thinking this through I think I would prefer to go ahead with fixing this in this PR, then eventually we can do another PR for a deletion.

@prrace would you consider approving this PR as-is?

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1500079954


From duke at openjdk.org  Fri Apr  7 09:10:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 09:10:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <UNx5kajHm8bXnl8XGs3I5xKHGodIVD6yQJ-DxoHcgdw=.2592f28c-a962-41c3-a9ae-2e359a64d516@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 38:

> 36: 
> 37: import jdk.internal.util.Architecture;
> 38: 

Not?removed in?[commit?`ab084c2` or?`52ca4a7`](https://github.com/openjdk/jdk/pull/13357/files/105ce60528f7ef84e31ac3db64e6eb63860b4a70..52ca4a70fc3de9e285964f9545ea8cd54e2d9924):
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160563815


From stuefe at openjdk.org  Fri Apr  7 09:30:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 09:30:48 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
 <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
Message-ID: <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>

On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
> 
> So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.

Yes, precisely.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500115177


From duke at openjdk.org  Fri Apr  7 10:06:09 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:06:09 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <z8EuL6vvnVdCVsR68uEbPMFxyCabYlTLxrgh-xRzEj0=.619c4a4b-1bb0-44d5-88cf-50b801c4049d@github.com>
 <nc_w6DjozGQhwsm1-vZr-xgc0tV1HPheuWyA0QAo0CA=.f4b271b0-b08e-47a1-8353-12fe26707d8a@github.com>
 <yyHezPsdOG8L8tnGGSIR1NfKkmLGvG2fnlGt1TbdWZ4=.0f7ad875-d8c5-4d31-9da4-4fe70eaacdda@github.com>
 <RSr_REqgL5AEiDIRHJmvhlDoHBV5XclUTFwt9ALIOUc=.b9986985-0d6f-4daa-ab65-69acb188a52f@github.com>
 <xPongRDOBHRh5URyYf3cFcGGh2gMdwvCPbsnCdVuQ3Y=.23496da3-d68d-409e-bea1-53a1ec7f66b0@github.com>
Message-ID: <HqhOSr8ECbP9BRzm52aeWixWz4gCk7GZYLJt-oyGWEU=.396c01dd-f83c-4f91-92eb-afcb6b159325@github.com>

On Fri, 7 Apr 2023 09:28:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that?
> > > os.arch for AIX is "ppc64".
> > 
> > 
> > So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le.
> 
> Yes, precisely.

In?that?case, they?should probably be?called `PPC64BE` and?`PPC64LE`?to?disambiguate between?them.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500140904


From ngubarkov at openjdk.org  Fri Apr  7 10:09:54 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Fri, 7 Apr 2023 10:09:54 GMT
Subject: Integrated: 8305666: Add system property for fair AWT lock
In-Reply-To: <FVKOMEGLy18sellibnEH5l5CMHTbXp4fSN3ccgifyok=.9a2af404-338d-4c85-b473-0ee94cd2f423@github.com>
References: <FVKOMEGLy18sellibnEH5l5CMHTbXp4fSN3ccgifyok=.9a2af404-338d-4c85-b473-0ee94cd2f423@github.com>
Message-ID: <sIIXdiA96HO7xXRoLJdpdMhw9SvsNvWfQ3_8TSVlfQk=.b5281e70-f5ad-4d7d-b99b-cd9ef8863510@github.com>

On Wed, 5 Apr 2023 15:54:53 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> There are freezes reported on some Linux configurations which are believed to may be caused by the toolkit thread quickly reacquiring AWT_LOCK while polling for events, which starves EDT waiting on that lock.
> Adding new `awt.lock.fair` system property can help diagnosing such issues.

This pull request has now been integrated.

Changeset: dc81603c
Author:    Nikita Gubarkov <ngubarkov at openjdk.org>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc81603cbf223c3ac6b41396d1998a07524a0d54
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8305666: Add system property for fair AWT lock

Reviewed-by: prr

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

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


From stuefe at openjdk.org  Fri Apr  7 10:26:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 10:26:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
Message-ID: <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>

On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded qualified export from java.base to jdk.attach

src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:

> 39:     AARCH64(),
> 40:     RISCV64(),
> 41:     S390(),

Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160610072


From jpai at openjdk.org  Fri Apr  7 10:55:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 10:55:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
Message-ID: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>

On Fri, 7 Apr 2023 10:24:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
> 
>> 39:     AARCH64(),
>> 40:     RISCV64(),
>> 41:     S390(),
> 
> Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.

Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160623813


From stuefe at openjdk.org  Fri Apr  7 11:24:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Apr 2023 11:24:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
Message-ID: <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>

On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>> 
>>> 39:     AARCH64(),
>>> 40:     RISCV64(),
>>> 41:     S390(),
>> 
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years.
>
> Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942

Okay, Lutz is the expert here. Sorry for the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160637280


From kcr at openjdk.org  Fri Apr  7 11:54:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Apr 2023 11:54:45 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
Message-ID: <HCFK6fw1PlfI4ZQpfzK6efD9Ckt7iI_m78eleRS47_w=.ecf3fca6-f754-4844-9a6b-d67502ccceff@github.com>

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.
> 
> Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

Looks good to me. I tested this on an M1 MacBook. The test program attached to the bug fails without your fix and passes with your fix.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/13375#pullrequestreview-1376126786


From aghaisas at openjdk.org  Fri Apr  7 11:54:49 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 7 Apr 2023 11:54:49 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <wWsiTxCLUc_3UV-XNsP5hCwwMclNzaqMjrxFucP2ssw=.a1bbc853-5e8c-4640-bd36-f5067e217b4c@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
 <wWsiTxCLUc_3UV-XNsP5hCwwMclNzaqMjrxFucP2ssw=.a1bbc853-5e8c-4640-bd36-f5067e217b4c@github.com>
Message-ID: <ZmMORQ8-Pc2hgdADaIAA15wNv-f4jY5qzzBVhY2Gomg=.7052f4ff-d625-4adb-8306-d1988d77b1e7@github.com>

On Fri, 7 Apr 2023 04:36:39 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm assuming this is something we should have done already to save wasted work ?
i.e if the screen is asleep, we don't need to be connected to it and updating windows ?

We start the DisplayLink from Metal RenderQueue whenever there is something to be painted from back buffer to the window buffer. Once the window buffer is painted in a DisplayLink callback, we stop the DisplayLink. 
We were not stopping the DisplayLink on screen sleep event. This is what this PR adds.

> But I see the same stopDisplayLink call in the wakeup code ... any issues with the extra call there ?

I have added that call as a sanity before releasing the Displaylink. It will be a no-op if DisplayLink is not running.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13375#discussion_r1160649923


From lucy at openjdk.org  Fri Apr  7 12:08:49 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 7 Apr 2023 12:08:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
 <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
Message-ID: <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>

On Fri, 7 Apr 2023 11:21:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942
>
> Okay, Lutz is the expert here. Sorry for the noise.

Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore).

s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160657249


From rriggs at openjdk.org  Fri Apr  7 14:43:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:43:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com>
Message-ID: <ZPU30OWEffB1RmzJKMcO52XNC4f7L-DZtzvd2I1mFk4=.3aff1b1c-1131-4364-89fe-a8081adb1f0a@github.com>

On Thu, 6 Apr 2023 22:44:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded qualified export from java.base to jdk.attach
>
> src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169:
> 
>> 167:         // Load the appropriate DLLs
>> 168:         boolean is32on64 = false;
>> 169:         if (Architecture.isX86()) {
> 
> This would be another coupling of java.desktop into java.base internals and I don't think it worth it.
> Particularly because this check is obsolete !
> It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit.
> We don't even have  the file it is looking for in the build - even if someone did a 32 bit build.
> Instead of making this change a bug should be filed to remove this code.

Reverting; filed [8305745](https://bugs.openjdk.org/browse/JDK-8305745)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160748988


From avu at openjdk.org  Fri Apr  7 15:50:43 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 7 Apr 2023 15:50:43 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
Message-ID: <wwtS3TauBrXtZPi_BHMSWVlwbpwV1pHsDb_0aaD1jLU=.a2144bdc-07fc-4c5d-91a9-dde2c6219bcf@github.com>

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.
> 
> Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

Looks good for me

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13375#pullrequestreview-1376333938


From honkar at openjdk.org  Fri Apr  7 16:27:44 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Apr 2023 16:27:44 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due
 to wrong mouse position
In-Reply-To: <WvJ5FspO3nNrR2AH2bMNvNDIi7mzmh72ZLcZOF2GPxo=.8a250221-da6b-4364-829f-b2063d1a2084@github.com>
References: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
 <WvJ5FspO3nNrR2AH2bMNvNDIi7mzmh72ZLcZOF2GPxo=.8a250221-da6b-4364-829f-b2063d1a2084@github.com>
Message-ID: <6dBmWURgjX39RK_nDGhfdelPXc8b1bEkyHM58GEYCsc=.416f15de-2e23-4c1e-acab-3c30eb7de4e4@github.com>

On Fri, 7 Apr 2023 04:47:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`.
>> As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event.
>> 
>> Following is the event log before and after fix.
>> 
>> **Before fix:**
>> 
>> 1st mouse move
>> 2nd mouse move
>> Frame-1 Mouse Event
>> Frame-2 Mouse Event
>> java.awt.Point[x=29,y=29]
>> 
>> 
>> **After fix:**
>> 
>> 1st mouse move
>> 2nd mouse move
>> Frame-1 Mouse Event
>> 3rd mouse move
>> Frame-2 Mouse Event
>> java.awt.Point[x=50,y=50]
>> 
>> 
>> Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition.
>> 
>> The updated test fix is checked on multiple uiScales including fractional scales for windows platform.
>> CI testing works as expected on all platforms.
>
> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java line 113:
> 
>> 111:                 frame2.setBounds(120, 120, 120, 120);
>> 112:                 frame2.setVisible(true);
>> 113:             }
> 
> So are you confident the requested location will be honoured ?
> I seem to remember a test framework fix in which you had to work quite hard to be sure of the real location.
> And the implied "170-120=50" might be clearer if we had variables not just literal numbers ?

@prrace I agree, adding PassFailJFrame's [syncLocationToWindowManager()](https://github.com/openjdk/jdk/blob/a8871f5d26e5cb42c031c7b736ec30b1b147a2bc/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L343) to this test will make it more robust.
I'll change the literals to variables to make the context clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13380#discussion_r1160814524


From dnguyen at openjdk.org  Fri Apr  7 17:06:47 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 7 Apr 2023 17:06:47 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v4]
In-Reply-To: <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
Message-ID: <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>

On Tue, 21 Mar 2023 21:07:42 GMT, Jeremy <duke at openjdk.org> wrote:

>> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
>> 
>> In short:
>> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
>> 
>> I left more detailed notes here about the proposed resolution:
>> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
>> 
>> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303950: adding unit test for legacy window behavior
>   
>   This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
>   
>   This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
>   
>   In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.

src/java.desktop/share/classes/java/awt/Window.java line 3953:

> 3951:                 if (gg instanceof Graphics2D) {
> 3952:                     gg.setColor(getBackground());
> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));

Why was the import for SunHints added if the only edit to this file was adding a space?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160837035


From prr at openjdk.org  Fri Apr  7 17:06:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 17:06:45 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
Message-ID: <bXcfUYikTBwmb4U-cQoc18uWxg8v90cyNdWGfIUt7OY=.7e8d217e-3267-4483-8997-c6f99fac86c7@github.com>

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.
> 
> Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13375#pullrequestreview-1376399595


From prr at openjdk.org  Fri Apr  7 17:06:48 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 17:06:48 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <ZmMORQ8-Pc2hgdADaIAA15wNv-f4jY5qzzBVhY2Gomg=.7052f4ff-d625-4adb-8306-d1988d77b1e7@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
 <wWsiTxCLUc_3UV-XNsP5hCwwMclNzaqMjrxFucP2ssw=.a1bbc853-5e8c-4640-bd36-f5067e217b4c@github.com>
 <ZmMORQ8-Pc2hgdADaIAA15wNv-f4jY5qzzBVhY2Gomg=.7052f4ff-d625-4adb-8306-d1988d77b1e7@github.com>
Message-ID: <MERf_TeI_kJx52bPPhSnY9YI0JFJejp9s2Or9Z382FY=.4716665c-2035-4a93-a041-0916b2285cfc@github.com>

On Fri, 7 Apr 2023 11:49:50 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 102:
>> 
>>> 100: 
>>> 101:     [self stopDisplayLink];
>>> 102: }
>> 
>> I'm assuming this is something we should have done already to save wasted work ?
>> i.e if the screen is asleep, we don't need to be connected to it and updating windows ?
>> But I see the same stopDisplayLink call in the wakeup code ... any issues with the extra call there ?
>
>> I'm assuming this is something we should have done already to save wasted work ?
> i.e if the screen is asleep, we don't need to be connected to it and updating windows ?
> 
> We start the DisplayLink from Metal RenderQueue whenever there is something to be painted from back buffer to the window buffer. Once the window buffer is painted in a DisplayLink callback, we stop the DisplayLink. 
> We were not stopping the DisplayLink on screen sleep event. This is what this PR adds.
> 
>> But I see the same stopDisplayLink call in the wakeup code ... any issues with the extra call there ?
> 
> I have added that call as a sanity before releasing the Displaylink. It will be a no-op if DisplayLink is not running.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13375#discussion_r1160837063


From javalists at cbfiddle.com  Fri Apr  7 17:15:05 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 7 Apr 2023 10:15:05 -0700
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering
In-Reply-To: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
Message-ID: <1485DC72-613E-4984-85C8-9D12A99C8A49@cbfiddle.com>

When I added support for translucent windows to VAqua, I used a different solution: I ?tricked? the AWT Window into
accepting a transparent (alpha = 0) background color. I?m not sure if this is better or worse than your idea of suppressing the
painting of the background, but it does raise the issue of why AWT Windows insist on the background color being
opaque. Would something break if that restriction were removed? Using a transparent background color does not seem
to cause any problems on macOS and it seems like a natural way for a developer to indicate the desire to have
a window with a transparent or translucent background.



> On Mar 27, 2023, at 2:52 PM, Jeremy <duke at openjdk.org> wrote:
> 
> The original write-up contains two complaints:
> 1. The window is opaque, so pixels that should be transparent are black.
> 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).
> 
> I recommend splitting this up into separate tickets.
> 
> This PR addresses the first (probably most offensive) issue: the window is now transparent.
> 
> I experimented with a change that resolves the second issue (image resolution) here:
> https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002
> 
> ... that works, but IMO that looks riskier and should be part of a separate discussion.
> 
> I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.
> 
> -------------
> 
> Commit messages:
> - 8303904: fixing compiler `cannot find symbol` errors
> - 8303904: cleaning up comment
> - 8303904: apply same solution to other GraphicsConfigurations
> - 8303904: resolve failing bug8308904_OGL test on Mac
> - 8303904: adding failing unit test for OpenGL on Mac
> - 8303904: updating instruction text to reflect narrowed focus of this branch
> - 8303904: rolling back prev createAcceleratedImage commit
> - 8303904: change createAcceleratedImage to return a potentially high-res image
> - 8303904: use Transparency.TRANSLUCENT for non-opaque windows
> - 8303904: Add failing unit test
> - ... and 4 more: https://git.openjdk.org/jdk/compare/98a7a60f...4284d4cd
> 
> Changes: https://git.openjdk.org/jdk/pull/13196/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8303904
>  Stats: 225 lines in 7 files changed: 220 ins; 0 del; 5 mod
>  Patch: https://git.openjdk.org/jdk/pull/13196.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196
> 
> PR: https://git.openjdk.org/jdk/pull/13196
> 



From prr at openjdk.org  Fri Apr  7 17:18:44 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 17:18:44 GMT
Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility
In-Reply-To: <UJXjRpHOgKVTLYIAEGBRjqCIu87QwsiE_SK9jxsEZak=.5ba662d3-032e-453c-95cb-d2f802e418ed@github.com>
References: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
 <GWdSXfpYMDYdlfLrSkcA2IT4kj2Tfyd9cAYDgao-osU=.9a477680-0ee9-4cd8-92a6-c275a00905b4@github.com>
 <UJXjRpHOgKVTLYIAEGBRjqCIu87QwsiE_SK9jxsEZak=.5ba662d3-032e-453c-95cb-d2f802e418ed@github.com>
Message-ID: <Q50rff_wSeo7K3QEDVCtEu8P7gQUOu0glqJzhbUlZHs=.a6c5229d-09f7-41d9-ac23-8f28aaaa3816@github.com>

On Fri, 7 Apr 2023 07:03:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> how did you test it ?
> The existing regression tests will be used for the testing. I will ask for a Mach5 testing if approved. Hopefully, the current regression test coverage is sufficient. I have no plan to add new test cases.

This is windowsaccessbridge which isn't loaded by JDK, its loaded by the AT.
So tested only if you have JAWS or an to test with SFAIK.
 And jaccessinspector and jaccesswalker are separate tools in the JDK.
I think you'd have to be doing the manual accessibility testing.
In other words, you aren't testing the changes you propose.
The automated regression tests SFAIK will not prove anything.

Its important to understand the code you are changing  and how it is used - not just to know C functions.
There's mention of this on our group page :- 
https://openjdk.org/groups/client-libs/
See the paragraph : "Be a subject matter expert, not just a language expert."

Alex Zuev or  @kumarabhi006 can you advise on testing, or failing that test it yourself.

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

PR Comment: https://git.openjdk.org/jdk/pull/12929#issuecomment-1500477504


From dnguyen at openjdk.org  Fri Apr  7 17:40:44 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 7 Apr 2023 17:40:44 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v2]
In-Reply-To: <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
 <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>
Message-ID: <GQaDM0TXZcGmFaUOsjWCYXklJaQxtMMFhdaKFLNxjIE=.620140de-ae0e-4daa-acea-54145dd24f43@github.com>

On Wed, 5 Apr 2023 11:47:06 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305427: code formatting

Test passes on my local MacOS machine. 

Question: The title and bug description mentions testing requestFocus but this test uses requestFocusInWindow. Are you actually testing the right thing here?

Also are you covering enough UI components? I'm not sure the exact purpose of this test, but only CheckBox, Choice, TextField, and List are calling requestFocusInWindow. Button is being clicked by Robot instead. Then there's TextAreas and ScrollBar as other UI components to name a few.

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

PR Review: https://git.openjdk.org/jdk/pull/13293#pullrequestreview-1376426386


From honkar at openjdk.org  Fri Apr  7 17:57:41 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Apr 2023 17:57:41 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due
 to wrong mouse position [v2]
In-Reply-To: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
References: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
Message-ID: <kpoARUdzeV9Q9z8hg7V1IPZcaQkhLkTx92aN-P6Oq7c=.f8506095-c543-47ef-b06e-a00356a7a9a2@github.com>

> This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`.
> As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event.
> 
> Following is the event log before and after fix.
> 
> **Before fix:**
> 
> 1st mouse move
> 2nd mouse move
> Frame-1 Mouse Event
> Frame-2 Mouse Event
> java.awt.Point[x=29,y=29]
> 
> 
> **After fix:**
> 
> 1st mouse move
> 2nd mouse move
> Frame-1 Mouse Event
> 3rd mouse move
> Frame-2 Mouse Event
> java.awt.Point[x=50,y=50]
> 
> 
> Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition.
> 
> The updated test fix is checked on multiple uiScales including fractional scales for windows platform.
> CI testing works as expected on all platforms.

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

  added syncLocationToWindowManager(), changed literals to vars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13380/files
  - new: https://git.openjdk.org/jdk/pull/13380/files/663cc178..fc5f4808

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

  Stats: 37 lines in 1 file changed: 19 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13380/head:pull/13380

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


From honkar at openjdk.org  Fri Apr  7 18:07:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Apr 2023 18:07:45 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due
 to wrong mouse position [v2]
In-Reply-To: <6dBmWURgjX39RK_nDGhfdelPXc8b1bEkyHM58GEYCsc=.416f15de-2e23-4c1e-acab-3c30eb7de4e4@github.com>
References: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
 <WvJ5FspO3nNrR2AH2bMNvNDIi7mzmh72ZLcZOF2GPxo=.8a250221-da6b-4364-829f-b2063d1a2084@github.com>
 <6dBmWURgjX39RK_nDGhfdelPXc8b1bEkyHM58GEYCsc=.416f15de-2e23-4c1e-acab-3c30eb7de4e4@github.com>
Message-ID: <Gzmk8HgvE4XqtjFLbkeZxel_ZghbBBE9_VDlx6PW7_4=.7cd3c5da-3723-4a99-ab6e-892907fc3e21@github.com>

On Fri, 7 Apr 2023 16:24:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java line 113:
>> 
>>> 111:                 frame2.setBounds(120, 120, 120, 120);
>>> 112:                 frame2.setVisible(true);
>>> 113:             }
>> 
>> So are you confident the requested location will be honoured ?
>> I seem to remember a test framework fix in which you had to work quite hard to be sure of the real location.
>> And the implied "170-120=50" might be clearer if we had variables not just literal numbers ?
>
> @prrace I agree, adding PassFailJFrame's [syncLocationToWindowManager()](https://github.com/openjdk/jdk/blob/a8871f5d26e5cb42c031c7b736ec30b1b147a2bc/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L343) to this test will make it more robust.
> I'll change the literals to variables to make the context clear.

Test updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13380#discussion_r1160869231


From dnguyen at openjdk.org  Fri Apr  7 18:41:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 7 Apr 2023 18:41:46 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v4]
In-Reply-To: <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
 <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
Message-ID: <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>

On Fri, 7 Apr 2023 17:03:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303950: adding unit test for legacy window behavior
>>   
>>   This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
>>   
>>   This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
>>   
>>   In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.
>
> src/java.desktop/share/classes/java/awt/Window.java line 3953:
> 
>> 3951:                 if (gg instanceof Graphics2D) {
>> 3952:                     gg.setColor(getBackground());
>> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
> 
> Why was the import for SunHints added if the only edit to this file was adding a space?

Nevermind I saw this wrong when looking through the commit history.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160887595


From duke at openjdk.org  Fri Apr  7 19:37:45 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 7 Apr 2023 19:37:45 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v5]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <REngv82_1yUCb5D6bJuYXlQTT-JNNXCcQSa2W391uis=.62a1482c-cbad-4f04-969f-7dcf13dbcd7b@github.com>

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

Jeremy has updated the pull request incrementally with two additional commits since the last revision:

 - 8303950: adding opaque white window under test windows
   
   Since the bottom two windows are translucent: it will help safeguard test results if they're positioned above an opaque white background.
   
   Also adding a couple of text lines to the windows to help explain why they rendered the way they did.
 - 8303950: rolling back unnecessary
   
   This is should have been part of 6a3a9b42bb705273e1ed9b1de0d04370e69c43ca, which rolled back 1991fdac5dbf76ddaf73cc78a9f7c38370c9674c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/bd81761a..c0d80dc6

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

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

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


From duke at openjdk.org  Fri Apr  7 19:41:42 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 7 Apr 2023 19:41:42 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v4]
In-Reply-To: <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
 <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
 <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>
Message-ID: <i8T8TLDXtke9ScDQoP5VqOxjY9OIQAJIhTm937Qfqnc=.7d181894-d3cb-4360-a44f-6980ea26bfd5@github.com>

On Fri, 7 Apr 2023 18:39:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Window.java line 3953:
>> 
>>> 3951:                 if (gg instanceof Graphics2D) {
>>> 3952:                     gg.setColor(getBackground());
>>> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
>> 
>> Why was the import for SunHints added if the only edit to this file was adding a space?
>
> Nevermind I saw this wrong when looking through the commit history.

Thanks for checking, though. I just pushed a change to roll back this diffs. https://github.com/openjdk/jdk/pull/12993/commits/f369ccde6d73537948d6f5007ae5d0a2b847d8ac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160921482


From honkar at openjdk.org  Fri Apr  7 19:56:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Apr 2023 19:56:45 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <w3LN5bOoM91IO3eTA9meqPabHWfLmrN3sOVc4jdEV44=.654095c3-7b52-4f98-aa01-861491059f36@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
 <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
 <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>
 <Ja6sWzpR8Jh25NfDzzc5vlXOzUMGFVoPNXcTbUllxDg=.f1590064-eff0-4f85-ace8-a31c109f2292@github.com>
 <w3LN5bOoM91IO3eTA9meqPabHWfLmrN3sOVc4jdEV44=.654095c3-7b52-4f98-aa01-861491059f36@github.com>
Message-ID: <-I_H7DMIJUiir4foCe4CXx5TV3wfZsX-MtmCB66yAaU=.d945083f-87b7-42b2-815b-135fc6e99b4d@github.com>

On Fri, 7 Apr 2023 05:32:55 GMT, Phil Race <prr at openjdk.org> wrote:

> > > I don't see why we need this in mainline. I'd prefer to not have it unless we need it.
> > 
> > 
> > I believe it is better to have all JDK branches in sync if it's possible. This change is harmless and as Sergey mentioned it would simplify backport process.
> 
> We'll get it anyway when we upgrade .. that's why we only apply changes that are accepted upstream. And if we upgrade to a version that pre-dates it then we'll have to manually re-apply it for no reason. It is just unnecessary.

@dmarkov20 We will be having a HarfBuzz upgrade to mainline soon. As @prrace suggested, this might be unnecessary at this point then. 

@prrace What about patching it to other branches -17, 20u, is that not required too since we will be backporting the next planned upgrade changes to these branches too?

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1500592886


From prr at openjdk.org  Fri Apr  7 20:15:44 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 20:15:44 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <-I_H7DMIJUiir4foCe4CXx5TV3wfZsX-MtmCB66yAaU=.d945083f-87b7-42b2-815b-135fc6e99b4d@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
 <SdgHkkKz4BLmz4EWOb5pYQb3sETEbO9zwOfDX7BkD5s=.756572c5-19cd-4a84-a91c-131295a42266@github.com>
 <DLKAT0ub8pE0W7ExXtN4nWTMM7g5rElWmkE9Dy0rKTM=.06f36883-9809-4dc8-abfb-65e932d70146@github.com>
 <Ja6sWzpR8Jh25NfDzzc5vlXOzUMGFVoPNXcTbUllxDg=.f1590064-eff0-4f85-ace8-a31c109f2292@github.com>
 <w3LN5bOoM91IO3eTA9meqPabHWfLmrN3sOVc4jdEV44=.654095c3-7b52-4f98-aa01-861491059f36@github.com>
 <-I_H7DMIJUiir4foCe4CXx5TV3wfZsX-MtmCB66yAaU=.d945083f-87b7-42b2-815b-135fc6e99b4d@github.com>
Message-ID: <v7csGj3rYndwcX4YxNfUox6fWhE-dhlCX-MCSzZBd2w=.fb010f88-adcc-4602-82bb-7e6b434d4dca@github.com>

On Fri, 7 Apr 2023 19:52:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> @dmarkov20 We will be having a HarfBuzz upgrade to mainline soon. As @prrace suggested, this might be unnecessary at this point then.

I think it extremely likely we'll do a HB update before JDK 21 RDP1 so, yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1500606758


From prr at openjdk.org  Fri Apr  7 20:41:43 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 20:41:43 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <ZBkxxyXUxmZv6yvO0Me1k7Vtr1VgPeUVOvAPf3SD1aY=.8b4ec945-a7cf-4755-9662-dd821f53b8cd@github.com>

On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

Multiple seconds seems out of bounds (so to speak :-)), for network latency of an X11 round trip.
if it were that slow, I'd expect everything to be unusable, and that's not what you are saying.
So I'd like to hear about a deeper dive into what precisely is slow.
Although very old, it reminded me of this bug : https://bugs.openjdk.org/browse/JDK-4369234
Meanwhile I'll kick off some testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1500622715


From prr at openjdk.org  Fri Apr  7 20:45:43 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 20:45:43 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <P8cy9gUCtMZyQR3FYeGsw0Cs6BlLbGKrMr8DiqCFLzs=.705eae38-2c46-456a-a03f-5bbbf941421c@github.com>

On Mon, 20 Mar 2023 01:07:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

Results look good. This passes all my testing.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13095#pullrequestreview-1376565699


From prr at openjdk.org  Fri Apr  7 20:55:43 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Apr 2023 20:55:43 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <u_CfqaVQS6r_M3GVrS1bxQ9aOS2wHiNEurheQbxrQeM=.4f613d65-094a-4415-8b3f-268353fce73f@github.com>

On Mon, 20 Mar 2023 01:07:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

wait a moment. It looked all green but I didn't look close enough

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13095#pullrequestreview-1376574915


From rriggs at openjdk.org  Fri Apr  7 21:13:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:13:03 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:

 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - Revised mapping mechanism of build target architecture names to enum values.
   Unrecognized values from the build are mapped to enum value "OTHER".
   Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
   Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
 - Revert changes to jdk.accessibility AccessBridge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/52ca4a70..53c20c77

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

  Stats: 237 lines in 10 files changed: 123 ins; 81 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From rriggs at openjdk.org  Fri Apr  7 21:20:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:50 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
Message-ID: <Q13R8FT1RLjbMV8OLLPzuQn9NF2U2ZuuQdMtR48J7-0=.6b9136e6-e9cf-421b-a228-a7b5d59c8701@github.com>

On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge

Take a fresh look and comment.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500655738


From rriggs at openjdk.org  Fri Apr  7 21:20:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <j7jhRBvTbbRGN7Adkc8kY-5ZTRTAUGgG5hOLldVrh4Y=.d9ca1ba2-0dd1-4280-a321-46fb2cf65288@github.com>
 <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com>
 <tsc6LlSdPu19saBv3IHUJsjaw-XTxrO3Syvemm4ZasY=.583024c6-5298-4fab-a359-8fdba0905fdc@github.com>
 <Xvuj-FNTekaixILX1yWW729EsDfmTv_KN4iNp08-eWA=.742dfc08-383b-4afe-af0c-87098d7e177c@github.com>
Message-ID: <OPkepccrTIX4Mw1pwC5nci9e07caIiJDLTRxpDic18o=.85e77a43-2d49-4157-9645-580548295daa@github.com>

On Fri, 7 Apr 2023 12:05:28 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Okay, Lutz is the expert here. Sorry for the noise.
>
> Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore).
> 
> s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example.

Thanks for the authoritative answer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968894


From rriggs at openjdk.org  Fri Apr  7 21:20:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 21:20:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
 <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
Message-ID: <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>

On Fri, 7 Apr 2023 06:03:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> What did you use as the example that would not compile on the other architecture? 
>> 
>> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40
>> 
>> I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file.
>> 
>>> Did you make the other changes to the build that would be needed for a new architecture?
>> 
>> I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. 
>> 
>> According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline?
>> 
>> For example, I want to compile OpenJDK for 32-bit ARM.  I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile.
>
> @Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway.
> 
> Edit: I now understand your point better and agree in parts, see my reply below.

Refactored the way that build time architecture values are mapped to the Architecture enum.
It now uses strings and does not require predefined names in the template file.
Explicitly maps some build time arch values to the corresponding (but not identical Arch enum); for example x86_64 to X64.
Added a method to expose the endian-ness of the build; this allows it to be separated from the architecture.
So for example "ppc64le" maps to PPC64 and the endian-ness is little.
Added an "OTHER" to the enum values so that unrecognized architecture values from the build can be mapped to that enum.
Renamed the template file so it can more naturally cover the os, architecture, endianness, and 64bit'ness of the implementation.
Reworked OperatingSystem to use the same string based interface between the build and the enum.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968389


From duke at openjdk.org  Fri Apr  7 22:29:42 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 7 Apr 2023 22:29:42 GMT
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering
In-Reply-To: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
Message-ID: <BNR0Phhy4Yi43LxsGt2_2i19gGheHcx_mh2RKUgFJYM=.d0ab0746-ced9-4705-9f2a-037b4997bb35@github.com>

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

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

Alan, I may be confused. Does VAqua rely on turning off volatile buffering?

Or your comment might (?) make more sense if it's for my other PR ([for 8303950](https://github.com/openjdk/jdk/pull/12993)) that relates to this method:

https://github.com/openjdk/jdk/blob/a8871f5d26e5cb42c031c7b736ec30b1b147a2bc/src/java.desktop/share/classes/java/awt/Window.java#L3946-L3960

(Also: thanks for mentioning VAqua! I'll check it out. I was a big fan of Werner's Quaqua work a decade ago at another job.)

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

PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-1500695845


From duke at openjdk.org  Fri Apr  7 22:42:45 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 7 Apr 2023 22:42:45 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v2]
In-Reply-To: <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
 <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>
Message-ID: <D3Q2PIEfukIUlQqne0LLTKXxq5gdHSD6z7zTzfFWysg=.f6bee040-4f91-4dba-88a4-23890728a123@github.com>

On Wed, 5 Apr 2023 11:47:06 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305427: code formatting

test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 144:

> 142:             robot.waitForIdle();
> 143: 
> 144:             if (!requestStatus) {

According to the requestFocusInWindow() documentation https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/java/awt/Component.html#requestFocusInWindow() . Developers must never assume that this Component is the focus owner until this Component receives a FOCUS_GAINED event.   

So dn't depend on requestFocusInWindow()  return value

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1161003435


From javalists at cbfiddle.com  Fri Apr  7 22:51:50 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 7 Apr 2023 15:51:50 -0700
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering
In-Reply-To: <BNR0Phhy4Yi43LxsGt2_2i19gGheHcx_mh2RKUgFJYM=.d0ab0746-ced9-4705-9f2a-037b4997bb35@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
 <BNR0Phhy4Yi43LxsGt2_2i19gGheHcx_mh2RKUgFJYM=.d0ab0746-ced9-4705-9f2a-037b4997bb35@github.com>
Message-ID: <C21F178F-36C4-48D0-B9AB-B346485340B6@cbfiddle.com>

I may be confused, too! I haven?t kept close track of the various issues and PRs.

My comment relates to a perhaps old idea of using a graphics rendering hint to suppress painting the window background.

VAqua knows nothing about volatile buffering, nor do I. :-)




> On Apr 7, 2023, at 3:29 PM, Jeremy <duke at openjdk.org> wrote:
> 
> On Mon, 27 Mar 2023 21:45:08 GMT, Jeremy <duke at openjdk.org <mailto:duke at openjdk.org>> wrote:
> 
>> The original write-up contains two complaints:
>> 1. The window is opaque, so pixels that should be transparent are black.
>> 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).
>> 
>> I recommend splitting this up into separate tickets.
>> 
>> This PR addresses the first (probably most offensive) issue: the window is now transparent.
>> 
>> I experimented with a change that resolves the second issue (image resolution) here:
>> https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002
>> 
>> ... that works, but IMO that looks riskier and should be part of a separate discussion.
>> 
>> I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.
> 
> Alan, I may be confused. Does VAqua rely on turning off volatile buffering?
> 
> Or your comment might (?) make more sense if it's for my other PR ([for 8303950](https://github.com/openjdk/jdk/pull/12993)) that relates to this method:
> 
> https://github.com/openjdk/jdk/blob/a8871f5d26e5cb42c031c7b736ec30b1b147a2bc/src/java.desktop/share/classes/java/awt/Window.java#L3946-L3960
> 
> (Also: thanks for mentioning VAqua! I'll check it out. I was a big fan of Werner's Quaqua work a decade ago at another job.)
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-1500695845

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230407/0f51a235/attachment.htm>

From rriggs at openjdk.org  Sat Apr  8 00:58:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 8 Apr 2023 00:58:57 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v4]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

Roger Riggs 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:

 - Refactor to use sun.awt.OSInfo instead of system property os.name.
   Modify OSInfo to use jdk.internal.util.OperatingSystem.
   Modify OSInfo.getOSType() to use a cached value and not require doPriv
   or throw SecurityException
 - Merge branch 'master' into 8304912-use-os-desktop
 - Update copyright
   Replaced a few more uses of os.name.
 - Merge branch 'master' into 8304912-use-os-desktop
 - Use OperatingSystem.isAix
 - Remove unused os.arch system property
 - Apply OperatingSystem enum instead of os.name to java.desktop module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/8f0b918e..a81dd830

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

  Stats: 5111 lines in 137 files changed: 3978 ins; 559 del; 574 mod
  Patch: https://git.openjdk.org/jdk/pull/13213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13213/head:pull/13213

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


From prr at openjdk.org  Sat Apr  8 03:54:47 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 8 Apr 2023 03:54:47 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v4]
In-Reply-To: <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>
Message-ID: <Ma8JBupebr4SPNhO56OBRWHNmrCsUL72hWSH19wuF7o=.a9be8789-4e91-427e-a34a-ef39ca119ef2@github.com>

On Sat, 8 Apr 2023 00:58:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs 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:
> 
>  - Refactor to use sun.awt.OSInfo instead of system property os.name.
>    Modify OSInfo to use jdk.internal.util.OperatingSystem.
>    Modify OSInfo.getOSType() to use a cached value and not require doPriv
>    or throw SecurityException
>  - Merge branch 'master' into 8304912-use-os-desktop
>  - Update copyright
>    Replaced a few more uses of os.name.
>  - Merge branch 'master' into 8304912-use-os-desktop
>  - Use OperatingSystem.isAix
>  - Remove unused os.arch system property
>  - Apply OperatingSystem enum instead of os.name to java.desktop module

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved.

no changes so revert (c) year

src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved.

no changes so revert (c) year

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 2:

> 1: /*
> 2:  * Copyright (c) 2008, 2023, Oracle and/or its affiliates. All rights reserved.

no changes so revert (c) year

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2023, Oracle and/or its affiliates. All rights reserved.

no changes so revert (c) year

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

PR Review: https://git.openjdk.org/jdk/pull/13213#pullrequestreview-1376698465
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161056207
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161056349
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161056810
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161056828


From tr at openjdk.org  Sat Apr  8 05:38:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Sat, 8 Apr 2023 05:38:57 GMT
Subject: RFR: 8257455: javax/swing/Security/6378709/TimerHack.java and
 javax/swing/JFileChooser/4163841/AcceptAllFileFilterTest.java fails in CI
In-Reply-To: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
References: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
Message-ID: <WCkn_mNwFh9QOcQBDXDJ5xcoOXyebnc-mu3g7d1k-Ps=.a1f30618-e848-4c8b-bb80-32c77448f868@github.com>

On Tue, 14 Mar 2023 10:06:47 GMT, Tejesh R <tr at openjdk.org> wrote:

> The issue is intermittent and was not able to reproduce it. Though through code analysis and bug reported logs, the issue seems to be in COM thread of `FilesLoader` class in `BasicDirectoryModel` file. Looks like there are certain places where the `filecache` variable isn't thread-safe, and this fix address the issue. 
> Mach5 test runs are fine, no regressions were found.

Since this include test from closed, I will close this PR and the Bug, will raise an Bug without mentioning the closed test so that it can be taken care as open.

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

PR Comment: https://git.openjdk.org/jdk/pull/13012#issuecomment-1500797905


From tr at openjdk.org  Sat Apr  8 05:38:58 2023
From: tr at openjdk.org (Tejesh R)
Date: Sat, 8 Apr 2023 05:38:58 GMT
Subject: Withdrawn: 8257455: javax/swing/Security/6378709/TimerHack.java and
 javax/swing/JFileChooser/4163841/AcceptAllFileFilterTest.java fails in CI
In-Reply-To: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
References: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
Message-ID: <dLtUHNCJ7tOJuQRo5e-k8B3m59jGAbnK2UEMN3mZXrE=.acd793c2-529e-42b7-8c98-739562a5268c@github.com>

On Tue, 14 Mar 2023 10:06:47 GMT, Tejesh R <tr at openjdk.org> wrote:

> The issue is intermittent and was not able to reproduce it. Though through code analysis and bug reported logs, the issue seems to be in COM thread of `FilesLoader` class in `BasicDirectoryModel` file. Looks like there are certain places where the `filecache` variable isn't thread-safe, and this fix address the issue. 
> Mach5 test runs are fine, no regressions were found.

This pull request has been closed without being integrated.

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

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


From stuefe at openjdk.org  Sat Apr  8 07:10:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 8 Apr 2023 07:10:55 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v7]
In-Reply-To: <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <mgeV-ZQcXhbwhg8_T6HcBp60U9UeV1r9Onp3hA9hm9s=.129a9e03-54af-486f-a3d0-6708a8ab0fe0@github.com>
 <Ej2JZXteX9T4DuRQ38yW-QlOljEbw0KQP2ZCEeeS3QA=.40c9dea3-f068-4c39-b708-17174a8884dd@github.com>
 <VnW1VBWQ9sLchqOACSMh0gUQG1cvQDJaSW3g_MPHnqo=.47697356-aabb-4d33-b4bf-df12bd3b15b3@github.com>
 <IWrvXb5j8yccPrUMpMHD63ddaA_7zKQBtkcRlnA--VU=.39f6fc2d-2614-4b2c-9f53-b7c7567648e2@github.com>
 <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com>
 <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com>
 <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com>
 <GwC_Fo0whJG-qqwuFPBso_v6GMGaH5LNGPnWGhmJzpE=.68e2a3b1-0ea6-40e9-b3ec-d4f6b3ba0680@github.com>
Message-ID: <yGbFDaAum7pDn4MwLcBi0iWruPAfF3L9ixTaz4_le3E=.80c8a999-3f52-40c0-95dc-6b4336b890c0@github.com>

On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactored the way that build time architecture values are mapped to the Architecture enum. 

Thank you for this, Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537


From aturbanov at openjdk.org  Sat Apr  8 08:26:48 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 8 Apr 2023 08:26:48 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v4]
In-Reply-To: <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>
Message-ID: <YcjqIZEj_n0DyYG6WzeIPwFzj-hA-A5aZE2j_WS6-Tw=.3032854b-6dfd-42d6-afb0-c92b71f47e84@github.com>

On Sat, 8 Apr 2023 00:58:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs 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:
> 
>  - Refactor to use sun.awt.OSInfo instead of system property os.name.
>    Modify OSInfo to use jdk.internal.util.OperatingSystem.
>    Modify OSInfo.getOSType() to use a cached value and not require doPriv
>    or throw SecurityException
>  - Merge branch 'master' into 8304912-use-os-desktop
>  - Update copyright
>    Replaced a few more uses of os.name.
>  - Merge branch 'master' into 8304912-use-os-desktop
>  - Use OperatingSystem.isAix
>  - Remove unused os.arch system property
>  - Apply OperatingSystem enum instead of os.name to java.desktop module

src/java.desktop/share/classes/sun/awt/OSInfo.java line 1:

> 1: /*

`sun.awt.OSInfo#OS_NAME` is now unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161082742


From duke at openjdk.org  Sat Apr  8 08:26:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 8 Apr 2023 08:26:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v8]
In-Reply-To: <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <kkme-6_p1Ux-3R8qks4vMCfF32WaCxcCBfyeHmOgsUA=.a33c4e16-1f0f-40cb-8e83-1cf318d89f60@github.com>
Message-ID: <bp-SLJyZUFte1k0P3N5Xkf2YZmA_MDGuJlfbSHwOdYA=.3b2a68c6-e27c-47d9-811a-21c8ebb7036f@github.com>

On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge

src/java.base/share/classes/jdk/internal/util/Architecture.java line 47:

> 45:     // Cache a copy of the array for lightweight indexing
> 46:     private static final @Stable Architecture[] archValues = Architecture.values();
> 47: 

This?now appears to?be?unused:
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161082612


From jwaters at openjdk.org  Sat Apr  8 13:26:36 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 8 Apr 2023 13:26:36 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

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

  Legacy Boolean to jboolean conversion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13139/files
  - new: https://git.openjdk.org/jdk/pull/13139/files/362cf3ed..dad94b31

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

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

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


From jwaters at openjdk.org  Sat Apr  8 13:26:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 8 Apr 2023 13:26:38 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <B5qkdYWLgOcqZ-_IdFBZTehhhHA6IhwfnE9OecMrxGU=.d1e536f4-fba5-43db-b6a1-e8974b641815@github.com>
Message-ID: <Xaw00mULXX4soVsjOmi12olib0t6Qt997WbQOAp3zes=.e084264d-b74d-4ed4-b685-24d45b74d46f@github.com>

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

Alright, thanks Phil

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

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1500890807


From rriggs at openjdk.org  Sat Apr  8 18:00:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 8 Apr 2023 18:00:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The values of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Remove unused static and import of Stabile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/53c20c77..f3646dc9

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

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

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


From rriggs at openjdk.org  Sat Apr  8 18:04:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 8 Apr 2023 18:04:33 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v5]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <wSS-ARXAaX3lV0S3-JeJWTFtqc4Vkuy0VGNQR9mJ6SE=.e666585a-e3be-4005-b950-147bb969ac9c@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

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

  Revert copyright in unmodified files; remove unused static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/a81dd830..98219b24

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

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

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


From prr at openjdk.org  Sat Apr  8 20:27:57 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 8 Apr 2023 20:27:57 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v5]
In-Reply-To: <wSS-ARXAaX3lV0S3-JeJWTFtqc4Vkuy0VGNQR9mJ6SE=.e666585a-e3be-4005-b950-147bb969ac9c@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <wSS-ARXAaX3lV0S3-JeJWTFtqc4Vkuy0VGNQR9mJ6SE=.e666585a-e3be-4005-b950-147bb969ac9c@github.com>
Message-ID: <6516k7eIl-cbRfS6cir4NLBD2umzCeZfVHkn6ygEAbA=.1fa6b3ab-e52d-4b82-b10a-0aefe1c5a793@github.com>

On Sat, 8 Apr 2023 18:04:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert copyright in unmodified files; remove unused static

src/java.desktop/share/classes/sun/awt/OSInfo.java line 62:

> 60:     public static final WindowsVersion WINDOWS_2003 = new WindowsVersion(5, 2);
> 61:     public static final WindowsVersion WINDOWS_VISTA = new WindowsVersion(6, 0);
> 62:     public static final WindowsVersion WINDOWS_7 = new WindowsVersion(6, 1);

The  windows version map looks like it hasn't had any love in a long time.
Updating it is VERY out of scope for this fix as it needs some thought in whether to remove old entries
and what to do about replacing them so I filed https://bugs.openjdk.org/browse/JDK-8305777

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161154446


From duke at openjdk.org  Sun Apr  9 10:15:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 9 Apr 2023 10:15:50 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
 <sbyXrFCu7Ac7ZeudCgy067S9l6Zy2c2qzrtPcTYlsNI=.fdf18e0e-f9d9-4184-86f3-5f41d60d18c2@github.com>
Message-ID: <bzTui17Yr5qYIZRgwn2MlxRAJpLpULNKnwsRgKAl6aA=.361d16c1-51fc-4988-8ae7-903627eef83e@github.com>

On Mon, 20 Mar 2023 11:24:12 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which suggests we remove the orhphaned `SwingApplet` netbeans project directory.
>> 
>> The `SwingApplet` demo was removed in [JDK-8205119](https://bugs.openjdk.org/browse/JDK-8205119), but the netbeans projects files were left behind.
>> 
>> Additionally, the following netbeans projects reference source files that do not exist (if they ever did?):
>> 
>> - src/demo/share/nbproject/management/FullThreadDump
>> - src/demo/share/nbproject/management/JTop
>> - src/demo/share/nbproject/management/MemoryMonitor
>> - src/demo/share/nbproject/management/VerboseGC
>> - src/demo/share/nbproject/scripting/jconsole-plugin
>> 
>> The PR deletes files in these directories as well.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete netbeans project files in src/demo/share/nbproject/management and src/demo/share/nbproject/scripting

This approved PR is looking for a friendly sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1501093899


From dmarkov at openjdk.org  Sun Apr  9 16:13:55 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Sun, 9 Apr 2023 16:13:55 GMT
Subject: RFR: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
Message-ID: <4x9tm_zA0iUjIeGFzYPh4QqiRmQKYzErHcEJ1U6yDcA=.4e010961-237c-4409-bb0e-56f38004e96e@github.com>

On Tue, 4 Apr 2023 15:46:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Port the fix from the upstream/HarfBuzz repo.
> 
> More info can be obtained here:
> https://github.com/harfbuzz/harfbuzz/discussions/4188 
> https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

OK, I will am this PR then

> > @dmarkov20 We will be having a HarfBuzz upgrade to mainline soon. As @prrace suggested, this might be unnecessary at this point then.
> 
> I think it extremely likely we'll do a HB update before JDK 21 RDP1 so, yes.

OK, I am closing this one then

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

PR Comment: https://git.openjdk.org/jdk/pull/13328#issuecomment-1501162235


From dmarkov at openjdk.org  Sun Apr  9 16:13:56 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Sun, 9 Apr 2023 16:13:56 GMT
Subject: Withdrawn: 8305527: HarfBuzz: Remove trailing comma from the enum in
 hb-paint.h
In-Reply-To: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
References: <2u9nlXcukZ1-eyNEIGQ7o4jRmJhOGov6t4-bjh7Ec1g=.a5c58bdd-f152-49f4-bc7d-7920fc0c86d9@github.com>
Message-ID: <V5aX4Xu49m61ETjUdsqAREQIGuKe8ZOYgmlrYUreOmg=.3d0f9b6a-37dc-43f9-aa65-00bdf912fb8e@github.com>

On Tue, 4 Apr 2023 15:46:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Port the fix from the upstream/HarfBuzz repo.
> 
> More info can be obtained here:
> https://github.com/harfbuzz/harfbuzz/discussions/4188 
> https://github.com/harfbuzz/harfbuzz/commit/04a47932a3844f7e73e3af8b05fb98c8b54fb779

This pull request has been closed without being integrated.

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

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


From stuefe at openjdk.org  Sun Apr  9 17:22:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 9 Apr 2023 17:22:38 GMT
Subject: RFR: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
In-Reply-To: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
References: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
Message-ID: <w8oIBQu84J3t0utf8_aJVoBt-GqHAAXb0DlUwSyTyAY=.fe5e3d6b-2ece-4f93-a63c-51a2e9f52a64@github.com>

On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
> 
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
> 
> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
> 
> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.

Seems like a reasonable workaround. Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

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

PR Comment: https://git.openjdk.org/jdk/pull/13352#issuecomment-1501166929


From duke at openjdk.org  Mon Apr 10 00:47:43 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Mon, 10 Apr 2023 00:47:43 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <Kul_GOybQWwpJk_4yS6a8dd9MP3vm3IkIuGOinnqK9E=.f6ac18ba-54df-4e2e-95ac-6de78e87e5ce@github.com>
Message-ID: <wBtEjNkW4GxWPEEN9-ARFZBZQa9euv61mdajzZa6--s=.5322b292-4b30-4084-a608-317d4c36923f@github.com>

On Fri, 7 Apr 2023 05:26:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Provide a complete description and explanation of what you are doing.
Thanks, I have add a description. In fact it isn't a complex problem, the key problem is how to initinate. If have any problem, please notify me.,
Good luck!

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

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


From aghaisas at openjdk.org  Mon Apr 10 04:55:52 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 10 Apr 2023 04:55:52 GMT
Subject: Integrated: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
References: <qc8WRexC1E8ZIVabDsMpd4WnEc6KgCj5hG1QEnWmlWM=.c941cf19-7dba-4ac8-b7a4-8965fd91d746@github.com>
Message-ID: <_0dOGIaFE-rpP7-st7ChmZOy4Y_73pe05fyYBuwooT0=.e3913ebc-1b85-4379-81da-80a1b971d9a3@github.com>

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on screen sleep and wakeup event. It is found that stop and restart of CVDisplayLink on these events also does not help.
> 
> Fix : Recreate the CVDisplayLink on screen sleep and wakeup event.

This pull request has now been integrated.

Changeset: 969a6b9f
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/969a6b9fd7f7afc60250309f3ada205c1473cf8e
Stats:     38 lines in 1 file changed: 35 ins; 0 del; 3 mod

8304825: MacOS metal pipeline - window isn't painted if created during display sleep

Reviewed-by: kcr, avu, prr

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

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


From mkartashev at openjdk.org  Mon Apr 10 07:02:42 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 10 Apr 2023 07:02:42 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <ZBkxxyXUxmZv6yvO0Me1k7Vtr1VgPeUVOvAPf3SD1aY=.8b4ec945-a7cf-4755-9662-dd821f53b8cd@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <ZBkxxyXUxmZv6yvO0Me1k7Vtr1VgPeUVOvAPf3SD1aY=.8b4ec945-a7cf-4755-9662-dd821f53b8cd@github.com>
Message-ID: <rzT7SACjLsY71IRUawcSika9ENRpJMQ-lo1j__iPFQU=.a5b45a66-3607-4791-bb36-22f6019bf94a@github.com>

On Fri, 7 Apr 2023 20:38:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Multiple seconds seems out of bounds (so to speak :-)), for network latency of an X11 round trip.

Most certainly. What I actually measured was the time (min, max, and average) the AWT lock was being held by a method.

In fact, the story began with [fakexrandr](https://github.com/phillipberndt/fakexrandr), a tool that divides one monitor into several for purposes beyond my comprehension (testing, perhaps?) When this tool is configured to fake many monitors (don't remember the exact number, but it was around 10 or more), it starts to introduce significant delays that [annoyed some users](https://github.com/phillipberndt/fakexrandr/issues/64#issuecomment-901877835).

Normally, `X11GraphicsDevice.pGetBounds()` holds the AWT lock for 1 ms on average with 11 ms max in one of the experiments.. `fakexrandr` managed to bring this number up to 34ms on average, which - together with `XToolkit.getScreenInsets()` - was the only difference between "fast" and "sluggish" GUI that users were reporting. Other operations took about the same amount of time.

But it wasn't just about `fakexrandr`: I also noticed that a remote X session has the same effect as `fakexrandr`. As an example, on a remote machine the call to `XToolkit.getScreenInsets()` holds the AWT lock for 69ms on average with a whopping 830ms peak. As is obvious from the average number, such a long delay doesn't happen frequently, so it's very hard to start profiling at exactly the right moment in order to try to find out the underlying cause.

In the end, I'm sure it's about the timing of *other* operations that take the AWT lock coupled with the delays introduced by `XineramaQueryScreens()` and friends. Perhaps the recent [commit](https://github.com/openjdk/jdk/commit/dc81603cbf223c3ac6b41396d1998a07524a0d54) for `8305666: Add system property for fair AWT lock` may also help with this, but it wouldn't be as effective as this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1501473318


From psadhukhan at openjdk.org  Mon Apr 10 07:24:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Apr 2023 07:24:57 GMT
Subject: Integrated: 4825182: DefaultBoundedRangeModel.setMinimum() changes
 extent unnecessarily
In-Reply-To: <zHp80OVLg5z1_ctDda9Zc8ZXMgVwaBP3xfKla_B91so=.06c9528e-5f79-4bd4-bb00-c0f36f10a94e@github.com>
References: <zHp80OVLg5z1_ctDda9Zc8ZXMgVwaBP3xfKla_B91so=.06c9528e-5f79-4bd4-bb00-c0f36f10a94e@github.com>
Message-ID: <yDYyRl51IgFJ4KFOca9-v0Qu3t2MQwaNahTFLw0UDZ4=.a819942e-11ef-4f22-bf9a-4e4d6160a90d@github.com>

On Thu, 6 Apr 2023 14:15:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [DefaultBoundedRangeModel spec](https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/javax/swing/DefaultBoundedRangeModel.html#%3Cinit%3E(int,int,int,int))
> set maximum, minimun., extent as per the constraint "min <= value <= value+extent <= max"
> Now, when DefaultBoundedRangeModel.setMinimum() is called with same negative "value" then because of the integer overflow in `setMinimum` method, it causes the `extent `to become 0.
> 
> Fix the integer overflow and make sure the extent is not changed unncessarily.
> All jtreg/jck tests are ok.

This pull request has now been integrated.

Changeset: db174a15
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db174a15d18eb8ea9c826592b88f8e690112eaaf
Stats:     72 lines in 2 files changed: 71 ins; 0 del; 1 mod

4825182: DefaultBoundedRangeModel.setMinimum() changes extent unnecessarily

Reviewed-by: prr

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

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


From psadhukhan at openjdk.org  Mon Apr 10 08:16:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Apr 2023 08:16:44 GMT
Subject: RFR: 8299713: Test
 javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor
In-Reply-To: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>
References: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>
Message-ID: <mWUvmx7LkgYbNDfdeWLy1WpKYbzeUKbaYtGU7RbBcSU=.10c8b99f-c3bb-4036-81b9-207f219cedca@github.com>

On Wed, 25 Jan 2023 08:32:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue seems to be very old, very intermittent bug which is not reproducible in repeated test run,
> so added some stability fixes like accessing swing components in EDT, delay, frame dispose and take a screenshot during fail.
> Multiple runs on CI platforms is ok.

time

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

PR Comment: https://git.openjdk.org/jdk/pull/12181#issuecomment-1501538175


From ngubarkov at openjdk.org  Mon Apr 10 08:38:42 2023
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Mon, 10 Apr 2023 08:38:42 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <MLmYnfXB-RzTYritoAqQkkXswCKFjsRTI3Xqe_97EB8=.f5373cbe-bce5-497b-b33b-f31762b73564@github.com>

On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

As for me, even 1ms per call is already too much for coordinate conversion functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1501555363


From psadhukhan at openjdk.org  Mon Apr 10 12:58:30 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Apr 2023 12:58:30 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode()
Message-ID: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>

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

All jtreg/jck tests are ok

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

Commit messages:
 - Test fix
 - Test fix
 - 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode()

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

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


From aturbanov at openjdk.org  Mon Apr 10 16:11:49 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 10 Apr 2023 16:11:49 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v4]
In-Reply-To: <Ma8JBupebr4SPNhO56OBRWHNmrCsUL72hWSH19wuF7o=.a9be8789-4e91-427e-a34a-ef39ca119ef2@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <GCt9LJtGJC0EGqIEQN_-LvBugYbWxUnMWllb5zVYLVY=.253ee323-c451-429d-ba50-d35de52e4ad7@github.com>
 <Ma8JBupebr4SPNhO56OBRWHNmrCsUL72hWSH19wuF7o=.a9be8789-4e91-427e-a34a-ef39ca119ef2@github.com>
Message-ID: <RQ71msFAZqnvlUOFfe6-hlzA4BY5W9Yh5SDd9vTMqTY=.5df0a8bf-8ace-4b2b-bd2f-46c0cba9bbd7@github.com>

On Sat, 8 Apr 2023 03:51:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> Roger Riggs 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:
>> 
>>  - Refactor to use sun.awt.OSInfo instead of system property os.name.
>>    Modify OSInfo to use jdk.internal.util.OperatingSystem.
>>    Modify OSInfo.getOSType() to use a cached value and not require doPriv
>>    or throw SecurityException
>>  - Merge branch 'master' into 8304912-use-os-desktop
>>  - Update copyright
>>    Replaced a few more uses of os.name.
>>  - Merge branch 'master' into 8304912-use-os-desktop
>>  - Use OperatingSystem.isAix
>>  - Remove unused os.arch system property
>>  - Apply OperatingSystem enum instead of os.name to java.desktop module
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> no changes so revert (c) year

@RogerRiggs missed this one

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1161856370


From duke at openjdk.org  Mon Apr 10 16:23:41 2023
From: duke at openjdk.org (Jeremy)
Date: Mon, 10 Apr 2023 16:23:41 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer NullPointerException
Message-ID: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>

This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.

This resolution involves confirming that an ImageConsumer is still registered before every notification.

I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

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

Commit messages:
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - Merge pull request #1 from openjdk/master

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

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


From rriggs at openjdk.org  Mon Apr 10 16:56:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 16:56:43 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v6]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <nnCr_yIK1Nsl3paFZ-0zMFQBXgwoolH5sLVgeJsR5Rc=.44745efd-eb7a-4650-93bf-261851c4a605@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

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

  Revert copyright in unmodified file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/98219b24..89fe7507

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13213&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13213&range=04-05

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

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


From prr at openjdk.org  Mon Apr 10 21:28:37 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Apr 2023 21:28:37 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <d9c1DdYeG9sH84EzA0OnKzDaGXusiQDHapcox_aTtiU=.e19c474a-598d-4939-98c5-584ab65f711b@github.com>

On Mon, 10 Apr 2023 16:16:32 GMT, Jeremy <duke at openjdk.org> wrote:

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

So the repeated checks for null make it look like you are dealing with some other thread setting it to null

If that were so, I don't think this approach is correct because the repeated null checks aren't a guarantee.
It can still go null between you checking it and then de-referencing it.

But I see that add/removeConsumer are synchronized methods
And the private method sendPixels() is only called from the private method produce()
which is only called from addConsumer()

So it seems impossible for some other thread to do this.
Therefore you must be doing it to yourself on the same thread.

I tracked down that the catch of null and printStackTrace were added under this bug
https://bugs.openjdk.org/browse/JDK-4905411

There it is implied that the callbacks such as
theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE);
are where the null is happening

The person who suggested the fix (not the person who implemented the fix)
was the person who architected the whole image producer/consumer model and near as I can tell
the idea was that you have a programming bug removing the consumer too soon.
I'd expect that you'd see this problem consistently since there's only one thread involved
(unless the callback kicks off another thread to do it)

It also points out that you're unlikely to need the repeated checks since it can only be nulled out
during the call backs (again unless the callback starts another thread to do it - unlikely I think).

If you think what you are doing is correct (I think the architect of the code supposed otherwise)
and you want to be sure, I'd capture "theConsumer" into a local var in each of the methods
sendPixel() and produce() and check and use the local var. Then no one can ever null that
out while you are using it. Since that's the intention of the design, I think that's a safe thing
to do.
However I suggest that if the null check finds it is null on entry that there be an

ImageConsumer localConsumer = theConsumer;
if (localConsumer ==  null) {
boolean debugging = <wrap in doprivleged get property("awt.consumer.debug")>
if (debugging) {
System.err.println("theConsumer is null - did you remove the consumer before production is complete ?"); e.printStackTrace())
 }
return
}
at the beginning of both methods

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1502348061


From serb at openjdk.org  Tue Apr 11 00:05:41 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 00:05:41 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <F161Hx-HEu4P_M-Av5KJNPFNPJchBmV_R3MwvqnKleE=.05631729-f2f6-4b4f-94ed-d901704255c8@github.com>

On Mon, 20 Mar 2023 01:07:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

Sad, does it catches the difference between slow/fast implementations or some issues related to the alpha_pre support?

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

PR Comment: https://git.openjdk.org/jdk/pull/13095#issuecomment-1502489899


From serb at openjdk.org  Tue Apr 11 00:08:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 00:08:32 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <xd3PckA6E3d04Ew1THTj0ZlM6cCwOhLiIdVdvAkKHto=.b8537c37-2fe8-4c14-addc-b0a31468106b@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <ityXcTPFx_sk-zvzhc2YirLu6pYiFG52e6OfrzYo3MY=.f145f196-2d48-40bc-b7b8-a702d7cbf90e@github.com>
 <xd3PckA6E3d04Ew1THTj0ZlM6cCwOhLiIdVdvAkKHto=.b8537c37-2fe8-4c14-addc-b0a31468106b@github.com>
Message-ID: <XQU1NQyEAbM-b12WS0tdHqE7-7HA_J46TQf9B-eQvks=.e3830ddc-3f5a-467f-8c85-09c5406ef718@github.com>

On Wed, 5 Apr 2023 09:21:18 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> `X11GraphicsDevice.pGetBounds()`; I didn't measure further down.

It would be good to know the exact function to check where it is used.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1502492865


From serb at openjdk.org  Tue Apr 11 00:12:37 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 00:12:37 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>

On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 881:

> 879:     }
> 880: 
> 881:     private final Hashtable<GraphicsConfiguration, Insets> cachedInsets = new Hashtable<>();

You do not need to create a handcrafted list of gc->insets, but instead, you can save that information directly in the GC. In that case, each GC should be added as a listener(DisplayChangedListener) to the SGE. I think the same should be done for the GD+bounds, see how it is implemented on macOS(CGraphicsDevice#displayChanged)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1162181681


From serb at openjdk.org  Tue Apr 11 00:13:34 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 00:13:34 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <KmingNm_1xGEFr3V0oxdnQTZrNQHzUCULQCi4VLjMDU=.15e67567-bf31-43b1-93d1-7d726b942d15@github.com>

On Mon, 10 Apr 2023 16:16:32 GMT, Jeremy <duke at openjdk.org> wrote:

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

test/jdk/sun/awt/image/OffScreenImageSource/bug4200096.java line 49:

> 47:                 super.println(x);
> 48:                 if (x instanceof Throwable)
> 49:                     System.exit(1);

The tests should not use the System.exit() as it might affect the execution of other tests. It is better to set some flag and check it at the end.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1162182212


From serb at openjdk.org  Tue Apr 11 00:14:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 00:14:35 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
 <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>
Message-ID: <-6wNY5cssf-oazwqnicJ7ilYAzMt5sf98J3vPlar6w0=.da416751-19b1-41c2-ae85-58951f6c23b9@github.com>

On Mon, 3 Apr 2023 09:55:40 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Such notifications won't be ignored as isVisible() returns true for iconified windows

But it will be ignored if the window is invisible. It is better to fix the https://bugs.openjdk.org/browse/JDK-6995195

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

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1502498535


From duke at openjdk.org  Tue Apr 11 00:20:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 11 Apr 2023 00:20:45 GMT
Subject: Integrated: 8304501: Remove orphaned demo netbeans projects
In-Reply-To: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
References: <nMyQ7-Ix9Pcvezo2DbRzalLcIL8Jgd06QTroz7D2YMw=.c4243cb8-e63d-4a46-b120-1b6e5da6e8f0@github.com>
Message-ID: <WTJBV6G7voGWw5TrvQbkgN8TK-IAVVpZkdpiCfouKKw=.20512626-11fc-4aec-a20b-5a47a5b4eb62@github.com>

On Mon, 20 Mar 2023 10:31:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests we remove the orhphaned `SwingApplet` netbeans project directory.
> 
> The `SwingApplet` demo was removed in [JDK-8205119](https://bugs.openjdk.org/browse/JDK-8205119), but the netbeans projects files were left behind.
> 
> Additionally, the following netbeans projects reference source files that do not exist (if they ever did?):
> 
> - src/demo/share/nbproject/management/FullThreadDump
> - src/demo/share/nbproject/management/JTop
> - src/demo/share/nbproject/management/MemoryMonitor
> - src/demo/share/nbproject/management/VerboseGC
> - src/demo/share/nbproject/scripting/jconsole-plugin
> 
> The PR deletes files in these directories as well.

This pull request has now been integrated.

Changeset: 4485737e
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4485737e9b93cdf5cfc9a0f4dc0f327cd119f75b
Stats:     3063 lines in 36 files changed: 0 ins; 3063 del; 0 mod

8304501: Remove orphaned demo netbeans projects

Reviewed-by: serb

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

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


From dholmes at openjdk.org  Tue Apr 11 03:15:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Apr 2023 03:15:35 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
Message-ID: <XMIZ0dYXJOHdI8dybaoy0CKj7LLPHsQjJ9MEQlBc6wQ=.5cc3a8b1-de19-4e8c-9e6d-beb14a75bf1a@github.com>

On Sat, 8 Apr 2023 13:26:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Legacy Boolean to jboolean conversion

Okay. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1378388160


From duke at openjdk.org  Tue Apr 11 03:49:25 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 11 Apr 2023 03:49:25 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v2]
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <uOcQc10SiFfdYmv9CnUnYEeubqsG4x4QgYTlpZq_0hs=.aa85c96b-58ee-4fc7-ba7f-a6de3b99a838@github.com>

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

Jeremy has updated the pull request incrementally with six additional commits since the last revision:

 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   Make sure OffScreenImageSource#addConsumer doesn't throw a NPE if the argument is null.
   
   The rationale here is:
   The preexisting implementation wouldn't throw a NPE, so we shouldn't change that now.
   
   (Or more specifically: the preexisting implementation *would* throw a NPE, but it would also catch it and print it to System.err. The caller wouldn't need to anticipate a NPE.)
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   Changing `runImageConsumerTest` to make sure we're explicitly testing a `OffScreenImageSource`.
   
   By contrast: the `runImageDimensionTest` is more of an integration-style test that *happens* to test the `OffScreenImageSource`.
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   Adding createAbstractImage() with a little documentation to clarify why we're creating an image the way we are.
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   Re-adding the 'synchronized' keyword.
   
   We can probably do without it now, but I'm just trying to minimize possible unintended side-effects of this PR. Nobody asked for improved multithreaded support. And this class is used to iterate over BufferedImages (which are already in memory), so (as long as the ImageConsumer isn't taking too long -- or blocking) this should be very fast.
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   In code review prrace pointed out:
   > I'd capture "theConsumer" into a local var in each of the methods sendPixel() and produce() and check and use the local var
   
   https://github.com/openjdk/jdk/pull/13408#issuecomment-1502348061
   
   This is actually my previous/original draft for JDK-4200096 ( 49a49ee8585e8a4b5f33a6af04f2ce0165bf1199 ), but I shied way from this approach because I was afraid code reviewers would point out its changes are excessively invasive for the original complaint. (For ex: now OSIS supports multithreading, which nobody asked for. Should I re-add the `synchronized` method modifiers? (although they are theoretically no longer necessary, keeping them reduces the risk of unintended consequences...) Or if multithreaded support is worth keeping: should I at least add a unit test for it? These questions seemed like they're straying off-topic from the original bug.)
 - 4200096: OffScreenImageSource.removeConsumer NullPointerException
   
   In code review mrserb pointed out we shouldn't use System.exit(1) as an error condition.
   
   https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13408/files
  - new: https://git.openjdk.org/jdk/pull/13408/files/73e9f010..36feaad0

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

  Stats: 90 lines in 2 files changed: 46 ins; 10 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13408/head:pull/13408

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


From duke at openjdk.org  Tue Apr 11 03:49:27 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 11 Apr 2023 03:49:27 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <attqHmGacclmcE1wh29uj1z_59X_LM3NltC80ZMxzxc=.6c40c8b8-748b-4469-b9b1-7297efd74058@github.com>

On Mon, 10 Apr 2023 16:16:32 GMT, Jeremy <duke at openjdk.org> wrote:

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

Thanks for the thorough review.

To recap:

Yes, the original problem (as I understand it) has to do with listeners that detach mid-production.

I apologize if I failed to explain this up-front. I tried to describe the problem I set out to "solve" in the comments preceding the first unit test:

https://github.com/mickleness/jdk/blob/73e9f010b3c356c2cf405855f5a33f387e7bb7ee/test/jdk/sun/awt/image/OffScreenImageSource/bug4200096.java#L57-L91

> I'd like to know what stack trace you see.

In the master openjdk branch this test fails as follows:


----------System.err:(29/2496)----------
java.lang.NullPointerException: Cannot invoke "java.awt.image.ImageConsumer.setProperties(java.util.Hashtable)" because "this.theConsumer" is null
java.lang.RuntimeException: java.lang.NullPointerException: Cannot invoke "java.awt.image.ImageConsumer.setProperties(java.util.Hashtable)" because "this.theConsumer" is null
	at bug4200096$1.println(bug4200096.java:49)
	at java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)
	at java.base/java.lang.Throwable.lockedPrintStackTrace(Throwable.java:684)
	at java.base/java.lang.Throwable.printStackTrace(Throwable.java:673)
	at java.base/java.lang.Throwable.printStackTrace(Throwable.java:660)
	at java.base/java.lang.Throwable.printStackTrace(Throwable.java:651)
	at java.desktop/sun.awt.image.OffScreenImageSource.produce(OffScreenImageSource.java:204)
	at java.desktop/sun.awt.image.OffScreenImageSource.addConsumer(OffScreenImageSource.java:66)
	at java.desktop/sun.awt.image.OffScreenImageSource.startProduction(OffScreenImageSource.java:80)
	at java.desktop/java.awt.image.FilteredImageSource.startProduction(FilteredImageSource.java:184)
	at java.desktop/sun.awt.image.ImageRepresentation.startProduction(ImageRepresentation.java:732)
	at java.desktop/sun.awt.image.ToolkitImage.addWatcher(ToolkitImage.java:221)
	at java.desktop/sun.awt.image.ToolkitImage.getWidth(ToolkitImage.java:110)
	at bug4200096.runImageDimensionTest(bug4200096.java:90)
	at bug4200096.main(bug4200096.java:53)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1623)
Caused by: java.lang.NullPointerException: Cannot invoke "java.awt.image.ImageConsumer.setProperties(java.util.Hashtable)" because "this.theConsumer" is null
	at java.desktop/sun.awt.image.OffScreenImageSource.produce(OffScreenImageSource.java:186)
	... 12 more


So in this test: I'm not explicitly adding or removing an ImageConsumer or ImageObserver. My implementation of `ImageObserver#imageUpdate` is returning `false` once it received the dimensions. Returning false prompts something else to remove an ImageConsumer on my behalf, which resulted in the NPE in System.err when the OffScreenImageSource proceeded to keep producing the image.

I just pushed a few revisions that, among other things, pass in the ImageConsumer as an argument as you suggested. (But they also still constantly check `isConsumer(ImageObserver)`

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1502645900


From psadhukhan at openjdk.org  Tue Apr 11 03:55:36 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Apr 2023 03:55:36 GMT
Subject: RFR: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on
 Ubunutu 20.04
Message-ID: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>

Although not able to reproduce this locally or in mach5, it can happen when robot key movements start happening before frame is visible,
so added stability fixes like delay of 1s after frame is visible and key movements are done, added waitForIdle, increase autodelay time, added frame dispose also at end.

Several iterations of the test pass in all platforms. Link in JBS

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

Commit messages:
 - 8305780: javax/swing/JTable/7068740/bug7068740.java fails on Ubunutu 20.04
 - 8305780: javax/swing/JTable/7068740/bug7068740.java fails on Ubunutu 20.04

Changes: https://git.openjdk.org/jdk/pull/13416/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305780
  Stats: 87 lines in 1 file changed: 28 ins; 30 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/13416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13416/head:pull/13416

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


From duke at openjdk.org  Tue Apr 11 04:18:58 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 11 Apr 2023 04:18:58 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v6]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <Uwu1lFS9HLngFDFSDolfC9MYHNI3Qnww6Clg8ReEYpo=.0cb03b44-4d44-4ee7-95cf-dc2de22e18d5@github.com>

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

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

  8303950: avoid System.exit(1)
  
  mrserb recommended against this in a separate PR
  
  https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/c0d80dc6..d9c881e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=04-05

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

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


From duke at openjdk.org  Tue Apr 11 04:47:04 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 11 Apr 2023 04:47:04 GMT
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o
 Volatile Buffering [v2]
In-Reply-To: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
Message-ID: <0tixl2g0Tq-yGHz6_0XsPjZwYoW_YWjuoMcaFOVR_68=.0ef9b8e4-930e-4136-8426-124d1e0a5053@github.com>

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

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

  8303904: avoid System.exit(1)
  
  mrserb recommended against this in a separate PR
  
  https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13196/files
  - new: https://git.openjdk.org/jdk/pull/13196/files/4284d4cd..ffc8ff44

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

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

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


From psadhukhan at openjdk.org  Tue Apr 11 05:12:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Apr 2023 05:12:24 GMT
Subject: RFR: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java:
 Unexpected header's value; index = 4 value = E
Message-ID: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>

Although not reproducible locally or in mach5, some stability fixes have been added in the test like
induce 1s delay after frame is made visible, increase autodelay time, move frame to center of screen and also dispose frame at end.

Modified test pass for several iterations in all platforms. Link in JBS

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

Commit messages:
 - 8305778: javax/swing/JTableHeader/6884066/bug6884066.java: Unexpected header's value; index = 4 value = E
 - 8305778: javax/swing/JTableHeader/6884066/bug6884066.java: Unexpected header's value; index = 4 value = E

Changes: https://git.openjdk.org/jdk/pull/13417/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13417&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305778
  Stats: 61 lines in 1 file changed: 26 ins; 8 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13417/head:pull/13417

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


From psadhukhan at openjdk.org  Tue Apr 11 05:16:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Apr 2023 05:16:31 GMT
Subject: RFR: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on
 Ubunutu 20.04
In-Reply-To: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
References: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
Message-ID: <h6__uCSmyreHhS_1OVJ7VFCRD6skXM2XhEAzUOMFJi0=.35f87b23-9943-40d8-a9e4-19db29fb43c2@github.com>

On Tue, 11 Apr 2023 03:47:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not able to reproduce this locally or in mach5, it can happen when robot key movements start happening before frame is visible,
> so added stability fixes like delay of 1s after frame is visible and key movements are done, added waitForIdle, increase autodelay time, added frame dispose also at end.
> 
> Several iterations of the test pass in all platforms. Link in JBS

@jayathirthrao @TejeshR13 please review

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

PR Comment: https://git.openjdk.org/jdk/pull/13416#issuecomment-1502699211


From psadhukhan at openjdk.org  Tue Apr 11 05:16:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Apr 2023 05:16:31 GMT
Subject: RFR: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java:
 Unexpected header's value; index = 4 value = E
In-Reply-To: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
References: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
Message-ID: <PxOpvXgVdbWTbAkbMxd1X_BadvdeIShxtMMWOIK3-dc=.d47ba75f-f2e1-4c8c-a052-875d8bf8cbc3@github.com>

On Tue, 11 Apr 2023 05:04:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not reproducible locally or in mach5, some stability fixes have been added in the test like
> induce 1s delay after frame is made visible, increase autodelay time, move frame to center of screen and also dispose frame at end.
> 
> Modified test pass for several iterations in all platforms. Link in JBS

@jayathirthrao @TejeshR13 please review

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

PR Comment: https://git.openjdk.org/jdk/pull/13417#issuecomment-1502699280


From jwaters at openjdk.org  Tue Apr 11 06:52:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Apr 2023 06:52:39 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v4]
In-Reply-To: <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 <V1mOqqIoiev_kAYV0lyDKLJ2NaxTA-EzY_DiJkI8hig=.1eeea2af-a281-499e-88bb-2beff4262bc2@github.com>
Message-ID: <-QKehWzWY91LzYWZRQsCO7I-HU7ewzlPBA-c5KvJ7R4=.28f57c31-48fb-463f-8c44-e89e8dcae043@github.com>

On Sat, 8 Apr 2023 13:26:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Legacy Boolean to jboolean conversion

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1502770584


From jwaters at openjdk.org  Tue Apr 11 06:55:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Apr 2023 06:55:46 GMT
Subject: Integrated: 8304717: Declaration aliasing between boolean and jboolean
 is wrong
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: <HgFrHGYAyOYxww4rbZuP2nFrbMMzlerRb3WY9_hReTQ=.dfd79bd1-d29f-4e73-af8b-40b56cbcc00b@github.com>

On Wed, 22 Mar 2023 14:02:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

This pull request has now been integrated.

Changeset: cd7d53c8
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd7d53c88c27eedbe16020b88c2219708d170a1e
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8304717: Declaration aliasing between boolean and jboolean is wrong

Reviewed-by: dholmes

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

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


From aturbanov at openjdk.org  Tue Apr 11 06:57:37 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Apr 2023 06:57:37 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v6]
In-Reply-To: <nnCr_yIK1Nsl3paFZ-0zMFQBXgwoolH5sLVgeJsR5Rc=.44745efd-eb7a-4650-93bf-261851c4a605@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <nnCr_yIK1Nsl3paFZ-0zMFQBXgwoolH5sLVgeJsR5Rc=.44745efd-eb7a-4650-93bf-261851c4a605@github.com>
Message-ID: <tl1pCx0i0Prkilq0X9G4Bxbxk5I-3UeMLrTc4GVb6C8=.f7d327ce-4db0-4e3e-b1b8-157abacf5ebc@github.com>

On Mon, 10 Apr 2023 16:56:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert copyright in unmodified file

src/java.desktop/share/classes/sun/awt/OSInfo.java line 83:

> 81:     }
> 82: 
> 83:     private static final PrivilegedAction<OSType> osTypeAction = new PrivilegedAction<OSType>() {

As this field is not used in production code anymore, I think it makes sense to inline it (allocate directly in `sun.awt.OSInfo#getOSTypeAction`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1162374596


From mkartashev at openjdk.org  Tue Apr 11 07:00:31 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 11 Apr 2023 07:00:31 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions
In-Reply-To: <XQU1NQyEAbM-b12WS0tdHqE7-7HA_J46TQf9B-eQvks=.e3830ddc-3f5a-467f-8c85-09c5406ef718@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <ityXcTPFx_sk-zvzhc2YirLu6pYiFG52e6OfrzYo3MY=.f145f196-2d48-40bc-b7b8-a702d7cbf90e@github.com>
 <xd3PckA6E3d04Ew1THTj0ZlM6cCwOhLiIdVdvAkKHto=.b8537c37-2fe8-4c14-addc-b0a31468106b@github.com>
 <XQU1NQyEAbM-b12WS0tdHqE7-7HA_J46TQf9B-eQvks=.e3830ddc-3f5a-467f-8c85-09c5406ef718@github.com>
Message-ID: <_gPvzRY14JrpeL51c0gL-goMg2Xr3axWTMi0Km4ZlyI=.ca6f5806-1017-47ca-ad36-a816a815e76a@github.com>

On Tue, 11 Apr 2023 00:06:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It would be good to know the exact function to check where it is used.

What was actually measured was the time AWT lock was being held. In `Java_sun_awt_X11GraphicsDevice_pGetBounds()` there are two such places:

                AWT_LOCK();
                xinInfo = (*XineramaQueryScreens)(awt_display, &locNumScr);
                AWT_UNLOCK();

and

            AWT_LOCK ();
            XGetWindowAttributes(awt_display, RootWindow(awt_display, screen),
                    &xwa);
            AWT_UNLOCK ();



While they could take a significant amount of time in a remote X session, I'm sure that the lock fairness and the presence of other operations that could've grabbed the lock are of equal importance. In other words, going further down to either of `XineramaQueryScreens()` or `XGetWindowAttributes()` will not help to isolate the root of the issue because they are but a part of a larger one.

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

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1502777976


From serb at openjdk.org  Tue Apr 11 08:00:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 08:00:33 GMT
Subject: RFR: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java:
 Unexpected header's value; index = 4 value = E
In-Reply-To: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
References: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
Message-ID: <dExCV66_xdGM1bzb6XvAlrpBZQKATuodtyD3Kv70jkE=.1181e6c8-2b8c-4fe7-8210-7c765a9e6d9b@github.com>

On Tue, 11 Apr 2023 05:04:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not reproducible locally or in mach5, some stability fixes have been added in the test like
> induce 1s delay after frame is made visible, increase autodelay time, move frame to center of screen and also dispose frame at end.
> 
> Modified test pass for several iterations in all platforms. Link in JBS

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13417#pullrequestreview-1378656426


From serb at openjdk.org  Tue Apr 11 08:01:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Apr 2023 08:01:32 GMT
Subject: RFR: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on
 Ubunutu 20.04
In-Reply-To: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
References: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
Message-ID: <_pOwx9U_0dAQRoRNJ-52lP5BGh4RtQKU54GgjgSzpgE=.15c3121e-1809-4900-aef2-b6002de4574d@github.com>

On Tue, 11 Apr 2023 03:47:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not able to reproduce this locally or in mach5, it can happen when robot key movements start happening before frame is visible,
> so added stability fixes like delay of 1s after frame is visible and key movements are done, added waitForIdle, increase autodelay time, added frame dispose also at end.
> 
> Several iterations of the test pass in all platforms. Link in JBS

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13416#pullrequestreview-1378657843


From mbaesken at openjdk.org  Tue Apr 11 08:14:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Apr 2023 08:14:34 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <rewC4WntAuLkGWkH9EeCoVmcgxyL_XLO4LFxBrmpubo=.8e7afb34-fb24-4022-b31b-ed666d85347d@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <ysFbtVtG2WDwak7IAICXp_DUltY6HoK6vz08qhaLocg=.4a6e6a1b-7416-4e5a-bc3a-8df4c1b842dd@github.com>
 <Kj6uoZ_oGv1d2JqczqewQroCMQ9JWD8HRkepH9jmq9U=.758e1fa4-ff98-4a36-b05c-9e298178bcdd@github.com>
 <rewC4WntAuLkGWkH9EeCoVmcgxyL_XLO4LFxBrmpubo=.8e7afb34-fb24-4022-b31b-ed666d85347d@github.com>
Message-ID: <pqnVe57FtN1hJGmUL8GyBO00gC7SHwzS5jZw5V5xbKA=.c460b685-d4db-4c15-94a4-cd3c987d3938@github.com>

On Fri, 7 Apr 2023 02:19:29 GMT, Phil Race <prr at openjdk.org> wrote:

>>> @prrace Do you know any news about possibility to bundle some free/open fonts like https://dejavu-fonts.github.io/License.html?
>> 
>> Hi Sergey, this might be a good idea, but as long as it is not decided, should we better track the  'bundled fonts' proposal separately for example in another JBS issue ?
>
>> @prrace Do you know any news about possibility to bundle some free/open fonts like https://dejavu-fonts.github.io/License.html?
> 
> I think it quite unlikely it will get traction.
> Regardless of licensing 3rd party *anything* in JDK is a maintenance task.

> > @prrace Do you know any news about possibility to bundle some free/open fonts like https://dejavu-fonts.github.io/License.html?
> 
> I think it quite unlikely it will get traction. Regardless of licensing 3rd party _anything_ in JDK is a maintenance task.

Thanks for clarifying , so I guess we shouldn't wait for some bundled  default fonts to be included in OpenJDK, otherwise we would maybe wait forever .

> I interpret InternalError as meaning something wrong with the JDK itself, not something in the environment causing a problem, so RTE would be fine here.
> 
> But this NPE is coming from a field (head) that is initialised by code that reads a binary font configuration file. Are you quite sure you've diagnosed the root of the problem ? Or that this message is really in the right place ?
> 
> What does -Dsun.java2d.debugfonts=true reveal ?

Hi Phil, when looking  at the java.desktop  codebase ,  both  RuntimeException and InternalError are used quite a lot for  similar cases.

We had this error on a Linux machine with no fonts,  once some fonts were added the error went away.
I'll try to re-run with the property you suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1502882366
PR Review Comment: https://git.openjdk.org/jdk/pull/13045#discussion_r1162451594


From tr at openjdk.org  Tue Apr 11 10:10:36 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Apr 2023 10:10:36 GMT
Subject: RFR: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on
 Ubunutu 20.04
In-Reply-To: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
References: <fNCwHM5YrDpINuSm6lEbN3SBIaL-VmwYdMewdoWvYPs=.01f65c14-6d66-42f6-b9f4-27d162729d9c@github.com>
Message-ID: <OPZ8Fz-cVsE0HxdkNt-70p8BU5bk--gZ5cnut_Ia1xI=.4b96a1f0-82ff-4cef-a3fc-be0c1b7cd3e9@github.com>

On Tue, 11 Apr 2023 03:47:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not able to reproduce this locally or in mach5, it can happen when robot key movements start happening before frame is visible,
> so added stability fixes like delay of 1s after frame is visible and key movements are done, added waitForIdle, increase autodelay time, added frame dispose also at end.
> 
> Several iterations of the test pass in all platforms. Link in JBS

Looks good to me.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13416#pullrequestreview-1378887349


From mdoerr at openjdk.org  Tue Apr 11 10:18:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 10:18:44 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
Message-ID: <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>

On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused static and import of Stabile

Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.

test/jdk/jdk/internal/util/ArchTest.java line 128:

> 126:             case RISCV64 -> true;
> 127:             case S390 -> false;
> 128:             case PPC64 -> true;

This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1378905956
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162600674


From duke at openjdk.org  Tue Apr 11 10:29:43 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 10:29:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
Message-ID: <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>

On Tue, 11 Apr 2023 10:15:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static and import of Stabile
>
> test/jdk/jdk/internal/util/ArchTest.java line 128:
> 
>> 126:             case RISCV64 -> true;
>> 127:             case S390 -> false;
>> 128:             case PPC64 -> true;
> 
> This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.

This?should (probably) be?correct:
Suggestion:

            case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162614588


From mdoerr at openjdk.org  Tue Apr 11 10:42:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 10:42:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
 <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
Message-ID: <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>

On Tue, 11 Apr 2023 10:26:02 GMT, ExE Boss <duke at openjdk.org> wrote:

>> test/jdk/jdk/internal/util/ArchTest.java line 128:
>> 
>>> 126:             case RISCV64 -> true;
>>> 127:             case S390 -> false;
>>> 128:             case PPC64 -> true;
>> 
>> This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course.
>
> This?should (probably) be?correct:
> Suggestion:
> 
>             case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();

Looks correct, but makes the test pointless for any linux on PPC64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162628828


From duke at openjdk.org  Tue Apr 11 11:53:42 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 11:53:42 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
Message-ID: <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>

On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused static and import of Stabile

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68:

> 66:     // The variables are named to match the Architecture value names, and
> 67:     // the values are named to match the build variables.
> 68:     static final boolean TARGET_ARCH_IS_X64         = "@@OPENJDK_TARGET_CPU@@" == "x86_64";

Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64..

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 82:

> 80:     private static Architecture initArch(String archName) {
> 81:         try {
> 82:             String mapped = switch (archName) {

How about mapping names in the build script instead of at runtime?

I suggest placing only the mapped arch name in `PlatformProps` and moving the `CURRENT_ARCH` to `Architecture`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162686875
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162695586


From rriggs at openjdk.org  Tue Apr 11 16:02:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 16:02:49 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v7]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

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

  Removed unused osTypeAction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/89fe7507..a3334e88

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

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

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


From rriggs at openjdk.org  Tue Apr 11 17:00:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:00:51 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
Message-ID: <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>

On Tue, 11 Apr 2023 11:41:24 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static and import of Stabile
>
> src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68:
> 
>> 66:     // The variables are named to match the Architecture value names, and
>> 67:     // the values are named to match the build variables.
>> 68:     static final boolean TARGET_ARCH_IS_X64         = "@@OPENJDK_TARGET_CPU@@" == "x86_64";
> 
> Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64..

> Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.

Changing os.arch is out of scope for this PR.
The best way for that would someone supporting ppc to develop and propose a PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163098619


From aturbanov at openjdk.org  Tue Apr 11 17:08:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Apr 2023 17:08:39 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v7]
In-Reply-To: <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
Message-ID: <th8KzauLsOsPP_dEQbOjkVoad1KLHcw8poydWoErbLM=.42051cbc-7709-42b4-8ecc-1fc4d41c9e06@github.com>

On Tue, 11 Apr 2023 16:02:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused osTypeAction

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13213#pullrequestreview-1379735205


From rriggs at openjdk.org  Tue Apr 11 17:14:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:14:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <CCDPqtT_cmyHiC5NunYWKPHOe_frC2YuyQT8fyCdjbA=.f4490dd6-261b-4e80-8bb7-c6f8df76f22f@github.com>
 <RAe8ARnMbOWvkONRQ-EcnumPphnKYKuQ_X35Irfgi5E=.d1e942b4-9680-45fa-beec-459247768624@github.com>
 <iyzzD01nOt0xHtg15c6H8wl4mJT54weHKb1yKtZFosc=.0c155c27-8cee-4d80-850a-0f32c4ac209d@github.com>
Message-ID: <0k8KcVp6piijYrt4MpxXyZzVIM_00uf_Zetj14jTBww=.c09aec26-1e32-4e0d-bf2c-8324b1c47a44@github.com>

On Tue, 11 Apr 2023 10:39:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This?should (probably) be?correct:
>> Suggestion:
>> 
>>             case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian();
>
> Looks correct, but makes the test pointless for any linux on PPC64.

Will change to compare `isLittleEndian` with `!Unsafe.isBigEndian()`.
The runtime must match the build time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163112421


From rriggs at openjdk.org  Tue Apr 11 17:58:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 17:58:54 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Modified test to check Architecture is64bits() and isLittleEndian()
  against Unsafe respective values.
  Relocated code mapping OS name and arch name from PlatformProps to
  OperatingSystem and Architecture. Kept the mapping of names
  in the template close to where the values are filled in by the build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/f3646dc9..fc40270a

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

  Stats: 105 lines in 4 files changed: 46 ins; 41 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From mdoerr at openjdk.org  Tue Apr 11 18:04:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 18:04:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
Message-ID: <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>

On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test to check Architecture is64bits() and isLittleEndian()
>   against Unsafe respective values.
>   Relocated code mapping OS name and arch name from PlatformProps to
>   OperatingSystem and Architecture. Kept the mapping of names
>   in the template close to where the values are filled in by the build.

test/jdk/jdk/internal/util/ArchTest.java line 74:

> 72:             case "riscv64" -> RISCV64;  // unverified
> 73:             case "s390x", "s390" -> S390;  // unverified
> 74:             case "ppc64le" -> PPC64;  // unverified

I think "ppc64" should also get mapped to "PPC64".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163161387


From duke at openjdk.org  Tue Apr 11 18:11:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 18:11:45 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <XR6XJ8_PlbaCZwAza-qUVbXKrbA0MGgAuZAjS-x-7DA=.db23097f-f88a-4ebf-9985-124eb2b48af3@github.com>
Message-ID: <fqHaub4apueeoOZAjM1K8NsVUm8YvGvDPtDcUFaLObc=.67df51b2-a2e6-4075-9ebb-c6dac5557be4@github.com>

On Tue, 11 Apr 2023 18:02:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified test to check Architecture is64bits() and isLittleEndian()
>>   against Unsafe respective values.
>>   Relocated code mapping OS name and arch name from PlatformProps to
>>   OperatingSystem and Architecture. Kept the mapping of names
>>   in the template close to where the values are filled in by the build.
>
> test/jdk/jdk/internal/util/ArchTest.java line 74:
> 
>> 72:             case "riscv64" -> RISCV64;  // unverified
>> 73:             case "s390x", "s390" -> S390;  // unverified
>> 74:             case "ppc64le" -> PPC64;  // unverified
> 
> I think "ppc64" should also get mapped to "PPC64".

Suggestion:

            case "ppc64", "ppc64le" -> PPC64;  // unverified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163166827


From mdoerr at openjdk.org  Tue Apr 11 18:11:42 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 18:11:42 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
Message-ID: <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>

On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test to check Architecture is64bits() and isLittleEndian()
>   against Unsafe respective values.
>   Relocated code mapping OS name and arch name from PlatformProps to
>   OperatingSystem and Architecture. Kept the mapping of names
>   in the template close to where the values are filled in by the build.

Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1503861585


From rriggs at openjdk.org  Tue Apr 11 18:35:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 18:35:56 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Add ppc64 as mapping to PPC64 Architecture

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/fc40270a..1c0c0220

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

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

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


From duke at openjdk.org  Tue Apr 11 18:39:41 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 18:39:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
Message-ID: <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>

On Tue, 11 Apr 2023 16:58:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
> 
> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.

It seems that you replied in the wrong place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163192614


From rmahajan at openjdk.org  Tue Apr 11 18:42:52 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 11 Apr 2023 18:42:52 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif image
 to the system clipboard
Message-ID: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>

**Problem:**

On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
Due to this infinite wait the application freezes.

**Proposed Fix:**

There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
After this change I see the GIF image being correctly copied and animated.


**Testing:**

Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

Commit messages:
 - fix executable permission of bug6176679.java
 - fix executable permission of cupanim.gif
 - fix for 6176679

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

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


From jdowland at openjdk.org  Tue Apr 11 19:00:34 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Tue, 11 Apr 2023 19:00:34 GMT
Subject: RFR: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
In-Reply-To: <w8oIBQu84J3t0utf8_aJVoBt-GqHAAXb0DlUwSyTyAY=.fe5e3d6b-2ece-4f93-a63c-51a2e9f52a64@github.com>
References: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
 <w8oIBQu84J3t0utf8_aJVoBt-GqHAAXb0DlUwSyTyAY=.fe5e3d6b-2ece-4f93-a63c-51a2e9f52a64@github.com>
Message-ID: <mnVzF59-DFNo3KkPtIyucNpDsYi1LXX4uJ8GBLg_QeU=.9afa851f-0198-4ba9-9c01-c43b4d93a0c6@github.com>

On Sun, 9 Apr 2023 16:39:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>> 
>> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
>> 
>> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
>> 
>> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.
>
> Seems like a reasonable workaround. Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

@tstuefe wrote:
> Seems like a reasonable workaround.

Thanks for your feedback!

>  Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

I suspect so, because I expect that performance is the reason the simple path was added. I just tried a simple JMH-based benchmark (I'll push the source for the test app somewhere shortly) based on a PDF renderer which relies upon Tracking for correct operation. It's definitely slower with the patch. Without:

    Benchmark       Mode  Cnt     Score     Error  Units
    App.pdfwriter  thrpt   25  6466.086 ? 52.114  ops/s

with:

    Benchmark       Mode  Cnt     Score    Error  Units
    App.pdfwriter  thrpt   25  5894.784 ? 56.380  ops/s

That said; there's fast, and then there's correct...

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

PR Comment: https://git.openjdk.org/jdk/pull/13352#issuecomment-1503936821


From rriggs at openjdk.org  Tue Apr 11 19:37:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 19:37:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
 <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
Message-ID: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>

On Tue, 11 Apr 2023 18:37:11 GMT, Glavo <duke at openjdk.org> wrote:

>>> Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>> 
>> Changing os.arch is out of scope for this PR.
>> The best way for that would someone supporting ppc to develop and propose a PR.
>
>> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>> 
>> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.
> 
> It seems that you replied in the wrong place.

Likely, I misunderstood the request.  Mapping ppc64 to PPC64 is easy enough.
But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms).
For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163241987


From rriggs at openjdk.org  Tue Apr 11 19:37:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 19:37:53 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v9]
In-Reply-To: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <ivxUH1uDXm52YPrc7AuL9jxZaEXFIKQyjEJb9tVJbqc=.52f96949-ab60-48d9-ad13-645f4d030c91@github.com>
 <TmkOpylJOmfV6CpwyF8BsuKjp58iqjv2mjDJROpjHHw=.393f6ba9-eecc-4adf-9f4e-b5abb7aaa8a5@github.com>
 <zVFAPrR8Iq7X2oD8vVoQ3qb97HybmQTnB3kl6EYXMYw=.937e1d6a-7ce4-4d70-94ff-a1ab36c9adb0@github.com>
 <FrhXODydplyZNBZ5bdGY_VGNcfKtCjGcsWj0TepHZPA=.1351c357-4154-4f4a-a140-61699d71b0b9@github.com>
 <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com>
Message-ID: <lrYWDY79fJuwcq5HClpu_BkxWk9K0PBLQrNFkxUQT4Y=.07c3c110-cb4e-4ab0-b000-4eb59a9c6064@github.com>

On Tue, 11 Apr 2023 19:33:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too.
>>> 
>>> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR.
>> 
>> It seems that you replied in the wrong place.
>
> Likely, I misunderstood the request.  Mapping ppc64 to PPC64 is easy enough.
> But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms).
> For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes.

The naming of x86_64 was raised earlier and resolved to use X64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163242850


From duke at openjdk.org  Tue Apr 11 19:53:46 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 11 Apr 2023 19:53:46 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
Message-ID: <D1OneTtxzEudKNyw31h5mn03wsXjpnaOoS6PSRhc-Qs=.13f4fd9d-141e-4b18-b789-a38f9b200f48@github.com>

On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ppc64 as mapping to PPC64 Architecture

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 58:

> 56:         return switch (archName) {
> 57:             case "x86_64" -> "x64";
> 58:             case "ppc64", "ppc64le" -> "ppc64";

There?s?no `case?"s390" ->?"s390"`, so?this is?also?extraneous:
Suggestion:

            case "ppc64le" -> "ppc64";


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

The?`case?"ppc64"` was?supposed to?be?added to?`ArchTest.java`.

test/jdk/jdk/internal/util/ArchTest.java line 74:

> 72:             case "riscv64" -> RISCV64;  // unverified
> 73:             case "s390x", "s390" -> S390;  // unverified
> 74:             case "ppc64le" -> PPC64;  // unverified

Suggestion:

            case "ppc64", "ppc64le" -> PPC64;  // unverified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257592
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257861


From jjg at openjdk.org  Tue Apr 11 20:04:32 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 20:04:32 GMT
Subject: RFR: JDK-8305593: Add @spec tags in java.desktop
In-Reply-To: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
References: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
Message-ID: <dEf1Lb8HpxPFI66ZRuwhNzbkf8gI3C4DpE3K7pdMMo4=.7841775d-a056-4da6-8a7b-af75b7baf8fe@github.com>

On Wed, 5 Apr 2023 17:29:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files

On the use of `rfc-editor.org`, this site came up during the original all-in-one version of this work in PR #11073.
See, for example, these messages:

* https://github.com/openjdk/jdk/pull/11073#issuecomment-1310899778
* https://github.com/openjdk/jdk/pull/11073#issuecomment-1331588069

So, despite being a non-obvious host name, it seems like this is the preferred long-term place to references to RFCs.

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

PR Comment: https://git.openjdk.org/jdk/pull/13360#issuecomment-1504018769


From jjg at openjdk.org  Tue Apr 11 20:14:35 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 20:14:35 GMT
Subject: RFR: JDK-8305593: Add @spec tags in java.desktop
In-Reply-To: <orhhTOWmlvfH2R-T6Q1dSxWZYp8wjGUFG9st6I7QQGg=.30dfdb41-0d68-4ae3-93cb-43cdbf8c2061@github.com>
References: <aUx7scIFFETURSzo__xjG51XS8nLkbhVb-1UE0b-Ciw=.8d646e3e-97de-42cd-9cfd-9b986b1d333c@github.com>
 <orhhTOWmlvfH2R-T6Q1dSxWZYp8wjGUFG9st6I7QQGg=.30dfdb41-0d68-4ae3-93cb-43cdbf8c2061@github.com>
Message-ID: <osxgyi3WwPcrqaKgKdLWQWXIhmvq9XJfT3EnGA8OAo0=.f9141d1b-222b-487f-a39f-9bc56d0d62db@github.com>

On Fri, 7 Apr 2023 01:35:58 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 591:
> 
>> 589:      * subprocess
>> 590:      * @spec https://www.rfc-editor.org/info/rfc2368
>> 591:      *      RFC 2368: The mailto URL scheme
> 
> The javadoc above references ietf.org. This tag references rfc-editor.org. It seems odd to use two different URLs
> in the same method specification for the same RFC. I would have thought the ietf one better to use .. although it should be updated to https

This work is primarily about adding `@spec` tags, in a semi-automated fashion, using a custom utility that scans comments in the public API, looking for `href`s to "well-known" sites hosting external specifications.  While "mostly automated", I did manually cleanup the references by line-wrapping as appropriate.

It is out of scope at this time to cleanup up the underlying `href`s, although we should look at cleaning up those links later, identifying the latest/preferred URL for the appropriate version of the spec document, which may or may not be the latest overall version of the spec. (For example, the client docs reference HTML 3.2, and should not reference anything more recent.). This cleanup can be done later and needs to be done in conjunction with the relevant teams, and probably not as a semi-automated update.   Such cleanup should be somewhat easier once we have tagged the affected comments with the relevant `@spec` tags.

I note that once we have completed the addition of the `@spec` tags, we will, re-enable the new "External Specifications" page, which cross-references where each individual external specification is mentioned in the overall API documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1163273381


From honkar at openjdk.org  Tue Apr 11 20:35:28 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Apr 2023 20:35:28 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
Message-ID: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>

There are a few deprecated Cocoa NSEvent names currently in use in JDK.

https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
https://developer.apple.com/documentation/appkit/nsmousemoved 

Since these event names are marked for deprecation it is better to switch to the newer names.

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

Commit messages:
 - prefix added to commented event types
 - renamed deprecated Cocoa NSEvents

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

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


From prr at openjdk.org  Tue Apr 11 20:42:44 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Apr 2023 20:42:44 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <JNztbq0EjEhCW8KGqmXA1R5WeENFfJ-UtMjZKzQa8lg=.bb001481-9dcb-45f3-99f0-86abe9575787@github.com>

On Tue, 11 Apr 2023 20:28:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

This has been tested in the CI build system, right ? And all tests pass too, right ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13435#issuecomment-1504060756


From mdoerr at openjdk.org  Tue Apr 11 20:46:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Apr 2023 20:46:44 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v11]
In-Reply-To: <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <Df_fXzkh2mDAUGTXbMDqTa_2mVwm_T0DThx1JKvEmVk=.ae3f9b07-2c07-4582-885c-a6163ebe996e@github.com>
Message-ID: <qHaNjGgVAgGT80j3UcOY-_Kda91OXxyqUZ6NdI0R0Vo=.6f7e46f3-79a8-4a4a-9e66-f1d27aab486b@github.com>

On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ppc64 as mapping to PPC64 Architecture

Thanks for the updates! PPC64 looks basically good except of a upper / lower case issue in the test:
STARTED    ArchTest::nameVsCurrent 'nameVsCurrent()'
org.opentest4j.AssertionFailedError: mismatch in Architecture.current vs ppc64 ==> expected: <PPC64> but was: <OTHER>
...
FAILED     ArchTest::nameVsCurrent 'nameVsCurrent()'
JavaTest Message: JUnit Platform Failure(s): 1

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504064549


From prr at openjdk.org  Tue Apr 11 20:50:41 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Apr 2023 20:50:41 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <UOLrRyVCXO-lKYZmM_chLoKLOq5PQNgHD3_cJDI1i-U=.a242fe67-0985-46c7-b225-8eaf206ccaaf@github.com>

On Tue, 11 Apr 2023 20:28:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1002:

> 1000: 
> 1001: - (void)sendEvent:(NSEvent *)event {
> 1002:         if ([event type] == NSLeftMouseDown || [event type] == NSRightMouseDown || [event type] == NSOtherMouseDown) {

since you are touching this, maybe we can format it for better legibility !

if ([event type] == NSEventTypeLeftMouseDown ||
     [event type] == NSEventTypeRightMouseDown ||
     [event type] == NSEventTypeOtherMouseDown))
{

src/java.desktop/macosx/native/libosxui/ScreenMenu.m line 176:

> 174: 
> 175:     switch (kind) {
> 176:         case NSLeftMouseUp: case NSRightMouseUp: case NSOtherMouseUp:

ugh. I've never seen multiple case: clauses on one line.
break these up too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13435#discussion_r1163307493
PR Review Comment: https://git.openjdk.org/jdk/pull/13435#discussion_r1163311354


From honkar at openjdk.org  Tue Apr 11 20:54:37 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Apr 2023 20:54:37 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
In-Reply-To: <JNztbq0EjEhCW8KGqmXA1R5WeENFfJ-UtMjZKzQa8lg=.bb001481-9dcb-45f3-99f0-86abe9575787@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <JNztbq0EjEhCW8KGqmXA1R5WeENFfJ-UtMjZKzQa8lg=.bb001481-9dcb-45f3-99f0-86abe9575787@github.com>
Message-ID: <qx1pvKfHhOklRpjGavvlCG-Ru3Pec8q8r39mGs1Ye4k=.2ff5f283-8f3b-4063-8c8e-fc8427e752a2@github.com>

On Tue, 11 Apr 2023 20:39:56 GMT, Phil Race <prr at openjdk.org> wrote:

> This has been tested in the CI build system, right ? And all tests pass too, right ?

@prrace That is correct Phil, CI testing passes and additionally, I checked by running mouse related tests locally - java/awt/Mouse (since all the NSEvents correspond to mouse events) and they work the same in both cases - before and after the changes. Are there any other set of tests to be cross-checked again to ensure the changes don't break anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/13435#issuecomment-1504074375


From honkar at openjdk.org  Tue Apr 11 20:58:34 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Apr 2023 20:58:34 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <3XgTyT8qoGrri1QVKk3BW43zGG2ybidh-41TCiX2dUw=.f02d499c-c5cd-4b72-abf4-e7b7d1244c27@github.com>

On Tue, 11 Apr 2023 20:28:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

I missed updating the copyright year, will be updating with the rest of the changes in the next commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/13435#issuecomment-1504077872


From rriggs at openjdk.org  Tue Apr 11 21:09:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Apr 2023 21:09:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Correct mapping and test of ppc64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/1c0c0220..71135e3b

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

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

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


From duke at openjdk.org  Tue Apr 11 21:16:46 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 11 Apr 2023 21:16:46 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
Message-ID: <gbjsrOlwH12weOz2XBiXQvHM9fJOqfk9gsX5PWqbGdM=.548facca-e367-4e40-9caf-c8364f7899ca@github.com>

On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mapping and test of ppc64

test/jdk/jdk/internal/util/ArchTest.java line 70:

> 68:             case "x86" -> X86;
> 69:             case "i386" -> X86;
> 70:             case "amd64" -> X64;  // Is alias for X86_64

Suggestion:

            case "x86_64", "amd64" -> X64;
            case "x86", "i386" -> X86;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163340519


From prr at openjdk.org  Tue Apr 11 21:47:33 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 11 Apr 2023 21:47:33 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v2]
In-Reply-To: <uOcQc10SiFfdYmv9CnUnYEeubqsG4x4QgYTlpZq_0hs=.aa85c96b-58ee-4fc7-ba7f-a6de3b99a838@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <uOcQc10SiFfdYmv9CnUnYEeubqsG4x4QgYTlpZq_0hs=.aa85c96b-58ee-4fc7-ba7f-a6de3b99a838@github.com>
Message-ID: <7rgTnFk0DmMT0WnDtjOoQQP2BnGx399rIlKw696lL1E=.68406e9b-dd06-4541-aa5b-19969404e3af@github.com>

On Tue, 11 Apr 2023 03:49:25 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Make sure OffScreenImageSource#addConsumer doesn't throw a NPE if the argument is null.
>    
>    The rationale here is:
>    The preexisting implementation wouldn't throw a NPE, so we shouldn't change that now.
>    
>    (Or more specifically: the preexisting implementation *would* throw a NPE, but it would also catch it and print it to System.err. The caller wouldn't need to anticipate a NPE.)
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Changing `runImageConsumerTest` to make sure we're explicitly testing a `OffScreenImageSource`.
>    
>    By contrast: the `runImageDimensionTest` is more of an integration-style test that *happens* to test the `OffScreenImageSource`.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Adding createAbstractImage() with a little documentation to clarify why we're creating an image the way we are.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Re-adding the 'synchronized' keyword.
>    
>    We can probably do without it now, but I'm just trying to minimize possible unintended side-effects of this PR. Nobody asked for improved multithreaded support. And this class is used to iterate over BufferedImages (which are already in memory), so (as long as the ImageConsumer isn't taking too long -- or blocking) this should be very fast.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    In code review prrace pointed out:
>    > I'd capture "theConsumer" into a local var in each of the methods sendPixel() and produce() and check and use the local var
>    
>    https://github.com/openjdk/jdk/pull/13408#issuecomment-1502348061
>    
>    This is actually my previous/original draft for JDK-4200096 ( 49a49ee8585e8a4b5f33a6af04f2ce0165bf1199 ), but I shied way from this approach because I was afraid code reviewers would point out its changes are excessively invasive for the original complaint. (For ex: now OSIS supports multithreading, which nobody asked for. Should I re-add the `synchronized` method modifiers? (although they are theoretically no longer necessary, keeping them reduces the risk of unintended consequences...) Or if multithreaded support is worth keeping: should I at least add a unit test for it? These questions seemed like they're straying off-topic from the original bug.)
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    In code review mrserb pointed out we shouldn't use System.exit(1) as an error condition.
>    
>    https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

I think I am starting to get the overall picture here.

The fix I cited (4905411) was essentially a fix for 4200096, since it prevented NPEs breaking the app
and was how they chose to avoid the constant null checking. Just catch the NPE and return.
The reasons for the printStackTrace() are not entirely clear. You'd know there something
removed the consumer but not where. FYI I added calls to dumpStack and ran your app
and the test program from 4905411 : java/awt/image/OffScreenImageTest/CropFilterTest.java
and the removal of the consumer can happen in multiple places for multiple reasons.
I can see why "handling" the null was more straightforward than hunting those down
and doing serious re-working of the code.

So
- Perhaps all you really needed to do here was remove the printStackTrace, catching the NPE
is a valid way to handle this if you want to bail as soon as the consumer is removed

- The catch block means that anyone adding new callbacks in here doesn't have to also
   add yet another check. The difference maker would be if ending up with an NPE is really
   common here, and I don't know if it is. If you keep all the null checks then I think
   several in-line comments are warranted.

- I'm back peddling  on continuing with the captured variable. Its a behavioural change.

- I don't understand the reason you are now allowing multiple consumers, nor what
   the consequences would be.

- I note that you are now not allowing someone to add a null consumer.
   I'd wondered why there was no upfront check
   I think this is OK since it looks completely compatible - the null would have been
   immediately de-referenced and the exception thrown.

- I  would definitely keep the synchronized modifiers

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1504137827


From honkar at openjdk.org  Tue Apr 11 23:05:23 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Apr 2023 23:05:23 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v2]
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

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

  copyright year & formatting update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13435/files
  - new: https://git.openjdk.org/jdk/pull/13435/files/291ae4bc..e9b183ea

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

  Stats: 32 lines in 13 files changed: 10 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13435/head:pull/13435

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


From honkar at openjdk.org  Tue Apr 11 23:07:35 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Apr 2023 23:07:35 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v2]
In-Reply-To: <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>
Message-ID: <Kvt7ymTX_CQmrAZoipZxnXyXE-8lxgGh0g40NnL51Mk=.450617ca-bea2-442f-887a-1a8a69fe524f@github.com>

On Tue, 11 Apr 2023 23:05:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
>> 
>> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
>> https://developer.apple.com/documentation/appkit/nsmousemoved 
>> 
>> Since these event names are marked for deprecation it is better to switch to the newer names.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year & formatting update

test/jdk/java/awt/Mouse/MacTouchPressEventModifiers/MouseMacTouchPressEventModifiers.java line 4:

> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2022, JetBrains s.r.o.. All rights reserved.
> 4:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Not sure if we need to have Oracle and JetBrains copyright here? The test is originally contributed by JetBrains team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13435#discussion_r1163410619


From amitkumar at openjdk.org  Wed Apr 12 03:47:43 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 12 Apr 2023 03:47:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
Message-ID: <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>

On Tue, 11 Apr 2023 18:07:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

Martin, only concern was that I didn't have a good experience with `s390x` string in [past](https://github.com/openjdk/jdk/pull/13228#issuecomment-1488599607).  But, I assume that `default` in `mapArchString` will unintentionally handle that scenario here. I tested it, and 'ArchTest.java' also passes.

 I guess @RealLucy might have some pointer over this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504542573


From duke at openjdk.org  Wed Apr 12 04:00:57 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 04:00:57 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v3]
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <pZbn9OXdA0ZL7gLw5IheOX1_LcNjRA44_5HvjDF11uE=.80622288-8785-4cf2-acba-a22d73b69c7f@github.com>

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

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

  4200096: rewrite solution, add LegitimateNullPointerTest
  
  Also I'm breaking out the unit tests (now there are 4 of them) into their own directory.
  
  The new LegitimateNullPointerTest confirms that we DO want to see NullPointerExceptions printed to System.err IF they come from the ImageConsumer itself.
  
  In this ticket most of our focus has been on the NPE's that stem from removing an ImageConsumer from OSIS mid-production (so the NPE was when OSIS tried to interact with its `theConsumer` field). This test tries to add other possible NPE's to our consideration.
  
  This new test passed in the master branch before this branch. I want to preserve this existing behavior if this proposal is accepted.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13408/files
  - new: https://git.openjdk.org/jdk/pull/13408/files/36feaad0..573bdd3a

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

  Stats: 696 lines in 6 files changed: 454 ins; 214 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13408/head:pull/13408

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


From duke at openjdk.org  Wed Apr 12 04:02:35 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 04:02:35 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v2]
In-Reply-To: <uOcQc10SiFfdYmv9CnUnYEeubqsG4x4QgYTlpZq_0hs=.aa85c96b-58ee-4fc7-ba7f-a6de3b99a838@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <uOcQc10SiFfdYmv9CnUnYEeubqsG4x4QgYTlpZq_0hs=.aa85c96b-58ee-4fc7-ba7f-a6de3b99a838@github.com>
Message-ID: <D7fvvPsq7H_3L_8a5J_bsBPEHrkyccA3Vlpg-AnEEvY=.8649608c-ee49-45b4-8469-9c6171248cbd@github.com>

On Tue, 11 Apr 2023 03:49:25 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Make sure OffScreenImageSource#addConsumer doesn't throw a NPE if the argument is null.
>    
>    The rationale here is:
>    The preexisting implementation wouldn't throw a NPE, so we shouldn't change that now.
>    
>    (Or more specifically: the preexisting implementation *would* throw a NPE, but it would also catch it and print it to System.err. The caller wouldn't need to anticipate a NPE.)
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Changing `runImageConsumerTest` to make sure we're explicitly testing a `OffScreenImageSource`.
>    
>    By contrast: the `runImageDimensionTest` is more of an integration-style test that *happens* to test the `OffScreenImageSource`.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Adding createAbstractImage() with a little documentation to clarify why we're creating an image the way we are.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    Re-adding the 'synchronized' keyword.
>    
>    We can probably do without it now, but I'm just trying to minimize possible unintended side-effects of this PR. Nobody asked for improved multithreaded support. And this class is used to iterate over BufferedImages (which are already in memory), so (as long as the ImageConsumer isn't taking too long -- or blocking) this should be very fast.
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    In code review prrace pointed out:
>    > I'd capture "theConsumer" into a local var in each of the methods sendPixel() and produce() and check and use the local var
>    
>    https://github.com/openjdk/jdk/pull/13408#issuecomment-1502348061
>    
>    This is actually my previous/original draft for JDK-4200096 ( 49a49ee8585e8a4b5f33a6af04f2ce0165bf1199 ), but I shied way from this approach because I was afraid code reviewers would point out its changes are excessively invasive for the original complaint. (For ex: now OSIS supports multithreading, which nobody asked for. Should I re-add the `synchronized` method modifiers? (although they are theoretically no longer necessary, keeping them reduces the risk of unintended consequences...) Or if multithreaded support is worth keeping: should I at least add a unit test for it? These questions seemed like they're straying off-topic from the original bug.)
>  - 4200096: OffScreenImageSource.removeConsumer NullPointerException
>    
>    In code review mrserb pointed out we shouldn't use System.exit(1) as an error condition.
>    
>    https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

I don't like the idea of removing `e.printStackTrace()`. For every case we've discussed so far: I agree that sounds good/harmless. But if the ImageConsumer is buggy and ends up throwing its own NullPointerException: then I'd argue developers *need* that NPE printed to the console so they can see what's going on.

I'll add a new (4th) unit test for this condition: I DO expect a NPE from the ImageConsumer to be printed to System.err.

I think what I'm hearing (please correct me if I'm wrong) is: constantly confirming the ImageConsumer is still attached to the OffScreenImageSource hurts readability. So I'll propose a new approach for your consideration shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1504556774


From duke at openjdk.org  Wed Apr 12 04:02:38 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 04:02:38 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v3]
In-Reply-To: <KmingNm_1xGEFr3V0oxdnQTZrNQHzUCULQCi4VLjMDU=.15e67567-bf31-43b1-93d1-7d726b942d15@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <KmingNm_1xGEFr3V0oxdnQTZrNQHzUCULQCi4VLjMDU=.15e67567-bf31-43b1-93d1-7d726b942d15@github.com>
Message-ID: <xwYKl5ih2bJXvAabrp8KOjf3Y98Uaq8so-S9y2-7VFI=.56896e5c-8f81-4a0e-aa54-b7eb763d5086@github.com>

On Tue, 11 Apr 2023 00:10:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4200096: rewrite solution, add LegitimateNullPointerTest
>>   
>>   Also I'm breaking out the unit tests (now there are 4 of them) into their own directory.
>>   
>>   The new LegitimateNullPointerTest confirms that we DO want to see NullPointerExceptions printed to System.err IF they come from the ImageConsumer itself.
>>   
>>   In this ticket most of our focus has been on the NPE's that stem from removing an ImageConsumer from OSIS mid-production (so the NPE was when OSIS tried to interact with its `theConsumer` field). This test tries to add other possible NPE's to our consideration.
>>   
>>   This new test passed in the master branch before this branch. I want to preserve this existing behavior if this proposal is accepted.
>
> test/jdk/sun/awt/image/OffScreenImageSource/bug4200096.java line 49:
> 
>> 47:                 super.println(x);
>> 48:                 if (x instanceof Throwable)
>> 49:                     System.exit(1);
> 
> The tests should not use the System.exit() as it might affect the execution of other tests. It is better to set some flag and check it at the end.

Thanks; this is fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1163569506


From jdv at openjdk.org  Wed Apr 12 04:04:32 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 12 Apr 2023 04:04:32 GMT
Subject: RFR: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java:
 Unexpected header's value; index = 4 value = E
In-Reply-To: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
References: <reY8fueDwwBG-hb5g71kFtRCwsULxus7FDPs_3mECLQ=.a0ea2ecd-6152-472b-aabf-8825e34d4bdb@github.com>
Message-ID: <ugalXOUnZz6GT9Q3bVyj4VTBMun8hsUZ9sNy2xvNLwI=.14bf4b47-a1e1-4c64-b8c6-c12f082e77d1@github.com>

On Tue, 11 Apr 2023 05:04:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although not reproducible locally or in mach5, some stability fixes have been added in the test like
> induce 1s delay after frame is made visible, increase autodelay time, move frame to center of screen and also dispose frame at end.
> 
> Modified test pass for several iterations in all platforms. Link in JBS

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13417#pullrequestreview-1380431060


From jdv at openjdk.org  Wed Apr 12 04:19:33 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 12 Apr 2023 04:19:33 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Instead of using .gif image as input, its better if we can create ImageStream as we do in some of animation tests under test/jdk/javax/imageio/plugins/gif.

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

Changes requested by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1380444337


From prr at openjdk.org  Wed Apr 12 04:45:35 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Apr 2023 04:45:35 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v3]
In-Reply-To: <pZbn9OXdA0ZL7gLw5IheOX1_LcNjRA44_5HvjDF11uE=.80622288-8785-4cf2-acba-a22d73b69c7f@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <pZbn9OXdA0ZL7gLw5IheOX1_LcNjRA44_5HvjDF11uE=.80622288-8785-4cf2-acba-a22d73b69c7f@github.com>
Message-ID: <U7O3hxljy4JXuea9JeulCdywQMpooKfovPd5wuCZT2Y=.ae8061e9-e5ba-4577-a97c-e624f1df1a65@github.com>

On Wed, 12 Apr 2023 04:00:57 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4200096: rewrite solution, add LegitimateNullPointerTest
>   
>   Also I'm breaking out the unit tests (now there are 4 of them) into their own directory.
>   
>   The new LegitimateNullPointerTest confirms that we DO want to see NullPointerExceptions printed to System.err IF they come from the ImageConsumer itself.
>   
>   In this ticket most of our focus has been on the NPE's that stem from removing an ImageConsumer from OSIS mid-production (so the NPE was when OSIS tried to interact with its `theConsumer` field). This test tries to add other possible NPE's to our consideration.
>   
>   This new test passed in the master branch before this branch. I want to preserve this existing behavior if this proposal is accepted.

> I don't like the idea of removing `e.printStackTrace()`. For every case we've discussed so far: I agree that sounds good/harmless. But if the ImageConsumer is buggy and ends up throwing its own NullPointerException: then I'd argue developers _need_ that NPE printed to the console so they can see what's going on.
> 
> I'll add a new (4th) unit test for this condition: I DO expect a NPE from the ImageConsumer to be printed to System.err.

Yes, that's a good point. Just check if consumer is null and if it isn't, then the NPE can't be from de-referemcing
that and should be reported. 

Also note my suggestion from yesterday that the NPE could still be reported if a system property is set.

If you prefer to have more discussion to agreement/clarification before coding up something just to find we revise it again , or if you prefer to code it up and ask "what do you think about this ? ", so there's clarity on what you mean, either is fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1504605358


From dmarkov at openjdk.org  Wed Apr 12 06:49:36 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 12 Apr 2023 06:49:36 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v2]
In-Reply-To: <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>
Message-ID: <xQ6AdmtB6iT_GxLTpdwQ7wpljJ6_hF0hEyYGt4TZo-w=.1eb00e17-6cf0-4e7f-9b48-203ab5753e4c@github.com>

On Tue, 11 Apr 2023 23:05:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
>> 
>> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
>> https://developer.apple.com/documentation/appkit/nsmousemoved 
>> 
>> Since these event names are marked for deprecation it is better to switch to the newer names.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year & formatting update

Changes requested by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13435#pullrequestreview-1380622994


From dmarkov at openjdk.org  Wed Apr 12 06:49:38 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 12 Apr 2023 06:49:38 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v2]
In-Reply-To: <Kvt7ymTX_CQmrAZoipZxnXyXE-8lxgGh0g40NnL51Mk=.450617ca-bea2-442f-887a-1a8a69fe524f@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <eEPoeBO7wGWTGfevvjIi6AvkXa6V_WnOGLVHcKJ9AQ4=.53df9330-d193-4f30-aa66-05d2ac94dde1@github.com>
 <Kvt7ymTX_CQmrAZoipZxnXyXE-8lxgGh0g40NnL51Mk=.450617ca-bea2-442f-887a-1a8a69fe524f@github.com>
Message-ID: <eM7nWD9sL9TSqOe1GXQ1WFkp97aZWBeywRiBhNbIagM=.8cf62d94-b7ef-4570-b161-8609a1209176@github.com>

On Tue, 11 Apr 2023 23:04:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year & formatting update
>
> test/jdk/java/awt/Mouse/MacTouchPressEventModifiers/MouseMacTouchPressEventModifiers.java line 4:
> 
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2022, JetBrains s.r.o.. All rights reserved.
>> 4:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Not sure if we need to have Oracle and JetBrains copyright here? The test was originally contributed by JetBrains team.

IIRC we need both Oracle and JetBrains copyrights here. 

You need to have two years in Oracle copyright: 1st - the year of the initial load; 2nd - the year of the last modification. In other words something like that:
`Copyright (c) 2022, 2023,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13435#discussion_r1163693338


From duke at openjdk.org  Wed Apr 12 08:09:42 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 08:09:42 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v4]
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <zuS7lABruI72lXA7VW1xyy5uF_fB7sEbGgobRxjXDOk=.0cf57c7f-47a7-4e6f-9aae-21a89ca89c48@github.com>

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

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

  4200096: rewrite solution, only print stacktrace if theConsumer != null
  
  I don't like that we're *expecting* a NullPointerException to get thrown in the course of an allowed use case, but that's probably just a preferences on my part. More importantly: this branch passes all new unit tests. Plus it's readable and easy to code review.
  
  This is related to the latest round of PR feedback here:
  https://github.com/openjdk/jdk/pull/13408#issuecomment-1504605358

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13408/files
  - new: https://git.openjdk.org/jdk/pull/13408/files/573bdd3a..1a6c1774

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

  Stats: 90 lines in 1 file changed: 6 ins; 68 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13408/head:pull/13408

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


From duke at openjdk.org  Wed Apr 12 08:17:33 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 08:17:33 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v4]
In-Reply-To: <zuS7lABruI72lXA7VW1xyy5uF_fB7sEbGgobRxjXDOk=.0cf57c7f-47a7-4e6f-9aae-21a89ca89c48@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <zuS7lABruI72lXA7VW1xyy5uF_fB7sEbGgobRxjXDOk=.0cf57c7f-47a7-4e6f-9aae-21a89ca89c48@github.com>
Message-ID: <Vuxer_Ec6-mhS26hjNENOAld2Sy-Bi6-TP1D2S6QPSY=.c1cf1756-dfca-4ce4-9bf2-5c486506711c@github.com>

On Wed, 12 Apr 2023 08:09:42 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4200096: rewrite solution, only print stacktrace if theConsumer != null
>   
>   I don't like that we're *expecting* a NullPointerException to get thrown in the course of an allowed use case, but that's probably just a preferences on my part. More importantly: this branch passes all new unit tests. Plus it's readable and easy to code review.
>   
>   This is related to the latest round of PR feedback here:
>   https://github.com/openjdk/jdk/pull/13408#issuecomment-1504605358

I just pushed an update that uses the null-check for `theConsumer`, but it otherwise still expects the NPE.

Regarding the System property / debugger message:

If we established that removing the listener before production is complete is an OK thing to do, then do you still want this debugger output? (Or to put that another way: do you think that will really get used?) I don't have a lot of experience with debugger output from sun classes, so if you think it's helpful I'll take your word for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/13408#issuecomment-1504854806


From duke at openjdk.org  Wed Apr 12 08:33:28 2023
From: duke at openjdk.org (Jeremy)
Date: Wed, 12 Apr 2023 08:33:28 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v5]
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <eMqgkT15yM1jasSxmxSzuVKw4AZ4ioleY56Hy7ADYJA=.04102920-f75b-408d-8cb1-fb9b593b8ade@github.com>

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

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

  4200096: updating test class header to better describe test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13408/files
  - new: https://git.openjdk.org/jdk/pull/13408/files/1a6c1774..ff469b23

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

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

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


From mdoerr at openjdk.org  Wed Apr 12 09:10:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 12 Apr 2023 09:10:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
Message-ID: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>

On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mapping and test of ppc64

Works on PPC64 Big Endian, now. However, little Endian fails:
org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
	at ArchTest.isArch(ArchTest.java:99)
...
System property os.arch: "ppc64le", Architecture.current(): "PPC64"

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504925182


From martin.desruisseaux at geomatys.com  Wed Apr 12 10:08:20 2023
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Wed, 12 Apr 2023 12:08:20 +0200
Subject: BufferedImage documentation inconsistent with implementation
Message-ID: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>

Hello all

BufferedImage implements WritableRenderedImage, but the javadoc of all 
WritableRenderedImage methods are inconsistent with implementation:

  * getWritableTile(?) said "All registered TileObservers are notified
    when a tile goes from having no writers to having one writer" but
    the implementation doesn't do that.
  * releaseWritableTile(?) said "All registered TileObservers are
    notified when a tile goes from having one writer to having no
    writers" but the implementation does nothing.
  * isTileWritable(?) said "throws ArrayIndexOutOfBoundsException if
    both tileX and tileY are not equal to 0" but the implementation
    throws IllegalArgumentException is *either* tileX or tileY is not 0.
  * addTileObserver(?) and removeTileObserver(?) are no-op, but the
    javadoc don't said that.

Should the javadoc be updated for saying that most methods are actually 
no-op, or should the implementation be updated with real support of 
listeners? Or should BufferedImage be considered as permanently checkout 
out for writing, in which case the current javadoc is not wrong (except 
above-cited throws clause) but a note about the "permanently 
checkout-out" behavior would be helpfui?

 ??? Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230412/67519c0a/attachment.htm>

From lucy at openjdk.org  Wed Apr 12 11:32:43 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 12 Apr 2023 11:32:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v10]
In-Reply-To: <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <i2siBlNCDjWM4dMLLyPL0c8SFGFTODNdJpKTBIxhJy4=.a9b40975-0efd-49b3-b81b-dbc67c58edbb@github.com>
 <mBvcRGaKW5CD2m2iTgeBXJ9S-xkgwdFdkgx5fkCNoVI=.0e483496-7ce0-45e9-9a3c-af79c0c20b95@github.com>
 <gGsAtNpsCBDC_6K6wrgzM3jdMFbOhLl4uKdkma7v-mY=.2eaf5245-84ad-4a44-975f-7a7eb5be4c79@github.com>
Message-ID: <qlw7HUDkrTDgEqpZSJmah0SEu3TEGw9EubDqDO9UX-8=.8dc39fe4-ccad-43bd-9077-73355dc1c7da@github.com>

On Wed, 12 Apr 2023 03:44:45 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look.

zArch_64 is not relevant/not used in the OpenJDK port to IBM System z. As noted elsewhere in the PR, it's the architecture name that was used in the initial, proprietary port by SAP. I found just one occurrence of the string in the head revision, and that was in test/lib/jdk/test/lib/Platform.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505110504


From lucy at openjdk.org  Wed Apr 12 13:05:35 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 12 Apr 2023 13:05:35 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <KAiZNdTj-6zPQdp6Yr27cPXw5fhvA9L79nNqpx3xh30=.ef5af54f-929b-4da6-84bf-671ab9449c69@github.com>

On Wed, 15 Mar 2023 16:02:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

Changes look good to me. 
This is a required fix, even more so because "default fonts" are not even visible on the horizon.
Thanks for fixing.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13045#pullrequestreview-1381272271


From javalists at cbfiddle.com  Wed Apr 12 13:05:50 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 12 Apr 2023 06:05:50 -0700
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
Message-ID: <05B02EC4-A7D4-45CF-86EA-6AE53736F683@cbfiddle.com>

Isn?t there a deeper issue here?

I ran into a problem trying to analyze an image using a filter. The code was waiting for ALLBITS to be reported (as well as ERROR conditions), but for an animated GIF that never happens. I worked around that problem by stopping when a FRAME was reported, which was good enough for my purposes.

I did not see any way to indicate that I did not want an animation or to determine when every frame had been produced once.

Did I miss something?

There are many places where ALLBITS is tested. Are all of these places at risk when operating on an animated GIF?

Implementing animation by simulating an image of infinite size seems like a bad idea, to put it mildly.





> On Apr 11, 2023, at 9:19 PM, Jayathirth D V <jdv at openjdk.org> wrote:
> 
> On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:
> 
>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
> 
> Instead of using .gif image as input, its better if we can create ImageStream as we do in some of animation tests under test/jdk/javax/imageio/plugins/gif.
> 
> -------------
> 
> Changes requested by jdv (Reviewer).
> 
> PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1380444337
> 



From aivanov at openjdk.org  Wed Apr 12 16:12:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Apr 2023 16:12:35 GMT
Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of
 equals() and hashCode()
In-Reply-To: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
References: <mK-fSbmLbOCLXO6cTloNJlYn6PBUrFswiATrPhL-Ado=.c37aa1b9-6ab6-4eec-9c60-759f4a340efa@github.com>
Message-ID: <6v5x6GVcdpOStSB5qACItC3gf-nZtCs8-jJXpNHedcE=.63c7d766-b754-4d56-9160-ed125fccd3ed@github.com>

On Mon, 10 Apr 2023 12:44:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

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

The change looks good but it doesn't address the whole problem raised in the [JDK-7083187](https://bugs.openjdk.org/browse/JDK-7083187): `CSS.CssValue` does not implement `equals`. This fix addresses only one particular case: `CSS.FontSize` for `font-size` property.

I do not think it resolves the problem *entirely*: `CssValue` and all its subclasses must implement `equals` method, otherwise adding another CSS attribute to `AttributeSet` will lead to this same issue described in the bug report.

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

> 2201:         }
> 2202: 
> 2203:         public int hashCode() {

You should add `@Override` annotation and to `equals` method too.

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

> 2211:                 return false;
> 2212:             }
> 2213:             return false;

Suggestion:

            return val instanceof CSS.FontSize size && value == size.value;


I won't insist though.

test/jdk/javax/swing/text/html/CSS/CSSBug.java line 25:

> 23: /*
> 24:  * @test
> 25:  * @key headful

Does it need to be headful?

test/jdk/javax/swing/text/html/CSS/CSSBug.java line 34:

> 32: import javax.swing.text.html.StyleSheet;
> 33: 
> 34: public class CSSBug {

Could this be a more specific name? I believe the agreement is giving descriptive test names, right?

test/jdk/javax/swing/text/html/CSS/CSSBug.java line 47:

> 45: 
> 46:         if (a.isEqual( b) ) {
> 47:             System.out.println( "a equals b");

Could you please the remove the extra spaces after and before the parentheses.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1381636095
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1164340214
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1164341958
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1164342718
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1164344571
PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1164345588


From honkar at openjdk.org  Wed Apr 12 16:13:13 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Apr 2023 16:13:13 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v3]
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <TmvozaY3EmykYggMha6PI5edzn9BDMd2y0_3JLmujPg=.c0a76bb5-9938-4e7c-aa60-e0e9952e3648@github.com>

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

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

  copyright year updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13435/files
  - new: https://git.openjdk.org/jdk/pull/13435/files/e9b183ea..e091a02f

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

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

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


From djelinski at openjdk.org  Wed Apr 12 17:07:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Apr 2023 17:07:40 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v3]
In-Reply-To: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
Message-ID: <fN4VLAicTWrou6GZIGOiDqFI1XheQJfPkQiY1X6I9K0=.94fc71b9-a6f9-47c0-a5f2-4a2345967ce2@github.com>

> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
> 
> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.

Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge remote-tracking branch 'origin' into awt-warning-cleanup
 - Merge remote-tracking branch 'origin' into awt-warning-cleanup
 - Copyright
 - snprintf
 - cl analyze
 - Fix non-debug warning
 - Restore suppressions
 - Fix warnings
 - WIP: reenable awt warnings
 - Fix warnings

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

Changes: https://git.openjdk.org/jdk/pull/11841/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11841&range=02
  Stats: 182 lines in 11 files changed: 1 ins; 120 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/11841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11841/head:pull/11841

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


From rriggs at openjdk.org  Wed Apr 12 17:31:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:31:49 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  Fixed isPPC64().
  Consolidated switch cases in ArchTest.
  Moved mapping of build TARGET_OS and TARGET_CPU to the build
  to avoid multiple mappings in more than one place.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/71135e3b..0cd6ce70

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

  Stats: 60 lines in 5 files changed: 19 ins; 22 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From rriggs at openjdk.org  Wed Apr 12 17:47:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:47:21 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v12]
In-Reply-To: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com>
 <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com>
Message-ID: <lgH5VqlldxKdPQ7Q3wZo1zQgOzdaRLcfLHqrZBMeURs=.782b0827-c6e2-472a-b562-e319b9531cca@github.com>

On Wed, 12 Apr 2023 09:07:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct mapping and test of ppc64
>
> Works on PPC64 Big Endian, now. However, little Endian fails:
> STARTED    ArchTest::isArch '[6] PPC64, false'
> org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: <true> but was: <false>
> 	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> 	at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> 	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> 	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> 	at ArchTest.isArch(ArchTest.java:99)
> ...
> System property os.arch: "ppc64le", Architecture.current(): "PPC64"

@TheRealMDoerr Thanks for the ppc64 feedback and testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505685254


From mdoerr at openjdk.org  Wed Apr 12 18:20:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 12 Apr 2023 18:20:45 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <-7iBud-60uLA3dCL1rKYgWjUok8t7rcMA8XDD2P9RoM=.606c361c-f677-4729-9537-e66c1e1c3ff3@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

Thanks! PPC64 parts look good and the test has passed on both endianness versions.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1381866371


From aivanov at openjdk.org  Wed Apr 12 18:48:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Apr 2023 18:48:08 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
Message-ID: <y4f42_6wRqftZv0gqnWLARnpYfY7ZEPQI71PwRotSS0=.9c87a19f-1ce1-4fa8-b3e6-e9e19bedaa30@github.com>

On Wed, 12 Apr 2023 04:16:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Instead of using .gif image as input, its better if we can create ImageStream as we do in some of animation tests under test/jdk/javax/imageio/plugins/gif.

@jayathirthrao Could you elaborate, please? How is `ImageStream` better than reading from a file directly?
Do you mean that it's better to store the GIF as a byte array or base64-encoded string so that there's no external .gif file? Do you mean generating the GIF by code on the fly? Anything else?

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1505759942


From aivanov at openjdk.org  Wed Apr 12 20:16:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Apr 2023 20:16:46 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <LROt3i8_-Uf80In8lUTxPNLOmvJdBYZBZ4rj-GNplZM=.e2981b3f-9c0b-4b68-8968-a374d2e6c1f8@github.com>

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 1:

> 1: /*

Please update the copyright year to 2023.

src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 112:

> 110:         }
> 111:         int missinginfo = flags & ~availinfo;
> 112:         if ((availinfo & (ImageObserver.ERROR |  ImageObserver.FRAMEBITS) ) == 0 && missinginfo != 0) {

Suggestion:

        if ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0
            && missinginfo != 0) {

The space between the closing parentheses is redundant as well as the extra space after `|` operator. The line could be wrapped to fit into 80-column limit.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 1:

> 1: /*

I think the test should not be in this directory: it does not test the GIF Image IO plugin. A better location is under `java/awt/Clipboard`.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 28:

> 26:  * @key headful
> 27:  * @bug 6176679
> 28:  * @summary Tests that an application doesn't freeze when copying an animated gif image to the system clipboard

Please wrap the line to fit into 80-column limit.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 33:

> 31: 
> 32: import java.awt.*;
> 33: import java.awt.datatransfer.*;

Please expand the wildcard imports.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 40:

> 38: 
> 39: 
> 40: public class bug6176679 implements ClipboardOwner, FlavorListener {

Are `ClipboardOwner` and `FlavorListener` really used? If not, they can be dropped.

The class name should have a descriptive name, like `CopyAnimatedGIFTest`.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 47:

> 45:     private static final CountDownLatch latch = new CountDownLatch(1);
> 46: 
> 47:     volatile static Image img = null;

Please use blessed modifier order: `static volatile`.

I think `img` should not be declared volatile, it's used only on EDT. It may even be non-static because it's accessed only from methods of the test class and you create an instance of it.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 62:

> 60:         panel.add(canvas);
> 61:         frame.add(panel);
> 62:         img = frame.getToolkit().getImage(System.getProperty("test.src", ".") + File.separator + FILENAME);

Could you wrap this long line, please?

The 80-column limit isn't strictly followed, yet it's better to fit into 100-column limit because the code becomes harder to read.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 101:

> 99:             } catch (Exception e) {
> 100:                 throw new RuntimeException(e);
> 101:             }

No checked exception is thrown within this try-block, thus it can be removed.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 111:

> 109:         {
> 110:             EventQueue.invokeAndWait(bug6176679::dispose);
> 111:         }

Suggestion:

        } else {
            EventQueue.invokeAndWait(bug6176679::dispose);
        }


Let's follow Java Coding Style conventions.

I think it also deserves a comment why the frame is disposed of only when the test doesn't fail. Perhaps, we can drop disposing altogether and let jtreg do the cleanup.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 131:

> 129:     }
> 130: 
> 131:     static class imgCanvas extends Canvas {

Suggestion:

    static class ImgCanvas extends Canvas {

Class names should start with a capital letter. Is `ImageCanvas` a better name?

I'd pass the image to the constructor of `ImgCanvas` and mark the `img` field `final` (and `private`). Then the `if` in paint can also be removed.

If the image isn't loaded, that is `img.getWidth()` and `img.getHeight()` return `-1`, the test should bail out before even creating the canvas.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 164:

> 162:                 df[0] = DataFlavor.imageFlavor;
> 163:             }
> 164:         }

You create the instance of `MyTransferable` with the image only, so you can declare the constructor to accept `Image` instead of `Object`.

Would `ImageTransferable` describe the purpose better?

As with the Canvas class above, I'd mark both `img` and `df` as `final` (and `private`).

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 173:

> 171:         public boolean isDataFlavorSupported(DataFlavor flavor) {
> 172:             return true;
> 173:         }

The `@Override` annotation is missing. Add it to `getTransferData` too.

It's not important in this case, yet the method should rather return `df[0].equals(flavor)`.

test/jdk/javax/imageio/plugins/gif/6176679/bug6176679.java line 184:

> 182: 
> 183: 
> 184: }

Please add a final blank line.

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

PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1381935281
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164601058
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164600192
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164573562
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164548806
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164533378
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164548321
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164553188
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164589759
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164554274
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164559765
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164566145
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164567413
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164570631
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1164571335


From aivanov at openjdk.org  Wed Apr 12 20:52:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Apr 2023 20:52:12 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v3]
In-Reply-To: <fN4VLAicTWrou6GZIGOiDqFI1XheQJfPkQiY1X6I9K0=.94fc71b9-a6f9-47c0-a5f2-4a2345967ce2@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <fN4VLAicTWrou6GZIGOiDqFI1XheQJfPkQiY1X6I9K0=.94fc71b9-a6f9-47c0-a5f2-4a2345967ce2@github.com>
Message-ID: <kwDCLP1ZKjr2yOBIWOHMNjXGhsbxsTbq3Eyobh5MjnY=.642569be-1599-438a-a3c6-e7b2117f17e7@github.com>

On Wed, 12 Apr 2023 17:07:40 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Copyright
>  - snprintf
>  - cl analyze
>  - Fix non-debug warning
>  - Restore suppressions
>  - Fix warnings
>  - WIP: reenable awt warnings
>  - Fix warnings

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

> 139:     DISABLED_WARNINGS_gcc_SurfaceData.c := unused-value, \
> 140:     DISABLED_WARNINGS_gcc_TransformHelper.c := sign-compare, \
> 141:     DISABLED_WARNINGS_clang_awt_ImagingLib.c := deprecated-non-prototype, \

I see you declared the functions as `inline`, it was probably the intention for declaring them in the header file.

Did it not resolve `deprecated-non-prototype` warning? If not, did you submit another bug to address it?

src/java.desktop/share/native/common/awt/debug/debug_mem.c line 72:

> 70:  */
> 71: static DMemState         DMemGlobalState;
> 72: const DMemState *        DMemStatePtr = &DMemGlobalState;

As far as all's aligned, should there be another space to align the type names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11841#discussion_r1164620755
PR Review Comment: https://git.openjdk.org/jdk/pull/11841#discussion_r1164619094


From prr at openjdk.org  Wed Apr 12 22:37:33 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Apr 2023 22:37:33 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <WXJBSJDyrdXRKPguEmiQjO8AnJrpQWEpfkB7UNq2yZ8=.b075050a-8e70-419b-bcec-db82052456ed@github.com>

On Mon, 20 Mar 2023 01:07:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

I think the test failures are somewhat spurious,
but the easiest thing to do here is for you to change one line and we'll be OK

< int firstBand = image.getSampleModel().getNumBands() - 1;
> int firstBand = byteRaster.getSampleModel().getNumBands() - 1;

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

PR Comment: https://git.openjdk.org/jdk/pull/13095#issuecomment-1506052136


From prr at openjdk.org  Wed Apr 12 22:41:34 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Apr 2023 22:41:34 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v3]
In-Reply-To: <TmvozaY3EmykYggMha6PI5edzn9BDMd2y0_3JLmujPg=.c0a76bb5-9938-4e7c-aa60-e0e9952e3648@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <TmvozaY3EmykYggMha6PI5edzn9BDMd2y0_3JLmujPg=.c0a76bb5-9938-4e7c-aa60-e0e9952e3648@github.com>
Message-ID: <hyI5Fkwz4K21YlARBrOyh9JRk60sqS5vLY84qbwqHY4=.b7acc290-19c3-49a5-89a1-df5b58fb5093@github.com>

On Wed, 12 Apr 2023 16:13:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
>> 
>> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
>> https://developer.apple.com/documentation/appkit/nsmousemoved 
>> 
>> Since these event names are marked for deprecation it is better to switch to the newer names.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year updated

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13435#pullrequestreview-1382220277


From jdv at openjdk.org  Thu Apr 13 02:15:38 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 13 Apr 2023 02:15:38 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <y4f42_6wRqftZv0gqnWLARnpYfY7ZEPQI71PwRotSS0=.9c87a19f-1ce1-4fa8-b3e6-e9e19bedaa30@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
 <y4f42_6wRqftZv0gqnWLARnpYfY7ZEPQI71PwRotSS0=.9c87a19f-1ce1-4fa8-b3e6-e9e19bedaa30@github.com>
Message-ID: <atDBwNfGj1HyXQj-blCHSnuMy1vxz58nQKSFnhWsHOs=.999d7238-3466-4f39-9889-3baf2d9f22b0@github.com>

On Wed, 12 Apr 2023 18:45:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Instead of using .gif image as input, its better if we can create ImageStream as we do in some of animation tests under test/jdk/javax/imageio/plugins/gif.
> 
> @jayathirthrao Could you elaborate, please? How is `ImageStream` better than reading from a file directly? Do you mean that it's better to store the GIF as a byte array or base64-encoded string so that there's no external .gif file? Do you mean generating the GIF by code on the fly? Anything else?

Yes i mean generating GIF by code and not using .gif file as input.

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1506227030


From rmahajan at openjdk.org  Thu Apr 13 04:22:36 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 13 Apr 2023 04:22:36 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <39dWCtmwI-IBfdV7HnmFjRy9Pf2wcY61l-TG6KMSY2Q=.6051cef6-f154-4dbe-a218-06590c01ff0e@github.com>

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

> 
Will the generated GIF file be animated ?, because this only happens with animated GIFs. 
And why is it better than having the GIF file itself ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1506321011


From jdv at openjdk.org  Thu Apr 13 04:57:44 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 13 Apr 2023 04:57:44 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <39dWCtmwI-IBfdV7HnmFjRy9Pf2wcY61l-TG6KMSY2Q=.6051cef6-f154-4dbe-a218-06590c01ff0e@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <39dWCtmwI-IBfdV7HnmFjRy9Pf2wcY61l-TG6KMSY2Q=.6051cef6-f154-4dbe-a218-06590c01ff0e@github.com>
Message-ID: <qT5cONahbZSHtJh7V47Xh6UxjJ5Cawr4AnajnRn_PI0=.736a00b0-af2d-4e43-9215-eba543bf97ea@github.com>

On Thu, 13 Apr 2023 04:19:50 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> > 
> 
> Will the generated GIF file be animated ?, because this only happens with animated GIFs. And why is it better than having the GIF file itself ?

As previously mentioned we have animation tests for GIF under test/jdk/javax/imageio/plugins/gif which don't use GIF file input.
We try to avoid adding new image file to JDK repo whenever we have some ImageIO test because it increases the size, so its better to use stream or create and delete temp file in regression tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1506343936


From stuefe at openjdk.org  Thu Apr 13 06:08:41 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Apr 2023 06:08:41 GMT
Subject: RFR: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
In-Reply-To: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
References: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
Message-ID: <os3F6jmbcDCdd5D38daakH1fpqQBE4G-x30bK6zASD8=.b749d96d-060e-4f03-9e60-3aef2bab0409@github.com>

On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
> 
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
> 
> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
> 
> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.

This is fine as a workaround. If we find the root cause of this problem we can remove it.

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13352#pullrequestreview-1382688383


From dmarkov at openjdk.org  Thu Apr 13 06:14:35 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Thu, 13 Apr 2023 06:14:35 GMT
Subject: RFR: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names [v3]
In-Reply-To: <TmvozaY3EmykYggMha6PI5edzn9BDMd2y0_3JLmujPg=.c0a76bb5-9938-4e7c-aa60-e0e9952e3648@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
 <TmvozaY3EmykYggMha6PI5edzn9BDMd2y0_3JLmujPg=.c0a76bb5-9938-4e7c-aa60-e0e9952e3648@github.com>
Message-ID: <JMdQ5Keni9NXzOtjLtWaGebsD91aJ-ivQuG2q1TPdWs=.bec84f69-6063-43c3-9b91-2a3cce98eb04@github.com>

On Wed, 12 Apr 2023 16:13:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
>> 
>> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
>> https://developer.apple.com/documentation/appkit/nsmousemoved 
>> 
>> Since these event names are marked for deprecation it is better to switch to the newer names.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year updated

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13435#pullrequestreview-1382697158


From djelinski at openjdk.org  Thu Apr 13 07:13:39 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Apr 2023 07:13:39 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v4]
In-Reply-To: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
Message-ID: <ukRZpfZ94L-5qtmocNs5CVEQOTQC7H52V0boscrdAGY=.56f3db77-bf6d-478f-a096-2c183fd6ccb2@github.com>

> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
> 
> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.

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

  Align type names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11841/files
  - new: https://git.openjdk.org/jdk/pull/11841/files/54cd307d..35413909

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

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

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


From djelinski at openjdk.org  Thu Apr 13 07:13:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Apr 2023 07:13:44 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v3]
In-Reply-To: <kwDCLP1ZKjr2yOBIWOHMNjXGhsbxsTbq3Eyobh5MjnY=.642569be-1599-438a-a3c6-e7b2117f17e7@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <fN4VLAicTWrou6GZIGOiDqFI1XheQJfPkQiY1X6I9K0=.94fc71b9-a6f9-47c0-a5f2-4a2345967ce2@github.com>
 <kwDCLP1ZKjr2yOBIWOHMNjXGhsbxsTbq3Eyobh5MjnY=.642569be-1599-438a-a3c6-e7b2117f17e7@github.com>
Message-ID: <l_2ta4tca7nW4nplf0Alrh3niynzgXxDZcdI6_X6ijk=.fc383e98-19c3-4a80-840c-b3e3938e71c1@github.com>

On Wed, 12 Apr 2023 20:29:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>>  - Copyright
>>  - snprintf
>>  - cl analyze
>>  - Fix non-debug warning
>>  - Restore suppressions
>>  - Fix warnings
>>  - WIP: reenable awt warnings
>>  - Fix warnings
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 141:
> 
>> 139:     DISABLED_WARNINGS_gcc_SurfaceData.c := unused-value, \
>> 140:     DISABLED_WARNINGS_gcc_TransformHelper.c := sign-compare, \
>> 141:     DISABLED_WARNINGS_clang_awt_ImagingLib.c := deprecated-non-prototype, \
> 
> I see you declared the functions as `inline`, it was probably the intention for declaring them in the header file.
> 
> Did it not resolve `deprecated-non-prototype` warning? If not, did you submit another bug to address it?

Thanks for reviewing!

I didn't see the warning in mach5 build. However, the warning was not related to inline declarations. See [JDK-8300169](https://bugs.openjdk.org/browse/JDK-8300169) where the warning was reported; the compiler complained that `sMlibFns.fptr` does not have a prototype. See the declaration:
https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.h#L35
I'm pretty sure that given the right compiler, the warning would still appear.

After I filed the ticket for this change, I found [JDK-8074823](https://bugs.openjdk.org/browse/JDK-8074823); let's use that to keep track of the remaining warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11841#discussion_r1165095236


From jdowland at openjdk.org  Thu Apr 13 10:50:34 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 13 Apr 2023 10:50:34 GMT
Subject: RFR: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
In-Reply-To: <w8oIBQu84J3t0utf8_aJVoBt-GqHAAXb0DlUwSyTyAY=.fe5e3d6b-2ece-4f93-a63c-51a2e9f52a64@github.com>
References: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
 <w8oIBQu84J3t0utf8_aJVoBt-GqHAAXb0DlUwSyTyAY=.fe5e3d6b-2ece-4f93-a63c-51a2e9f52a64@github.com>
Message-ID: <NNCJMlt2KC2gJdcgdtfKFyUtIVsIBF9cPp1LzZ6ZrLY=.756a27e4-e036-44ec-8f5a-e420414a947d@github.com>

On Sun, 9 Apr 2023 16:39:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>> 
>> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
>> 
>> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
>> 
>> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.
>
> Seems like a reasonable workaround. Would there be any measurable performance impacts by going the more complex route with Tracking != 0?

Thanks @tstuefe

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

PR Comment: https://git.openjdk.org/jdk/pull/13352#issuecomment-1506749935


From jdowland at openjdk.org  Thu Apr 13 12:05:53 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 13 Apr 2023 12:05:53 GMT
Subject: Integrated: 8304350: Font.getStringBounds calculates wrong width for
 TextAttribute.TRACKING other than 0.0
In-Reply-To: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
References: <Wej0QGzodq7XHy0WXYyCOfS31YK6PiWdZRLlpVF-3yE=.d0c4cfff-22bf-4c88-84d4-77c835251674@github.com>
Message-ID: <0Lb6FqNSDuVODZ-V648tT4gSyWtq-_0f6TQnlwEV9SU=.7a392a28-c229-42e0-8f6b-bde8d90e03c4@github.com>

On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
> 
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a heuristic to determine whether the question it's answering is "simple" or not. The bug described in 8304350 only occurs in the simple=true branch.
> 
> Extend the "simple?" heuristic to consider a tracking attribute not-simple and to use the complex branch in those cases.
> 
> One could argue that the root bug still exists: the simple path goes on to delegate to `sun.font.FontDesignMetrics.getMetrics(Font,FontRenderContext)`, although that's a private/internal API.

This pull request has now been integrated.

Changeset: 6b9b7d1d
Author:    Jonathan Dowland <jdowland at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b9b7d1d921367418f82c2813b272d3447a47595
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8304350: Font.getStringBounds calculates wrong width for TextAttribute.TRACKING other than 0.0

Reviewed-by: stuefe

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

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


From dcherepanov at openjdk.org  Thu Apr 13 13:11:53 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Thu, 13 Apr 2023 13:11:53 GMT
Subject: RFR: 6995195: Static initialization deadlock in sun.java2d.loops.Blit
 and GraphicsPrimitiveMgr
Message-ID: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>

This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.

This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

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

Commit messages:
 - deadlock fix

Changes: https://git.openjdk.org/jdk/pull/13459/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13459&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6995195
  Stats: 155 lines in 10 files changed: 113 ins; 33 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13459/head:pull/13459

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


From mkartashev at openjdk.org  Thu Apr 13 15:26:43 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Apr 2023 15:26:43 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v2]
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <Ui4PIh2Sp4ucU1v6OBtEVBCNew5VR7DZnK5yMhzZqlk=.4d325735-d8ca-4d24-a641-1ecf8656a5d8@github.com>

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

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

  Added X11GraphicsDevice.bounds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13346/files
  - new: https://git.openjdk.org/jdk/pull/13346/files/55da2240..eb625b28

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

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

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


From honkar at openjdk.org  Thu Apr 13 15:31:15 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Apr 2023 15:31:15 GMT
Subject: Integrated: JDK-8305712: [MacOS] Deprecated Cocoa-NSEvent names
In-Reply-To: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
References: <aeazuC0571XlVd8zN4-Is3O4GjMXirnB4h9xB3XfxE4=.a9046a67-35ae-4264-9a51-94ca8a4669b8@github.com>
Message-ID: <Jib4PzMoaQzdus-ERgEMUshWHXq3e5bCVcrDCaPLxpE=.91875b14-c7b0-4950-bd0c-ab51ba8b3a0b@github.com>

On Tue, 11 Apr 2023 20:28:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are a few deprecated Cocoa NSEvent names currently in use in JDK.
> 
> https://github.com/openjdk/jdk/blob/jdk-21+17/src/java.desktop/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
> https://developer.apple.com/documentation/appkit/nsmousemoved 
> 
> Since these event names are marked for deprecation it is better to switch to the newer names.

This pull request has now been integrated.

Changeset: d7dc474a
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7dc474a5aa29da7f6a0d9c0fd872243c4d82e3c
Stats:     116 lines in 13 files changed: 10 ins; 0 del; 106 mod

8305712: [MacOS] Deprecated Cocoa-NSEvent names

Reviewed-by: dmarkov, prr

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

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


From mkartashev at openjdk.org  Thu Apr 13 15:31:59 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Apr 2023 15:31:59 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v2]
In-Reply-To: <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
Message-ID: <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>

On Tue, 11 Apr 2023 00:09:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added X11GraphicsDevice.bounds
>
> src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 881:
> 
>> 879:     }
>> 880: 
>> 881:     private final Hashtable<GraphicsConfiguration, Insets> cachedInsets = new Hashtable<>();
> 
> You do not need to create a handcrafted list of gc->insets, but instead, you can save that information directly in the GC. In that case, each GC should be added as a listener(DisplayChangedListener) to the SGE. I think the same should be done for the GD+bounds, see how it is implemented on macOS(CGraphicsDevice#displayChanged)

I did what you suggested to `X11GraphicsDevice.bounds`; please, take a look.

As for insets, it is more complicated because they may change without `displayChanged()` being called; this happens when, for example, the size of the dock bar changes. We are notified of the `_NET_WORKAREA` property change for the root window that is not accompanied by the ConfigureNotify event. I'm reluctant to send `displayChanged()` in this case; it seems like an overkill for a change in the work area.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1165704393


From mkartashev at openjdk.org  Thu Apr 13 15:37:29 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Apr 2023 15:37:29 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v3]
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <vAmv1J1Gk7SpXT2PAibBrnuNG3zL5fVh27N_v39048Q=.46249abd-c29a-46f8-b95b-5f691c0129d7@github.com>

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

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

  Reverted the copyright year in X11GraphicsEnvironment.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13346/files
  - new: https://git.openjdk.org/jdk/pull/13346/files/eb625b28..670df083

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

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

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


From aturbanov at openjdk.org  Thu Apr 13 15:37:32 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 15:37:32 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <cJKzKw8ICqGLOz6ZHDivxpo3lNsaDQrYwyMwwt1xYaI=.384cf1a7-ddc0-4d34-aadc-a15bbe6e73ea@github.com>

On Thu, 13 Apr 2023 13:03:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java line 270:

> 268:         }
> 269: 
> 270:         static GraphicsPrimitive locate(int primTypeID) {

it should be marked as `synchronized` too. Otherwise there will possible data race between other thread called `register`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1165711469


From aivanov at openjdk.org  Thu Apr 13 16:52:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Apr 2023 16:52:39 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <KtslimI1PJDXjxDYU_7z6iPTTNVgZpT0WEl6xhLoPDA=.98ecdbfa-9798-4016-baa8-0afb6893d829@github.com>

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

> > Yes i mean generating GIF by code and not using .gif file as input.
>
> Will the generated GIF file be animated ?, because this only happens with animated GIFs. And why is it better than having the GIF file itself ?

It should if you create several frames.

There's always an option to create another GIF image, smaller, and use its byte or base64 representation as the source.

> We try to avoid adding new image file to JDK repo whenever we have some ImageIO test because it increases the size, so its better to use stream or create and delete temp file in regression tests.

Okay, now it's clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1507282776


From alexey.ivanov at oracle.com  Thu Apr 13 18:19:07 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Thu, 13 Apr 2023 19:19:07 +0100
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <05B02EC4-A7D4-45CF-86EA-6AE53736F683@cbfiddle.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <Una08K9inQNlkL7bstaTkB-sQIu4SORRVYaooVto8DY=.626e48ed-f96f-47af-bb1f-36744d0aa67c@github.com>
 <05B02EC4-A7D4-45CF-86EA-6AE53736F683@cbfiddle.com>
Message-ID: <10f982b9-ef3d-8c63-be82-16e6634a812f@oracle.com>

Hi Alan,

On 12/04/2023 14:05, Alan Snyder wrote:
> Isn?t there a deeper issue here?
>
> I ran into a problem trying to analyze an image using a filter. The code was waiting for ALLBITS to be reported (as well as ERROR conditions), but for an animated GIF that never happens. I worked around that problem by stopping when a FRAME was reported, which was good enough for my purposes.

This is what this fix does: ALLBITS is never set for animated images, so 
FRAMEBITS is also added.

> I did not see any way to indicate that I did not want an animation or to determine when every frame had been produced once.

In the test code, when MediaTracker.waitForAll() returns, which 
indicates the image is loaded completely, only WIDTH, HEIGHT and 
PROPERTIES bits are set. FRAMEBITS bit is set only after the image 
starts animating.

> Did I miss something?
>
> There are many places where ALLBITS is tested. Are all of these places at risk when operating on an animated GIF?

I did a quick search for ALLBITS, I can see both FRAMEBITS | ALLBITS are 
used in many places; however, there are quite a few places in the code 
where ALLBITS is used exclusively, it may cause issues if used with 
animated images.

> Implementing animation by simulating an image of infinite size seems like a bad idea, to put it mildly.
>
>
>> <SNIP>
-- 
Regards,
Alexey


From aivanov at openjdk.org  Thu Apr 13 20:13:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Apr 2023 20:13:34 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <mHI0mFpiDez5EaetBXwXhW2RHfl6JCYhsEPxNx2d-aA=.51ebb9c2-4bec-49db-8d34-4aa860774a8e@github.com>

On Wed, 15 Mar 2023 16:02:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

I reproduced this exception on a system where FontConfig library is installed yet no fonts are present.

It looks like Java can't or doesn't create its own `fontconfig.properties` file in such a case, which results in the exception from the PR description. Yet if I pass a dummy `fontconfig.properties` with `-Dsun.awt.fontconfig=/path/fontconfig.properties`, the exception isn't thrown.

For example,

$ fc-list

$ ./jdk-17.0.6/bin/java ListFonts
Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException
        at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
        ...
Caused by: java.lang.reflect.InvocationTargetException
        ...
Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
        at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
        at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
        at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
        at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
        at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
        at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
        at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
        at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
        at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
        ... 13 more

$ ./jdk-21/bin/java ListFonts
Exception in thread "main" java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
        at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1256)
        at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:221)
        at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:105)
        at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:696)
        at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:352)
        at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:309)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:309)
        at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
        at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:55)
        at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
        at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:137)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:171)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:195)
        at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:80)
        at ListFonts.main(ListFonts.java:8)



With explicit `fontconfig.properties`:


$ ./jdk-17.0.6/bin/java -Dsun.awt.fontconfig=~/fontconfig.properties ListFonts
Dialog
DialogInput
Monospaced
SansSerif
Serif

$ ./jdk-21/bin/java -Dsun.awt.fontconfig=~/fontconfig.properties ListFonts
Dialog
DialogInput
Monospaced
SansSerif
Serif


The sample app `ListFonts.java`:

import java.awt.GraphicsEnvironment;
import java.util.Arrays;

public class ListFonts {
    public static void main(String[] args) {
        Arrays.stream(GraphicsEnvironment
                      .getLocalGraphicsEnvironment()
                      .getAvailableFontFamilyNames())
              .forEach(System.out::println);
    }
}


The dummy `fontconfig.properties`:

version=1
sequence.allfonts=default


With Matthias's fix, the message in the exception is clearer:

$ ./jdk-21-fix/jdk-21/bin/java ListFonts
Exception in thread "main" java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration
        at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
        at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:223)
        ...


As with the cases above, passing `fontconfig.properties` explicitly, resolves the problem, and the logical fonts get listed.

Obviously, I get another error if I try rendering the text:

Exception in thread "main" java.lang.Error: Probable fatal error: No physical fonts found.
        at java.desktop/sun.font.SunFontManager.lambda$getDefaultPhysicalFont$0(SunFontManager.java:1034)
        at java.base/java.util.Optional.orElseThrow(Optional.java:403)
        ...


A clearer error message was added by [JDK-8221741](https://bugs.openjdk.org/browse/JDK-8221741).

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1507552539


From aivanov at openjdk.org  Thu Apr 13 20:17:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Apr 2023 20:17:41 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <nsRjxTimwK0BcFTL_QYHL9FGG3y0MU24ZCWMoc65aBU=.97c68aba-7f6a-45e9-9347-7fc91f58cb8f@github.com>

On Wed, 15 Mar 2023 16:02:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

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

> 1253:     public String getExtraFontPath() {
> 1254:         if (head == null) {
> 1255:             throw new RuntimeException("Fontconfig head is null, check your fonts or fonts configuration");

Does it make sense to create a String constant for the error message?

I understand that there's only one instance of the message in the class file, it's more to avoid duplication and to avoid having different error messages in case someone updates only one of them.

Other than that, it looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13045#discussion_r1165983401


From rriggs at openjdk.org  Thu Apr 13 20:19:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 20:19:40 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v3]
In-Reply-To: <ibKyw4m_rkLGsfMvIz16cWrtBDSBSw4zbEbUFfEFCGg=.9485f7ad-29fe-4731-a7d5-5c191f4ac0e0@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <bLUsfHRG5yBfdkTbs-Vez207p2cYxUlFDakcAaXB1Hg=.0817ffbc-5013-4ba9-ba3a-acbcf85915c9@github.com>
 <ibKyw4m_rkLGsfMvIz16cWrtBDSBSw4zbEbUFfEFCGg=.9485f7ad-29fe-4731-a7d5-5c191f4ac0e0@github.com>
Message-ID: <FbvN1BnEXGCZiw1UstcGpRDRFEYxQxvZN4dBm9vFqa0=.c270d501-5476-447e-b264-833837e35b85@github.com>

On Fri, 7 Apr 2023 01:45:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>>   Replaced a few more uses of os.name.
>
> So if we want to get rid of all the getProperty (etc) calls and unify it then  the way I'd prefer to do this is via a single channel inside the desktop module.
> So change everything to use that pre-existing sun.awt.OSInfo class.
> Modifying that as necessary. Then that class can be the SINGLE place that has a direct dependency on this java.base internal and we can more easily drop it if required.
> Meanwhile I also think there's a better than 50:50 chance someone will add new uses of System.getProperty .. whatever the solution is. So whack-a-mole-away.

@prrace Please review

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

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1507561152


From prr at openjdk.org  Thu Apr 13 20:41:38 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Apr 2023 20:41:38 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v7]
In-Reply-To: <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
Message-ID: <OQ1dCTp51XpLbjaaTO32t-pWWahzvJzz_5mC14t8roA=.dc733236-2603-45d4-bd3b-ae4bdba3bd8b@github.com>

On Tue, 11 Apr 2023 16:02:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused osTypeAction

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13213#pullrequestreview-1384168004


From duke at openjdk.org  Thu Apr 13 20:41:41 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 13 Apr 2023 20:41:41 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v7]
In-Reply-To: <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <MbX746wX5P_LegbF3EoH6kvr_Y_I4A5q6eY4OkE6UUo=.ff534a65-201c-4050-aff5-badeefa62705@github.com>
Message-ID: <5SQTOZ9AgfrjEBAs5eJUFLklbgwrvL7mccjrCTYF7M4=.591eb4a7-ff8b-480b-913c-2fccce46d237@github.com>

On Tue, 11 Apr 2023 16:02:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused osTypeAction

src/java.desktop/share/classes/javax/swing/PopupFactory.java line 1:

> 1: /*

https://github.com/openjdk/jdk/blob/a3334e88440eb576943e20daa7d5ee8f824d1290/src/java.desktop/share/classes/javax/swing/PopupFactory.java#L42

This import is no longer used.

src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java line 1:

> 1: /*

https://github.com/openjdk/jdk/blob/a3334e88440eb576943e20daa7d5ee8f824d1290/src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java#L353-L359

This method is no longer used.

src/java.desktop/share/classes/sun/awt/OSInfo.java line 31:

> 29: 
> 30: import java.security.AccessController;
> 31: import java.security.PrivilegedAction;

These imports are no longer used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1165996747
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1165998850
PR Review Comment: https://git.openjdk.org/jdk/pull/13213#discussion_r1166000312


From prr at openjdk.org  Thu Apr 13 20:51:37 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Apr 2023 20:51:37 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v5]
In-Reply-To: <eMqgkT15yM1jasSxmxSzuVKw4AZ4ioleY56Hy7ADYJA=.04102920-f75b-408d-8cb1-fb9b593b8ade@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <eMqgkT15yM1jasSxmxSzuVKw4AZ4ioleY56Hy7ADYJA=.04102920-f75b-408d-8cb1-fb9b593b8ade@github.com>
Message-ID: <82bWrzRL0XLOt1Wz12EWp3QxbUBggwizbj7qJGn4VDc=.0c0cbe67-6a71-4822-80d6-421365bbf0ce@github.com>

On Wed, 12 Apr 2023 08:33:28 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4200096: updating test class header to better describe test

I mean before pushing.

src/java.desktop/share/classes/sun/awt/image/OffScreenImageSource.java line 178:

> 176:                 }
> 177:                 theConsumer.setPixels(0, y, width, 1, newcm, scanline, 0,
> 178:                         width);

can we revert the white space changes ?

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13408#pullrequestreview-1384184811
PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1164740594


From serb at openjdk.org  Thu Apr 13 21:24:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Apr 2023 21:24:30 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13 [v2]
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <WwVDDzOehZz7VE4ARo7gsMhbmrLoBrxrCZB2_trcG-k=.80ee0868-6311-46c9-9df2-eb41fcbfee6a@github.com>

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

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

  SkipSampleModel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13095/files
  - new: https://git.openjdk.org/jdk/pull/13095/files/c4ff2a6b..e5e012da

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

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

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


From aivanov at openjdk.org  Thu Apr 13 21:27:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Apr 2023 21:27:34 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v4]
In-Reply-To: <ukRZpfZ94L-5qtmocNs5CVEQOTQC7H52V0boscrdAGY=.56f3db77-bf6d-478f-a096-2c183fd6ccb2@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <ukRZpfZ94L-5qtmocNs5CVEQOTQC7H52V0boscrdAGY=.56f3db77-bf6d-478f-a096-2c183fd6ccb2@github.com>
Message-ID: <9KagmgHmIFe5QNNOvzNWJ4Mm1OkBQQPztT6GVIV-8RY=.cd9db4de-445b-4f00-84c5-42f41f65d231@github.com>

On Thu, 13 Apr 2023 07:13:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align type names

Looks good to me.

I ran builds and automated client tests, no failures detected.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11841#pullrequestreview-1384243352


From duke at openjdk.org  Thu Apr 13 21:34:34 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Thu, 13 Apr 2023 21:34:34 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <XaNsL8HP1y8Ks7bol7w4PCql0JGfUDmsww0kGMwqbu0=.efb7d888-c643-4062-a014-69d22f0ab1c1@github.com>

On Thu, 13 Apr 2023 13:03:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java line 281:

> 279:             }
> 280:             return null;
> 281:             //throw new InternalError("No general handler registered for"+signature);

This line can be deleted if no longer needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1166050310


From philip.race at oracle.com  Thu Apr 13 21:38:20 2023
From: philip.race at oracle.com (Philip Race)
Date: Thu, 13 Apr 2023 14:38:20 -0700
Subject: BufferedImage documentation inconsistent with implementation
In-Reply-To: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>
References: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>
Message-ID: <e33579f0-ee9b-45a4-14c8-15cfa780f1bc@oracle.com>

A BufferedImage is a single always writable Tile.

The method that is most questionable is releaseWritableTile(int, int) 
being a no-op.
It doesn't even throw an AAIOB if you pass in something other than (0,0)
It probably should have a clause

"This method is a no-op and immediately returns without checking the 
passed values
since a BufferedImage has only a single tile which is always writable."

The observer methods could also benefit from doc that observers will 
never be added or
removed (no-op methods) since there will never any events to dispatch.
So there's no point in adding real support for listeners.

I think the doc on isTileWritable is well-intentioned but not well-worded.

-phil


On 4/12/23 3:08 AM, Martin Desruisseaux wrote:
>
> Hello all
>
> BufferedImage implements WritableRenderedImage, but the javadoc of all 
> WritableRenderedImage methods are inconsistent with implementation:
>
>   * getWritableTile(?) said "All registered TileObservers are notified
>     when a tile goes from having no writers to having one writer" but
>     the implementation doesn't do that.
>   * releaseWritableTile(?) said "All registered TileObservers are
>     notified when a tile goes from having one writer to having no
>     writers" but the implementation does nothing.
>   * isTileWritable(?) said "throws ArrayIndexOutOfBoundsException if
>     both tileX and tileY are not equal to 0" but the implementation
>     throws IllegalArgumentException is *either* tileX or tileY is not 0.
>   * addTileObserver(?) and removeTileObserver(?) are no-op, but the
>     javadoc don't said that.
>
> Should the javadoc be updated for saying that most methods are 
> actually no-op, or should the implementation be updated with real 
> support of listeners? Or should BufferedImage be considered as 
> permanently checkout out for writing, in which case the current 
> javadoc is not wrong (except above-cited throws clause) but a note 
> about the "permanently checkout-out" behavior would be helpfui?
>
> ??? Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230413/62ee5130/attachment.htm>

From serb at openjdk.org  Thu Apr 13 22:34:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Apr 2023 22:34:32 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13
In-Reply-To: <WXJBSJDyrdXRKPguEmiQjO8AnJrpQWEpfkB7UNq2yZ8=.b075050a-8e70-419b-bcec-db82052456ed@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
 <WXJBSJDyrdXRKPguEmiQjO8AnJrpQWEpfkB7UNq2yZ8=.b075050a-8e70-419b-bcec-db82052456ed@github.com>
Message-ID: <ohPPObksXXxk69IsU9xehkZijl_iFqdPomobxd893q8=.177380d6-fedc-43fa-8627-658d1af66261@github.com>

On Wed, 12 Apr 2023 22:34:17 GMT, Phil Race <prr at openjdk.org> wrote:

> ```
> < int firstBand = image.getSampleModel().getNumBands() - 1;
> > int firstBand = byteRaster.getSampleModel().getNumBands() - 1;
> ```
Done. The new test is added to prove that this issue could be reproduced before the current patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13095#issuecomment-1507688494


From duke at openjdk.org  Fri Apr 14 01:54:49 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 14 Apr 2023 01:54:49 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v6]
In-Reply-To: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
Message-ID: <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>

> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
> 
> This resolution involves confirming that an ImageConsumer is still registered before every notification.
> 
> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.

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

  4200096: removing whitespace diffs
  
  prrace pointed out this branch introduced some pointless whitespace changes.
  https://github.com/openjdk/jdk/pull/13408#discussion_r1164740594

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13408/files
  - new: https://git.openjdk.org/jdk/pull/13408/files/ff469b23..fd751f57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13408&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13408&range=04-05

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

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


From mbaesken at openjdk.org  Fri Apr 14 07:35:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Apr 2023 07:35:28 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v2]
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <kBdwrcDytgY5MqNrhIX9JRAhExOLwuoCLoeNDcEyPSg=.facd3d9a-9b1e-4a87-9cc7-3f7678f615b9@github.com>

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

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

  Avoid message duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13045/files
  - new: https://git.openjdk.org/jdk/pull/13045/files/e9e7b54b..24a30c18

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

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

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


From mbaesken at openjdk.org  Fri Apr 14 07:40:40 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Apr 2023 07:40:40 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v3]
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <WEzgIjIFjDBa7c52U4dbPSwilC4X9T3xvCgZIpnHqnI=.63f34aee-a212-4230-8c3a-3374a55ba7bd@github.com>

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

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

  Avoid adding empty lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13045/files
  - new: https://git.openjdk.org/jdk/pull/13045/files/24a30c18..55748b28

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

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

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


From mbaesken at openjdk.org  Fri Apr 14 07:40:42 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Apr 2023 07:40:42 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v2]
In-Reply-To: <kBdwrcDytgY5MqNrhIX9JRAhExOLwuoCLoeNDcEyPSg=.facd3d9a-9b1e-4a87-9cc7-3f7678f615b9@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <kBdwrcDytgY5MqNrhIX9JRAhExOLwuoCLoeNDcEyPSg=.facd3d9a-9b1e-4a87-9cc7-3f7678f615b9@github.com>
Message-ID: <XhB_967QjYh_5XU4fiqPElA1xA6nxxA0gDnb6bR7t7M=.88f1e914-7400-4bec-b117-c1de91e12742@github.com>

On Fri, 14 Apr 2023 07:35:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
>> 
>> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
>> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
>> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
>> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
>> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
>> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
>> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
>> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
>> ... 17 more
>> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
>> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
>> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
>> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> ... 23 more
>> 
>> Seems this was caused because no fonts were installed on the machine.
>> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
>> should be throw.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid message duplication

Hi Alexey, thanks for your experiments and providing more details , this is helpful for sure !

Regarding avoiding duplication, I think this is a good idea. I adjusted the PR .

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1508063720


From avu at openjdk.org  Fri Apr 14 10:32:36 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 14 Apr 2023 10:32:36 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v3]
In-Reply-To: <vAmv1J1Gk7SpXT2PAibBrnuNG3zL5fVh27N_v39048Q=.46249abd-c29a-46f8-b95b-5f691c0129d7@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <vAmv1J1Gk7SpXT2PAibBrnuNG3zL5fVh27N_v39048Q=.46249abd-c29a-46f8-b95b-5f691c0129d7@github.com>
Message-ID: <yaiOX4ludvGuNfo5EEnt9ddAz476e1DHEncS1JENVHM=.4e066a1a-c711-4368-af58-166e4e852cad@github.com>

On Thu, 13 Apr 2023 15:37:29 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
>> 
>> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
>> 
>> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted the copyright year in X11GraphicsEnvironment.java

Looks good for me

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13346#pullrequestreview-1385191885


From rriggs at openjdk.org  Fri Apr 14 14:34:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 14:34:51 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

make/modules/java.base/gensrc/GensrcMisc.gmk line 72:

> 70: endif
> 71: 
> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \

@erikj79 Is there a better/good way to do these mappings, or select "local" variable names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1166913016


From aivanov at openjdk.org  Fri Apr 14 14:46:37 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Apr 2023 14:46:37 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v3]
In-Reply-To: <WEzgIjIFjDBa7c52U4dbPSwilC4X9T3xvCgZIpnHqnI=.63f34aee-a212-4230-8c3a-3374a55ba7bd@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <WEzgIjIFjDBa7c52U4dbPSwilC4X9T3xvCgZIpnHqnI=.63f34aee-a212-4230-8c3a-3374a55ba7bd@github.com>
Message-ID: <UbzWomhjlzH668EtKOQb5arKgUV4_4ooP3NpOB6pQTg=.025eef04-e778-4f95-b3ef-7658723877cf@github.com>

On Fri, 14 Apr 2023 07:40:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
>> 
>> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
>> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
>> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
>> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
>> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
>> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
>> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
>> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
>> ... 17 more
>> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
>> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
>> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
>> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> ... 23 more
>> 
>> Seems this was caused because no fonts were installed on the machine.
>> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
>> should be throw.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid adding empty lines

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

> 1245:     }
> 1246: 
> 1247:     private static final String fontconfigErrorMessage = "Fontconfig head is null, check your fonts or fonts configuration";

Suggestion:

    private static final String fontconfigErrorMessage =
            "Fontconfig head is null, check your fonts or fonts configuration";

This way it fits into 80-column limit; otherwise the line is too long: 124-columns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13045#discussion_r1166924996


From rriggs at openjdk.org  Fri Apr 14 15:36:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 15:36:36 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v8]
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <6vY3y9okpLJSh_s03VHT8s_QJUf2TWEhnJjpNqkID38=.d16d6434-203c-4910-85db-617fabd345ba@github.com>

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

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

  Remove unused getSystemProperty method and unused imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13213/files
  - new: https://git.openjdk.org/jdk/pull/13213/files/a3334e88..b2aca952

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

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

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


From duke at openjdk.org  Fri Apr 14 15:36:36 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 14 Apr 2023 15:36:36 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module [v8]
In-Reply-To: <6vY3y9okpLJSh_s03VHT8s_QJUf2TWEhnJjpNqkID38=.d16d6434-203c-4910-85db-617fabd345ba@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
 <6vY3y9okpLJSh_s03VHT8s_QJUf2TWEhnJjpNqkID38=.d16d6434-203c-4910-85db-617fabd345ba@github.com>
Message-ID: <4ZCTbwXyXEWUME0KdFNis0vy74sFufFu6toWBRN80mY=.d5128d01-8462-4190-8ae0-129a9c0c766b@github.com>

On Fri, 14 Apr 2023 15:31:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused getSystemProperty method and unused imports

It looks great.

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

Marked as reviewed by Glavo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13213#pullrequestreview-1385685033


From dcherepanov at openjdk.org  Fri Apr 14 15:48:30 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 14 Apr 2023 15:48:30 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v2]
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <FjWyc5TFJ5ynodt9C4H4DRVCZs4slmQUwzVAl3d1dUk=.14832aab-1774-4ab3-b16b-7c4db430cf18@github.com>

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

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

  locate synchronized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13459/files
  - new: https://git.openjdk.org/jdk/pull/13459/files/6ecf314d..0727c25b

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

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

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


From dcherepanov at openjdk.org  Fri Apr 14 15:48:32 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 14 Apr 2023 15:48:32 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v2]
In-Reply-To: <cJKzKw8ICqGLOz6ZHDivxpo3lNsaDQrYwyMwwt1xYaI=.384cf1a7-ddc0-4d34-aadc-a15bbe6e73ea@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <cJKzKw8ICqGLOz6ZHDivxpo3lNsaDQrYwyMwwt1xYaI=.384cf1a7-ddc0-4d34-aadc-a15bbe6e73ea@github.com>
Message-ID: <Ai8FiZvDVpTyCqRNSNvt7PIQ_TRY45W9E3eE1b3j80A=.2113cc20-c87d-4121-b6a2-9799cd58a479@github.com>

On Thu, 13 Apr 2023 15:34:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   locate synchronized
>
> src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java line 270:
> 
>> 268:         }
>> 269: 
>> 270:         static GraphicsPrimitive locate(int primTypeID) {
> 
> it should be marked as `synchronized` too. Otherwise there will possible data race between other thread called `register`

Fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1166996384


From dcherepanov at openjdk.org  Fri Apr 14 15:58:26 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 14 Apr 2023 15:58:26 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v3]
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <srFrWMKBSlTbf2ETou0p4I1ImI5CjoHmCxlX0n-jpVo=.6945a204-d03f-4e77-b0c8-4af22e735661@github.com>

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

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

  remove commented line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13459/files
  - new: https://git.openjdk.org/jdk/pull/13459/files/0727c25b..e6754209

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

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

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


From dcherepanov at openjdk.org  Fri Apr 14 15:58:29 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 14 Apr 2023 15:58:29 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v3]
In-Reply-To: <XaNsL8HP1y8Ks7bol7w4PCql0JGfUDmsww0kGMwqbu0=.efb7d888-c643-4062-a014-69d22f0ab1c1@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <XaNsL8HP1y8Ks7bol7w4PCql0JGfUDmsww0kGMwqbu0=.efb7d888-c643-4062-a014-69d22f0ab1c1@github.com>
Message-ID: <6UnHT8_CdWhM8nisRigcu98VAgMhg00MH_TiHuBbYHU=.2c4460a3-1135-44a7-bad3-51ad56699cc2@github.com>

On Thu, 13 Apr 2023 21:31:58 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove commented line
>
> src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java line 281:
> 
>> 279:             }
>> 280:             return null;
>> 281:             //throw new InternalError("No general handler registered for"+signature);
> 
> This line can be deleted if no longer needed.

Removed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1167008104


From duke at openjdk.org  Fri Apr 14 16:06:28 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 14 Apr 2023 16:06:28 GMT
Subject: RFR: 8305920 : Replace String concatenation in a loop in
 SimpleAttributeSet.toString with StringBuilder
Message-ID: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>

Replaced string concatenation using '+' operator with StringBuilder append function.

Please review.

Regards,
Renjith.

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

Commit messages:
 - Updated copyright year
 - JDK-8305920 : Replace String concatenation in a loop in SimpleAttributeSet.toString with StringBuilder

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

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


From honkar at openjdk.org  Fri Apr 14 16:33:35 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Apr 2023 16:33:35 GMT
Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due
 to wrong mouse position [v2]
In-Reply-To: <kpoARUdzeV9Q9z8hg7V1IPZcaQkhLkTx92aN-P6Oq7c=.f8506095-c543-47ef-b06e-a00356a7a9a2@github.com>
References: <C9usFKJK2ZGoLfreooTcSOAOF-9DXL_nsW3tWPtfRas=.f9189154-e5fa-4c59-af03-4288c9513efe@github.com>
 <kpoARUdzeV9Q9z8hg7V1IPZcaQkhLkTx92aN-P6Oq7c=.f8506095-c543-47ef-b06e-a00356a7a9a2@github.com>
Message-ID: <tqaTOCeBavHGEHpLstAIuhAF4CtRRRyuikiHOuvWMQU=.753f5775-2f5b-4855-a1d2-08203663c04b@github.com>

On Fri, 7 Apr 2023 17:57:41 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`.
>> As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event.
>> 
>> Following is the event log before and after fix.
>> 
>> **Before fix:**
>> 
>> 1st mouse move
>> 2nd mouse move
>> Frame-1 Mouse Event
>> Frame-2 Mouse Event
>> java.awt.Point[x=29,y=29]
>> 
>> 
>> **After fix:**
>> 
>> 1st mouse move
>> 2nd mouse move
>> Frame-1 Mouse Event
>> 3rd mouse move
>> Frame-2 Mouse Event
>> java.awt.Point[x=50,y=50]
>> 
>> 
>> Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition.
>> 
>> The updated test fix is checked on multiple uiScales including fractional scales for windows platform.
>> CI testing works as expected on all platforms.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added syncLocationToWindowManager(), changed literals to vars

@prrace Please review

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

PR Comment: https://git.openjdk.org/jdk/pull/13380#issuecomment-1508926025


From rriggs at openjdk.org  Fri Apr 14 16:45:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 16:45:47 GMT
Subject: Integrated: 8304912: Use OperatingSystem enum in java.desktop module
In-Reply-To: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
References: <ppuZTtMZ9JRY67OMKkeVmhVRphRq1mxXN6rB8Mxu3tI=.04ea021f-56f3-4942-a2e1-ce0fc00d1719@github.com>
Message-ID: <c_tv6RoTfVQ2uqc6MqyUO84gu46EHodlbcWzrDcd3bw=.9d31e9e5-0c01-4677-8495-c7d77f0bd41d@github.com>

On Tue, 28 Mar 2023 17:59:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

This pull request has now been integrated.

Changeset: 30a140b5
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30a140b5a2cedc7f69158ce398f14820c7f0df05
Stats:     136 lines in 14 files changed: 22 ins; 71 del; 43 mod

8304912: Use OperatingSystem enum in java.desktop module

Reviewed-by: bpb, prr, aturbanov

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

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


From prr at openjdk.org  Fri Apr 14 16:52:35 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Apr 2023 16:52:35 GMT
Subject: RFR: 8305920 : Replace String concatenation in a loop in
 SimpleAttributeSet.toString with StringBuilder
In-Reply-To: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
References: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
Message-ID: <937s953Z1USijTA0R_2jwaqU5_JIXsuCfm-Kd1ztgds=.3cf77915-50d4-4973-b4f4-542354611614@github.com>

On Fri, 14 Apr 2023 15:59:32 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

> Replaced string concatenation using '+' operator with StringBuilder append function.
> 
> Please review.
> 
> Regards,
> Renjith.

Why is this important ? How often is toString() used on this class ?
IDE suggestions are more relevant when they are pointing to YOUR code that you are developing.
It has to be really important to go changing 20 year old stable code.
This seems like pointless code churn to me.

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

PR Review: https://git.openjdk.org/jdk/pull/13479#pullrequestreview-1385816721


From erikj at openjdk.org  Fri Apr 14 17:10:48 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Apr 2023 17:10:48 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
Message-ID: <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>

On Fri, 14 Apr 2023 14:31:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed isPPC64().
>>   Consolidated switch cases in ArchTest.
>>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>   to avoid multiple mappings in more than one place.
>
> make/modules/java.base/gensrc/GensrcMisc.gmk line 72:
> 
>> 70: endif
>> 71: 
>> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \
> 
> @erikj79 Is there a better/good way to do these mappings, or select "local" variable names?

Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167095379


From serb at openjdk.org  Fri Apr 14 19:46:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Apr 2023 19:46:32 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v3]
In-Reply-To: <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
Message-ID: <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>

On Thu, 13 Apr 2023 15:28:52 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 881:
>> 
>>> 879:     }
>>> 880: 
>>> 881:     private final Hashtable<GraphicsConfiguration, Insets> cachedInsets = new Hashtable<>();
>> 
>> You do not need to create a handcrafted list of gc->insets, but instead, you can save that information directly in the GC. In that case, each GC should be added as a listener(DisplayChangedListener) to the SGE. I think the same should be done for the GD+bounds, see how it is implemented on macOS(CGraphicsDevice#displayChanged)
>
> I did what you suggested to `X11GraphicsDevice.bounds`; please, take a look.
> 
> As for insets, it is more complicated because they may change without `displayChanged()` being called; this happens when, for example, the size of the dock bar changes. We are notified of the `_NET_WORKAREA` property change for the root window that is not accompanied by the ConfigureNotify event. I'm reluctant to send `displayChanged()` in this case; it seems like an overkill for a change in the work area.

II suggest to check how it works on win/mac, does we trigger displayChanged in that case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1167220493


From serb at openjdk.org  Fri Apr 14 20:00:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Apr 2023 20:00:35 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v3]
In-Reply-To: <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
 <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
Message-ID: <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>

On Fri, 14 Apr 2023 19:43:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I did what you suggested to `X11GraphicsDevice.bounds`; please, take a look.
>> 
>> As for insets, it is more complicated because they may change without `displayChanged()` being called; this happens when, for example, the size of the dock bar changes. We are notified of the `_NET_WORKAREA` property change for the root window that is not accompanied by the ConfigureNotify event. I'm reluctant to send `displayChanged()` in this case; it seems like an overkill for a change in the work area.
>
> II suggest to check how it works on win/mac, does we trigger displayChanged in that case?

Even if we skip displayChanged, it is better to inject the field to the GC, and update it on demand, in as similar way the displayChanged is implemented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1167229692


From serb at openjdk.org  Fri Apr 14 20:11:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 14 Apr 2023 20:11:35 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v3]
In-Reply-To: <srFrWMKBSlTbf2ETou0p4I1ImI5CjoHmCxlX0n-jpVo=.6945a204-d03f-4e77-b0c8-4af22e735661@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <srFrWMKBSlTbf2ETou0p4I1ImI5CjoHmCxlX0n-jpVo=.6945a204-d03f-4e77-b0c8-4af22e735661@github.com>
Message-ID: <DbRIBwG2Rk7l_B7SnO2hLRh2sAKrY5TIN5NPgGkn6m0=.9f935e3b-5cf5-4396-bed2-44c9e14659cf@github.com>

On Fri, 14 Apr 2023 15:58:26 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
>> 
>> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.
>
> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove commented line

test/jdk/sun/java2d/loops/GraphicsPrimitiveMgrTest.java line 38:

> 36:     private static volatile CountDownLatch latch;
> 37: 
> 38:     public static void main(final String[] args) throws ClassNotFoundException, InterruptedException {

please split the long lines to 80 chars per line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1167237602


From rriggs at openjdk.org  Fri Apr 14 21:38:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Apr 2023 21:38:41 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <lO7M9T25lZ02nQp3bl6kxwsUVibW8hlyCeS4S9QO92A=.7df8551d-3a35-4871-af06-2f171c19ac3b@github.com>
 <jsUfZmkzbPYQ98Ma4MMLm4t4215obdXNnGHA3SgPdwo=.839c5327-6132-46c9-beb4-5823fd2c02b5@github.com>
Message-ID: <0FxAZMAVyrqeR8n81rBSDKzKSL_GF_Qeyv5QbQeRJBI=.8d285dcf-1f72-40bf-a810-94a8cc073e97@github.com>

On Fri, 14 Apr 2023 17:08:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/java.base/gensrc/GensrcMisc.gmk line 72:
>> 
>>> 70: endif
>>> 71: 
>>> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \
>> 
>> @erikj79 Is there a better/good way to do these mappings, or select "local" variable names?
>
> Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now.

ok, I'd rather keep it local.  Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167290252


From rmahajan at openjdk.org  Fri Apr 14 22:48:41 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 14 Apr 2023 22:48:41 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v2]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

  code cleanup and test changes as requested in code review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/12631838..ea200b96

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

  Stats: 355 lines in 4 files changed: 169 ins; 184 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414

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


From rmahajan at openjdk.org  Fri Apr 14 22:50:33 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 14 Apr 2023 22:50:33 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <CHdMJ-xgcBAOcMHd0mhGE-s23ZLYqaa_LBOmFlqtsZU=.f1d135ab-3d85-44fb-9f41-47e11c86b84c@github.com>

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Made changes requested by the reviewers. Now we read animated gif image from byte array.
Thanks @aivanov-jdk for the help with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1509367937


From javalists at cbfiddle.com  Fri Apr 14 22:54:33 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 14 Apr 2023 15:54:33 -0700
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v2]
In-Reply-To: <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
Message-ID: <1CD99D31-5CF4-4778-874F-9A87F49AAC6E@cbfiddle.com>



> On Apr 14, 2023, at 3:48 PM, Rajat Mahajan <rmahajan at openjdk.org> wrote:
> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.

Is it really the case that multiple frames are copied one at a time?

I don?t see that, and don?t see how that could work.

I?m not saying it is wrong to copy only the first frame, as that is the only reasonable option if the goal is to transfer a BufferedImage.

I assume there is no Java representation of a multi-frame image that could be copied?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230414/582a7883/attachment.htm>

From prr at openjdk.org  Sat Apr 15 06:48:38 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 15 Apr 2023 06:48:38 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
Message-ID: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>

This is the SwingMark performance benchmark.
It is very simplistic by today's standards but has been in use since 1998
and gives a sense of changes that affect the UI stack not just core Java 2D
tight loop rendering.
It is mostly "as is" with these exceptions

1) I did some tidying up of the woeful code formatting
2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
3) I added a Makefile and support for building as a jar.
4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
5) README is cleaned up and updated
6) I used the same licensing as J2DBench
7) I've put it alongside RenderPerfTest in the sources

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

Commit messages:
 - 8278583
 - 8278583
 - 8278583
 - Revert "8278583"
 - 8278583
 - 8278583

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

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


From duke at openjdk.org  Sat Apr 15 17:23:43 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 15 Apr 2023 17:23:43 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
Message-ID: <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>

On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed isPPC64().
>   Consolidated switch cases in ArchTest.
>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>   to avoid multiple mappings in more than one place.

The RISC-V 64 part look good, `ArchTest` has passed on Debian RISC-V 64.

test/jdk/jdk/internal/util/ArchTest.java line 70:

> 68:             case "x86", "i386" -> X86;
> 69:             case "aarch64" -> AARCH64;
> 70:             case "riscv64" -> RISCV64;  // unverified

Suggestion:

            case "riscv64" -> RISCV64;

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

Marked as reviewed by Glavo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1386559067
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167584685


From serb at openjdk.org  Sun Apr 16 07:05:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 16 Apr 2023 07:05:40 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <sy6cxipdLsciAiHV8QaPIbYJOOhXwYx-5pXdvYfAqw4=.771b7d6f-d60c-498d-a39e-9b2b18e2bdfe@github.com>

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13486#pullrequestreview-1386714359


From asemenov at openjdk.org  Sun Apr 16 14:42:34 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 16 Apr 2023 14:42:34 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v2]
In-Reply-To: <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
 <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
Message-ID: <wi1zNkKgVFEFUYUBDweRFdwcbAI2283wZlfeEFxVMEQ=.c2a0ea71-cebd-4c65-8797-4fad4134297b@github.com>

On Fri, 17 Mar 2023 19:41:42 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature.
>> 
>> CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org")
>> 
>> @mrserb @prrace @azuev-java please review
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - I suppose that adding @Native to AccessibleAnnouncer constants would simplify the code

Do not close this pull request.
@mrserb @prrace @azuev-java please review

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

PR Comment: https://git.openjdk.org/jdk/pull/13001#issuecomment-1510402415


From kizune at openjdk.org  Mon Apr 17 00:48:44 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 17 Apr 2023 00:48:44 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v2]
In-Reply-To: <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
 <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
Message-ID: <XxmQCLLanuH2xcMYnm-5h4E3QQAfKq0e1azDOTq5Awk=.766fd3ba-0864-4be1-ab8c-e9d003714a8e@github.com>

On Fri, 17 Mar 2023 19:41:42 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature.
>> 
>> CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org")
>> 
>> @mrserb @prrace @azuev-java please review
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - I suppose that adding @Native to AccessibleAnnouncer constants would simplify the code

src/java.desktop/share/classes/javax/accessibility/AccessibleAnnouncer.java line 55:

> 53:     void announce(Accessible a, final String str, final int priority);
> 54: 
> 55: }

Minor: no newline at the last line of the file. Not an error just a cosmetic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13001#discussion_r1168070150


From kizune at openjdk.org  Mon Apr 17 00:52:43 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 17 Apr 2023 00:52:43 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v2]
In-Reply-To: <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
 <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
Message-ID: <4xnr-gUyfdkE1bFqqRI00nrXVAvh4bNOKVSmQSIrKG8=.6b9339b5-e959-4b9e-b64e-1cd6b8441f75@github.com>

On Fri, 17 Mar 2023 19:41:42 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature.
>> 
>> CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org")
>> 
>> @mrserb @prrace @azuev-java please review
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - I suppose that adding @Native to AccessibleAnnouncer constants would simplify the code

Since there is a new interface and a default implementation for it the CSR process should be invoked. See https://wiki.openjdk.org/display/csr/CSR+FAQs

Q: What sort of changes require CSR review?
A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include:

- Changes to public and exported APIs in java.* and javax.* packages.

And that falls well within that clause.

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

PR Review: https://git.openjdk.org/jdk/pull/13001#pullrequestreview-1387118201


From aghaisas at openjdk.org  Mon Apr 17 05:28:35 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 17 Apr 2023 05:28:35 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <FvJTqrLilK8Miezc3Qjtn7t5EsDju8pqmo9dF7-Ffo8=.ec51f573-7ede-4568-ac07-8f3d5fefba12@github.com>

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

Marked as reviewed by aghaisas (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13486#pullrequestreview-1387271184


From dcherepanov at openjdk.org  Mon Apr 17 08:14:13 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 17 Apr 2023 08:14:13 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

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

  fixed long lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13459/files
  - new: https://git.openjdk.org/jdk/pull/13459/files/e6754209..35d02bd4

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

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

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


From dcherepanov at openjdk.org  Mon Apr 17 08:14:16 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 17 Apr 2023 08:14:16 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v3]
In-Reply-To: <DbRIBwG2Rk7l_B7SnO2hLRh2sAKrY5TIN5NPgGkn6m0=.9f935e3b-5cf5-4396-bed2-44c9e14659cf@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <srFrWMKBSlTbf2ETou0p4I1ImI5CjoHmCxlX0n-jpVo=.6945a204-d03f-4e77-b0c8-4af22e735661@github.com>
 <DbRIBwG2Rk7l_B7SnO2hLRh2sAKrY5TIN5NPgGkn6m0=.9f935e3b-5cf5-4396-bed2-44c9e14659cf@github.com>
Message-ID: <36blU0xgP_6uOsVZlN_gEj74k_BErFAQITcgDiJQUJQ=.fc7f1d89-d9a1-46c1-85c8-7c5602a9b807@github.com>

On Fri, 14 Apr 2023 20:08:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove commented line
>
> test/jdk/sun/java2d/loops/GraphicsPrimitiveMgrTest.java line 38:
> 
>> 36:     private static volatile CountDownLatch latch;
>> 37: 
>> 38:     public static void main(final String[] args) throws ClassNotFoundException, InterruptedException {
> 
> please split the long lines to 80 chars per line

Fixed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1168333063


From mickleness at gmail.com  Mon Apr 17 08:53:51 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Mon, 17 Apr 2023 08:53:51 +0000
Subject: AreaAveragingScalingFilter
Message-ID: <em065a3875-ff7a-40c4-b4a4-0158aa90d506@d8023f25.com>

I could be mistaken, but it looks like AreaAveragingFilter has a typo in 
it. This method looks suspicious to me:

public void setHints(int hints) {
passthrough = ((hints & neededHints) != neededHints);
super.setHints(hints);
}

Later on the passthrough field is used as:

public void setPixels(int x, int y, int w, int h,
ColorModel model, byte pixels[], int off,
int scansize) {
if (passthrough) {
super.setPixels(x, y, w, h, model, pixels, off, scansize);
     } else {
         accumPixels(x, y, w, h, model, pixels, off, scansize);
     }
}

This makes me think we want passthrough to be true when we match 
specific hints (?neededHints?) promising to deliver the pixel data in 
whole scanlines from top-to-bottom. So the ?!=? in setHints(..) should 
be ?==?.

If I set passthrough to true for BufferedImages (which always deliver 
pixels from top to bottom in entire scanlines), then the execution time 
of this filter reduces to less than 5% of its current time. But it 
introduces scaling artifacts and looks lower quality.

So if (?) my theory is correct that there is a typo, and knowing that 
the AreaAveragingFilter is effectively internally deprecated 
<https://bugs.openjdk.org/browse/JDK-6196792?jql=status = Open AND text 
~ "AreaAveragingScaleFilter"> : is anyone interested in discussing this 
with me further? I attached my (very rough) test program that 
demonstrates both the performance difference and the scaling artifacts.

(My broad goal is to create thumbnails of large images. If I used a 
Graphics2D to scale the image more than 50%, then I also see scaling 
artifacts with that approach. I know ?Filthy Rich Clients? outlined a 
solution to that problem, but it?s expensive. So I?m dusting off this 
filter to see if it can work.)

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230417/64404475/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AreaAveragingScaleFilterTest.java.zip
Type: application/zip
Size: 2283 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230417/64404475/AreaAveragingScaleFilterTest.java.zip>

From aturbanov at openjdk.org  Mon Apr 17 08:56:07 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 17 Apr 2023 08:56:07 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <3UM8ErjfSVbRrkmvX_3xcOVX-t_y63MC_bDCjhAcxqQ=.53d84746-f573-43b1-9af9-fd1e60349c99@github.com>

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

test/jdk/performance/client/SwingMark/src/AbstractSwingTest.java line 135:

> 133:             if (test.getPaintCount() > 0) {
> 134:                System.out.println("Called Paint: " + test.getPaintCount() + " times");
> 135:             }  else {

nit
Suggestion:

            } else {

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 128:

> 126: 
> 127:         public TextAppender(JTextArea textArea, String appendThis) {
> 128:             area =  textArea;

nit
Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 141:

> 139: 
> 140:         public TextCutter(JTextArea textArea) {
> 141:             area =  textArea;

nit
Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 153:

> 151: 
> 152:         public TextCopier(JTextArea textArea) {
> 153:                 area =  textArea;

nit
Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 169:

> 167:         @SuppressWarnings("deprecation")
> 168:         public TextFontSetter(JTextArea textArea) {
> 169:             area =  textArea;

nit
Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 188:

> 186: 
> 187:         public TextPaster(JTextArea textArea) {
> 188:             area =  textArea;

Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 203:

> 201: 
> 202:         public TextSelector(JTextArea textArea) {
> 203:             area =  textArea;

Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/AdvancedTextAreaTest.java line 232:

> 230: 
> 231:         public CaretSetter(JTextArea textArea) {
> 232:             area =  textArea;

Suggestion:

            area = textArea;

test/jdk/performance/client/SwingMark/src/LabelTest.java line 114:

> 112: 
> 113:    public LabelChanger(JLabel[] labelsToChange) {
> 114:       labels =  labelsToChange;

nit
Suggestion:

      labels = labelsToChange;

test/jdk/performance/client/SwingMark/src/ListTest.java line 54:

> 52:         loadBundle();
> 53:         JPanel panel = new JPanel();
> 54:         String[] list1Data =  new String[list1ItemCount];

nit
Suggestion:

        String[] list1Data = new String[list1ItemCount];

test/jdk/performance/client/SwingMark/src/ListTest.java line 69:

> 67:      private void loadBundle() {
> 68:          ResourceBundle bundle = ResourceBundle.getBundle("resources.ListTest");
> 69:          DISPLAY_STRING =  bundle.getString("DisplayString");

Suggestion:

         DISPLAY_STRING = bundle.getString("DisplayString");

test/jdk/performance/client/SwingMark/src/ListTest.java line 116:

> 114: 
> 115:    public ListScroller(JList listToScroll, int scrollBy) {
> 116:       list =  listToScroll;

nit
Suggestion:

      list = listToScroll;

test/jdk/performance/client/SwingMark/src/NullRunnable.java line 38:

> 36:   */
> 37: 
> 38: class NullRunnable implements Runnable  {

nit
Suggestion:

class NullRunnable implements Runnable {

test/jdk/performance/client/SwingMark/src/SliderTest.java line 103:

> 101: 
> 102:     public SliderInc(JSlider sliderToIncrement, int incrementBy) {
> 103:         slider =  sliderToIncrement;

nit
Suggestion:

        slider = sliderToIncrement;

test/jdk/performance/client/SwingMark/src/TableColMoveTest.java line 94:

> 92: 
> 93:     public TableColMover(JTable table) {
> 94:         this.table =  table;

Suggestion:

        this.table = table;

test/jdk/performance/client/SwingMark/src/TableColTest.java line 87:

> 85:       System.out.println("1)Removing Columns");
> 86:       TableColAdder colRemover = new TableColAdder(currentTable,false);
> 87:       while(currentTable.getColumnCount() > 0 )  {

nit
Suggestion:

      while (currentTable.getColumnCount() > 0)  {

test/jdk/performance/client/SwingMark/src/TableColTest.java line 139:

> 137: 
> 138:     public TableColScroller(JTable tableToScroll, int scrollBy, int selectionMode) {
> 139:       table =  tableToScroll;

nit
Suggestion:

      table = tableToScroll;

test/jdk/performance/client/SwingMark/src/TableRowTest.java line 166:

> 164: 
> 165:     public TableScroller(JTable tableToScroll, int scrollBy, int selectionMode) {
> 166:         table =  tableToScroll;

nit
Suggestion:

        table = tableToScroll;

test/jdk/performance/client/SwingMark/src/TableRowTest.java line 213:

> 211: 
> 212:     public TableRowAdder(JTable table, Object[][] data, boolean add) {
> 213:         this.table =  table;

nit
Suggestion:

        this.table = table;

test/jdk/performance/client/SwingMark/src/TextAreaTest.java line 82:

> 80:    private void loadBundle() {
> 81:        ResourceBundle bundle = ResourceBundle.getBundle("resources.TextAreaTest");
> 82:        DISPLAY_STRING =  bundle.getString("DisplayString");

nit
Suggestion:

       DISPLAY_STRING = bundle.getString("DisplayString");

test/jdk/performance/client/SwingMark/src/TextAreaTest.java line 124:

> 122: 
> 123:     public TextAppender(JTextArea textArea, String appendThis) {
> 124:         area =  textArea;

nit
Suggestion:

        area = textArea;

test/jdk/performance/client/SwingMark/src/TextPaneTest.java line 102:

> 100: 
> 101:         public TextAppender(JTextPane textArea, String appendThis) {
> 102:             area =  textArea;

Suggestion:

            area = textArea;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168371928
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168378903
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168379263
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168379998
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168380396
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168380595
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168380769
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168381097
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168370089
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168376898
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168377279
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168377716
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168378106
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168378392
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168381452
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168374848
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168375116
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168373171
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168373510
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168372480
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168372764
PR Review Comment: https://git.openjdk.org/jdk/pull/13486#discussion_r1168381757


From mkartashev at openjdk.org  Mon Apr 17 08:58:41 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 17 Apr 2023 08:58:41 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v3]
In-Reply-To: <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
 <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
 <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>
Message-ID: <ARN9hx1kDtJk01JkFF9OHtJbVNbUXaL52yujttRttBg=.9e53f587-4825-48d0-aebc-c75e91d68c5b@github.com>

On Fri, 14 Apr 2023 19:56:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> II suggest to check how it works on win/mac, does we trigger displayChanged in that case?
>
> Even if we skip displayChanged, it is better to inject the field to the GC, and update it on demand, in as similar way the displayChanged is implemented.

> II suggest to check how it works on win/mac, does we trigger displayChanged in that case?

I doubt it: see comments in [CGraphicsDevice.getScreenInsets()](https://github.com/openjdk/jdk/blob/2a062f165491d599eb0dcfb6050eb9186ae31b71/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L185)

        // the insets are queried synchronously and are not cached
        // since there are no Quartz or Cocoa means to receive notifications
        // on insets changes (e.g. when the Dock is resized):
        // the existing CGDisplayReconfigurationCallBack is not notified
        // as well as the NSApplicationDidChangeScreenParametersNotification
        // is fired on the Dock location changes only

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1168385232


From avu at openjdk.org  Mon Apr 17 08:59:52 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 17 Apr 2023 08:59:52 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <sGZwJsJXPOl877JDuDcHSMsz5VCaMaVLpSPoFrM4nTs=.c5aa82e7-cadc-49e4-8e5b-59dcf621c0ff@github.com>

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

Looks good

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13486#pullrequestreview-1387584329


From mkartashev at openjdk.org  Mon Apr 17 09:33:20 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 17 Apr 2023 09:33:20 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v4]
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <nBbxSUJdD1CvIJnc4MCY3tWsrNJ28cxKRMGTBwRDHDo=.acd038d6-f5bd-4cd6-a80c-5ad6e6d5e49e@github.com>

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

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

  Initialize X11GraphicsDevice.bounds in constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13346/files
  - new: https://git.openjdk.org/jdk/pull/13346/files/670df083..02b6ae9d

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

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

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


From mkartashev at openjdk.org  Mon Apr 17 10:22:30 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 17 Apr 2023 10:22:30 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v4]
In-Reply-To: <ARN9hx1kDtJk01JkFF9OHtJbVNbUXaL52yujttRttBg=.9e53f587-4825-48d0-aebc-c75e91d68c5b@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
 <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
 <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>
 <ARN9hx1kDtJk01JkFF9OHtJbVNbUXaL52yujttRttBg=.9e53f587-4825-48d0-aebc-c75e91d68c5b@github.com>
Message-ID: <n1aD0-m9lIT6m4zYLM2bS0X7Z6p4I-oFYuXcYreUL3Q=.73f70fe5-2383-43d4-8c25-b40cb5bc0515@github.com>

On Mon, 17 Apr 2023 08:56:00 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Even if we skip displayChanged, it is better to inject the field to the GC, and update it on demand, in as similar way the displayChanged is implemented.
>
>> II suggest to check how it works on win/mac, does we trigger displayChanged in that case?
> 
> I doubt it: see comments in [CGraphicsDevice.getScreenInsets()](https://github.com/openjdk/jdk/blob/2a062f165491d599eb0dcfb6050eb9186ae31b71/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L185)
> 
>         // the insets are queried synchronously and are not cached
>         // since there are no Quartz or Cocoa means to receive notifications
>         // on insets changes (e.g. when the Dock is resized):
>         // the existing CGDisplayReconfigurationCallBack is not notified
>         // as well as the NSApplicationDidChangeScreenParametersNotification
>         // is fired on the Dock location changes only

> it is better to inject the field to the GC, and update it on demand

I'm not sure this will look as pretty as in `CGraphicsDevice`. The code to obtain insets is located in `XToolkit` and is not easily moveable; insets are queried from and updated in `XToolkit` also, so by moving insets outside of `XToolkit` we're going to create more cross-package dependencies without really improving anything. Redesigning the entire toolkit so that insets fit more naturally to be a property of `X11GraphicsConfig` (or rather `X11GraphicsDevice` where I think they belong) is a task way beyond the scope of 8305578.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1168480025


From alexey.ivanov at oracle.com  Mon Apr 17 11:43:06 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 17 Apr 2023 12:43:06 +0100
Subject: AreaAveragingScalingFilter
In-Reply-To: <em065a3875-ff7a-40c4-b4a4-0158aa90d506@d8023f25.com>
References: <em065a3875-ff7a-40c4-b4a4-0158aa90d506@d8023f25.com>
Message-ID: <53562955-5c06-f78f-623c-ec1cd994060f@oracle.com>

Hi Jeremy,

The intention could be /to pass through/ if the value of hints is 
different from the needed ones. That is the filter activates if and only 
if |hints == neededHints|, otherwise it doesn't do anything and forwards 
calls to its superclass.

-- 
Regards,
Alexey

On 17/04/2023 09:53, Jeremy Wood wrote:
> I could be mistaken, but it looks like AreaAveragingFilter has a typo 
> in it. This method looks suspicious to me:
>
> public void setHints(int hints) {
>      passthrough = ((hints &neededHints) !=neededHints);
>      super.setHints(hints);
> }
>
> Later on the passthrough field is used as:
>
> public void setPixels(int x,int y,int w,int h,
>                        ColorModel model,byte pixels[],int off,
>                        int scansize) {
>      if (passthrough) {
>          super.setPixels(x, y, w, h, model, pixels, off, scansize);
>      }else {
>          accumPixels(x, y, w, h, model, pixels, off, scansize);
>      }
> }
>
> This makes me think we want passthrough to be /true/?when we match 
> specific hints (?neededHints?) promising to deliver the pixel data in 
> whole scanlines from top-to-bottom. So the ?!=? in setHints(..) should 
> be ?==?.
>
> If I set passthrough to true for BufferedImages (which always deliver 
> pixels from top to bottom in entire scanlines),?then the execution 
> time of this filter reduces to less than 5% of its current time. But 
> it introduces scaling artifacts and looks lower quality.
>
> So if (?) my theory is correct that there is a typo, and knowing that 
> the AreaAveragingFilter iseffectively internally deprecated 
> <https://bugs.openjdk.org/browse/JDK-6196792?jql=status = Open AND 
> text ~ "AreaAveragingScaleFilter">?: is anyone interested in 
> discussing this with me further? I attached my (very rough) test 
> program that demonstrates both the performance difference and the 
> scaling artifacts.
>
> (My broad goal is to create thumbnails of large images. If I used a 
> Graphics2D to scale the image more than 50%, then I also see scaling 
> artifacts with?that approach. I know??Filthy Rich Clients? outlined a 
> solution?to that problem, but it?s expensive. So I?m dusting off this 
> filter to see if it can work.)
>
> Regards,
> ?- Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230417/ca0b3ac3/attachment.htm>

From rriggs at openjdk.org  Mon Apr 17 17:14:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 17:14:33 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v14]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <rkbmsfbX1jjvKtcTmVuQUY4kvXRQiHpOBNftKRLVKDs=.a3a45760-b38d-49bb-ba8f-e306ee0e2501@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

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

  ArchTest on Debian RISC-V 64 confirmed by reviewer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/0cd6ce70..7094db61

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

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

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


From rriggs at openjdk.org  Mon Apr 17 17:31:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 17:31:52 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v13]
In-Reply-To: <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <VsNE8ygO7YfGBM6XwaBQPCu6p54Rh35OXRjsI9f64EA=.afbe43a3-d880-4e69-8ea7-0ad1a61093d7@github.com>
 <SjWFADdGRi3vkaTtNe8-fezznmFe2p4DsmMb1acXsCI=.9212dade-0358-4a00-bf42-9f94bdf54342@github.com>
Message-ID: <aBPpSZdnrmZifebNEszsNOJWU9A3eyLGqslSPdt8P5s=.911d9778-a8ec-4b1f-9f56-238e5e82839d@github.com>

On Sat, 15 Apr 2023 17:17:13 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed isPPC64().
>>   Consolidated switch cases in ArchTest.
>>   Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>   to avoid multiple mappings in more than one place.
>
> test/jdk/jdk/internal/util/ArchTest.java line 70:
> 
>> 68:             case "x86", "i386" -> X86;
>> 69:             case "aarch64" -> AARCH64;
>> 70:             case "riscv64" -> RISCV64;  // unverified
> 
> Suggestion:
> 
>             case "riscv64" -> RISCV64;

@Glavo Thanks for verifying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1169059529


From prr at openjdk.org  Mon Apr 17 18:09:52 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 17 Apr 2023 18:09:52 GMT
Subject: RFR: 8278583: Open source SwingMark - Swing performance benchmark
 [v2]
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <rKciyGFrGJQssB8XJREwCGUKze7c-SI7WmJE_aXXKMc=.ef1150a6-4dcc-495f-adad-ba022d46f611@github.com>

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

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

  8278583

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13486/files
  - new: https://git.openjdk.org/jdk/pull/13486/files/1841c85e..ebc0ce6d

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

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

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


From prr at openjdk.org  Mon Apr 17 18:09:53 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 17 Apr 2023 18:09:53 GMT
Subject: Integrated: 8278583: Open source SwingMark - Swing performance
 benchmark
In-Reply-To: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
References: <u3ubRR2tWSFyZ1xyGs2oRUP3s62i5Z47LcpPGqEl1UY=.f51acc46-e008-450f-8c3d-cf537e72fcaf@github.com>
Message-ID: <BDa3gQgSfwoMpwLSxb2McLLnN2fD-C9idQBzXYSlEIs=.dbf72b31-d90e-44ef-8aac-9f77fc6c8e43@github.com>

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the SwingMark performance benchmark.
> It is very simplistic by today's standards but has been in use since 1998
> and gives a sense of changes that affect the UI stack not just core Java 2D
> tight loop rendering.
> It is mostly "as is" with these exceptions
> 
> 1) I did some tidying up of the woeful code formatting
> 2) I migrated some deprecated API and suppressed warnings for others (some future work there, but I didn't want to make changes that might affect comparisons)
> 3) I added a Makefile and support for building as a jar.
> 4) TestList.txt is a resource in the .jar so most folks don't need to worry about it
> 5) README is cleaned up and updated
> 6) I used the same licensing as J2DBench
> 7) I've put it alongside RenderPerfTest in the sources

This pull request has now been integrated.

Changeset: 6831f9db
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6831f9db8b978a441ef38d3602779c3a5f521413
Stats:     4852 lines in 34 files changed: 4852 ins; 0 del; 0 mod

8278583: Open source SwingMark - Swing performance benchmark

Reviewed-by: serb, aghaisas, avu

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

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


From rmahajan at openjdk.org  Mon Apr 17 18:52:13 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Mon, 17 Apr 2023 18:52:13 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v2]
In-Reply-To: <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
Message-ID: <wPshUc6nruWUgYpetQEAb77NADPHQqvFCXNgpysEhBk=.61a90a46-b400-47a3-8ed4-4894159a0ca3@github.com>

On Fri, 14 Apr 2023 22:48:41 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and test changes as requested in code review

> 



> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.org):_
> 
> > On Apr 14, 2023, at 3:48 PM, Rajat Mahajan <rmahajan at openjdk.org> wrote:
> > > On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> 
> Is it really the case that multiple frames are copied one at a time?
> 
> I don?t see that, and don?t see how that could work.
> 
> I?m not saying it is wrong to copy only the first frame, as that is the only reasonable option if the goal is to transfer a BufferedImage.
> 
> I assume there is no Java representation of a multi-frame image that could be copied?
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230414/582a7883/attachment.htm>

Yes I see that the frame is copied one at a time. When I debug and step in reconstruct() is called per frame.
I am not aware of Java representation of a multi-frame image.

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

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1511908141


From mickleness at gmail.com  Mon Apr 17 19:31:16 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Mon, 17 Apr 2023 19:31:16 +0000
Subject: AreaAveragingScalingFilter
In-Reply-To: <53562955-5c06-f78f-623c-ec1cd994060f@oracle.com>
References: <em065a3875-ff7a-40c4-b4a4-0158aa90d506@d8023f25.com>
 <53562955-5c06-f78f-623c-ec1cd994060f@oracle.com>
Message-ID: <em3b656f13-03ab-425f-b7c1-f661f0d654d5@d8023f25.com>

Ah, OK. Thanks. You?re right. I think that?s it.

I had assumed passthrough was a desired optimization because it starts 
out false and can only be assigned in `setHints`. But looking at the 
super class confirms your explanation.

So? I still think there are problems here, but now they strike me as 
less interesting/severe:

1. If an ImageProducer neglects to call setHints(..) AND if it produces 
pixels in, say, a random order: then AreaAveragingScaleFilter will fail 
with an exception. (It will enter the branch expecting pixels in a 
specific order, but it won?t get them in that order.)

Attached is a test case confirming that not calling setHints(..) can 
lead to an exception.

In practice:

    A. OffScreenImageSource doesn?t call setHints(), but it happens to 
deliver pixels in the desired order: so it works.

    B. On my Mac: ToolkitImages use an ImageProducer that calls 
setHInts() and promises to deliver pixels in the right order, so it 
works.

2. The AreaAveragingScalingFilter says in its documentation that if it 
doesn?t get the hints it wants: it will request new image production via 
  `requestTopDownLeftRightResent`. I don?t see any evidence that this 
class (or any of its ancestors) invoke this.

(The attached test case also confirms.)

Is there any interest in my writing either of these up?

Regards,
  - Jeremy

------ Original Message ------
>From "Aleksei Ivanov" <alexey.ivanov at oracle.com>
To "Jeremy Wood" <mickleness at gmail.com>; "client-libs-dev at openjdk.org" 
<client-libs-dev at openjdk.org>
Date 4/17/2023 7:43:06 AM
Subject Re: AreaAveragingScalingFilter

>Hi Jeremy,
>
>The intention could be to pass through if the value of hints is 
>different from the needed ones. That is the filter activates if and 
>only if hints == neededHints, otherwise it doesn't do anything and 
>forwards calls to its superclass.
>
>--
>Regards,
>Alexey
>
>On 17/04/2023 09:53, Jeremy Wood wrote:
>>I could be mistaken, but it looks like AreaAveragingFilter has a typo 
>>in it. This method looks suspicious to me:
>>
>>public void setHints(int hints) {
>>     passthrough = ((hints & neededHints) != neededHints);
>>     super.setHints(hints);
>>}
>>
>>Later on the passthrough field is used as:
>>
>>public void setPixels(int x, int y, int w, int h,
>>                       ColorModel model, byte pixels[], int off,
>>                       int scansize) {
>>     if (passthrough) {
>>         super.setPixels(x, y, w, h, model, pixels, off, scansize);
>>     }
>>else {
>>         accumPixels(x, y, w, h, model, pixels, off, scansize);
>>     }
>>}
>>
>>This makes me think we want passthrough to be true when we match 
>>specific hints (?neededHints?) promising to deliver the pixel data in 
>>whole scanlines from top-to-bottom. So the ?!=? in setHints(..) should 
>>be ?==?.
>>
>>If I set passthrough to true for BufferedImages (which always deliver 
>>pixels from top to bottom in entire scanlines), then the execution 
>>time of this filter reduces to less than 5% of its current time. But 
>>it introduces scaling artifacts and looks lower quality.
>>
>>So if (?) my theory is correct that there is a typo, and knowing that 
>>the AreaAveragingFilter is  effectively internally deprecated 
>><https://bugs.openjdk.org/browse/JDK-6196792?jql=status = Open AND 
>>text ~ "AreaAveragingScaleFilter" > : is anyone interested in 
>>discussing this with me further? I attached my (very rough) test 
>>program that demonstrates both the performance difference and the 
>>scaling artifacts.
>>
>>(My broad goal is to create thumbnails of large images. If I used a 
>>Graphics2D to scale the image more than 50%, then I also see scaling 
>>artifacts with that approach. I know ?Filthy Rich Clients? outlined a 
>>solution to that problem, but it?s expensive. So I?m dusting off this 
>>filter to see if it can work.)
>>
>>Regards,
>>  - Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230417/65cff22f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AreaAveragingScaleFilterTest2.java.zip
Type: application/zip
Size: 1871 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230417/65cff22f/AreaAveragingScaleFilterTest2.java.zip>

From asemenov at openjdk.org  Mon Apr 17 20:05:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 17 Apr 2023 20:05:04 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v3]
In-Reply-To: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
Message-ID: <huj1mNhcXlTFK69tjmVHCtHAEE2HbC2HdyPYUL9LRH4=.43d3583f-fde9-4da6-8cc5-9a23dfd7f1ca@github.com>

> This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature.
> 
> CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org")
> 
> @mrserb @prrace @azuev-java please review

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

  Minor: no newline at the last line of the file. Not an error just a cosmetic.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13001/files
  - new: https://git.openjdk.org/jdk/pull/13001/files/1e8fe769..9d770ebb

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

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

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


From asemenov at openjdk.org  Mon Apr 17 20:09:01 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 17 Apr 2023 20:09:01 GMT
Subject: RFR: 8302687 Implement interfaces and shared code for announcement
 feature [v2]
In-Reply-To: <XxmQCLLanuH2xcMYnm-5h4E3QQAfKq0e1azDOTq5Awk=.766fd3ba-0864-4be1-ab8c-e9d003714a8e@github.com>
References: <mF9Oh1YpTFWc6ocMe0bKLZqAXwWxKVa5pDOo_9UjpiI=.e3a972fc-6fa5-4986-ae08-4543377c8660@github.com>
 <6_J8vg_xw6HySE223inFJ0PWwYjP2Cysdl4zW5r0amc=.0ebf48b3-240e-4750-a31a-73e0961d71a6@github.com>
 <XxmQCLLanuH2xcMYnm-5h4E3QQAfKq0e1azDOTq5Awk=.766fd3ba-0864-4be1-ab8c-e9d003714a8e@github.com>
Message-ID: <2OFXd2Ib2j_2R3MQ8OEajxSnBDcJQLRtiM5eEX5WgnA=.f2181984-4a64-4e9d-8a37-900d122d8afd@github.com>

On Mon, 17 Apr 2023 00:45:54 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - I suppose that adding @Native to AccessibleAnnouncer constants would simplify the code
>
> src/java.desktop/share/classes/javax/accessibility/AccessibleAnnouncer.java line 55:
> 
>> 53:     void announce(Accessible a, final String str, final int priority);
>> 54: 
>> 55: }
> 
> Minor: no newline at the last line of the file. Not an error just a cosmetic.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13001#discussion_r1169217607


From rriggs at openjdk.org  Mon Apr 17 20:59:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 20:59:06 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into 8304915-arch-enum
 - ArchTest on Debian RISC-V 64 confirmed by reviewer
 - Fixed isPPC64().
   Consolidated switch cases in ArchTest.
   Moved mapping of build TARGET_OS and TARGET_CPU to the build
   to avoid multiple mappings in more than one place.
 - Correct mapping and test of ppc64
 - Add ppc64 as mapping to PPC64 Architecture
 - Modified test to check Architecture is64bits() and isLittleEndian()
   against Unsafe respective values.
   Relocated code mapping OS name and arch name from PlatformProps to
   OperatingSystem and Architecture. Kept the mapping of names
   in the template close to where the values are filled in by the build.
 - Remove unused static and import of Stabile
 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - Revised mapping mechanism of build target architecture names to enum values.
   Unrecognized values from the build are mapped to enum value "OTHER".
   Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
   Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
 - Revert changes to jdk.accessibility AccessBridge
 - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

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

Changes: https://git.openjdk.org/jdk/pull/13357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=14
  Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From mbaesken at openjdk.org  Tue Apr 18 08:21:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Apr 2023 08:21:53 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v4]
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <Y0nr0DBLn-R_koBQ6BOxMRqFmtCrvThNf7p9asgK4Hw=.d0d5a661-b600-4737-886f-4831ae4831ca@github.com>

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

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

  shorten long line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13045/files
  - new: https://git.openjdk.org/jdk/pull/13045/files/55748b28..1784476b

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

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

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


From mbaesken at openjdk.org  Tue Apr 18 08:21:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Apr 2023 08:21:55 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v3]
In-Reply-To: <WEzgIjIFjDBa7c52U4dbPSwilC4X9T3xvCgZIpnHqnI=.63f34aee-a212-4230-8c3a-3374a55ba7bd@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <WEzgIjIFjDBa7c52U4dbPSwilC4X9T3xvCgZIpnHqnI=.63f34aee-a212-4230-8c3a-3374a55ba7bd@github.com>
Message-ID: <VX4jzMOFrphKg13Cv32UpJ43gRTc1AXR-S-9FrejRR8=.b48df72d-b106-47a6-bda9-501570fe04a2@github.com>

On Fri, 14 Apr 2023 07:40:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
>> 
>> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
>> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
>> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
>> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
>> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
>> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
>> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
>> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
>> ... 17 more
>> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
>> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
>> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
>> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> ... 23 more
>> 
>> Seems this was caused because no fonts were installed on the machine.
>> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
>> should be throw.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid adding empty lines

Hi Alexey, I adjusted the long line, following your suggestion !
Thanks, Matthias

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1512658353


From duke at openjdk.org  Tue Apr 18 08:47:56 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 18 Apr 2023 08:47:56 GMT
Subject: RFR: 8305920 : Replace String concatenation in a loop in
 SimpleAttributeSet.toString with StringBuilder
In-Reply-To: <937s953Z1USijTA0R_2jwaqU5_JIXsuCfm-Kd1ztgds=.3cf77915-50d4-4973-b4f4-542354611614@github.com>
References: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
 <937s953Z1USijTA0R_2jwaqU5_JIXsuCfm-Kd1ztgds=.3cf77915-50d4-4973-b4f4-542354611614@github.com>
Message-ID: <cQoGYsm_IMM8FljVErguRHJBDUFV5gxLF44J7fIdy68=.5745c2ef-eb84-4aeb-ab21-a8076c00afdf@github.com>

On Fri, 14 Apr 2023 16:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Replaced string concatenation using '+' operator with StringBuilder append function.
>> 
>> Please review.
>> 
>> Regards,
>> Renjith.
>
> Why is this important ? How often is toString() used on this class ?
> IDE suggestions are more relevant when they are pointing to YOUR code that you are developing.
> It has to be really important to go changing 20 year old stable code.
> This seems like pointless code churn to me.

Thank you @prrace for the review, I will close this commit.

Renjith

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

PR Comment: https://git.openjdk.org/jdk/pull/13479#issuecomment-1512697471


From duke at openjdk.org  Tue Apr 18 08:47:58 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 18 Apr 2023 08:47:58 GMT
Subject: Withdrawn: 8305920 : Replace String concatenation in a loop in
 SimpleAttributeSet.toString with StringBuilder
In-Reply-To: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
References: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
Message-ID: <899P6NrwORweRG-QYLTVxibdh0isyqcZSj9ZjVDBrWg=.cd1a4eb3-8e27-49bd-94ea-2f479f8523c6@github.com>

On Fri, 14 Apr 2023 15:59:32 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

> Replaced string concatenation using '+' operator with StringBuilder append function.
> 
> Please review.
> 
> Regards,
> Renjith.

This pull request has been closed without being integrated.

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

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


From martin.desruisseaux at geomatys.com  Tue Apr 18 09:34:30 2023
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Tue, 18 Apr 2023 11:34:30 +0200
Subject: BufferedImage documentation inconsistent with implementation
In-Reply-To: <e33579f0-ee9b-45a4-14c8-15cfa780f1bc@oracle.com>
References: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>
 <e33579f0-ee9b-45a4-14c8-15cfa780f1bc@oracle.com>
Message-ID: <8f7b2175-b9a6-df0c-f248-c9de6f452dc4@geomatys.com>

Thanks, I opened a pull request with proposed wording:

https://github.com/openjdk/jdk/pull/13506

Note that it contains one specification change. As said in my previous 
email, the specification is inconsistent with the implementation 
regarding the exception type. I presumed that we want to keep the 
current implementation behavior.

I do not have the power to create new issue on 
https://bugs.openjdk.org/. How can we proceed for that step?

 ??? Thanks,

 ??? ??? Martin


Le 13/04/2023 ? 23:38, Philip Race a ?crit?:

> A BufferedImage is a single always writable Tile.
>
> The method that is most questionable is releaseWritableTile(int, int) 
> being a no-op.
> It doesn't even throw an AAIOB if you pass in something other than (0,0)
> It probably should have a clause
>
> "This method is a no-op and immediately returns without checking the 
> passed values
> since a BufferedImage has only a single tile which is always writable."
>
> The observer methods could also benefit from doc that observers will 
> never be added or
> removed (no-op methods) since there will never any events to dispatch.
> So there's no point in adding real support for listeners.
>
> I think the doc on isTileWritable is well-intentioned but not well-worded.
>
> -phil



From djelinski at openjdk.org  Tue Apr 18 09:46:57 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 09:46:57 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v4]
In-Reply-To: <ukRZpfZ94L-5qtmocNs5CVEQOTQC7H52V0boscrdAGY=.56f3db77-bf6d-478f-a096-2c183fd6ccb2@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <ukRZpfZ94L-5qtmocNs5CVEQOTQC7H52V0boscrdAGY=.56f3db77-bf6d-478f-a096-2c183fd6ccb2@github.com>
Message-ID: <XCG9xlCCbwMYdmsXowS7IZH-S9ZHyq6fw2trAhcOFMc=.8b3a3c5d-9bed-4307-b488-5d4ce4af4af7@github.com>

On Thu, 13 Apr 2023 07:13:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align type names

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/11841#issuecomment-1512768610


From djelinski at openjdk.org  Tue Apr 18 09:46:58 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 09:46:58 GMT
Subject: Integrated: 8299592: Fix and reenable warnings in java.desktop native
 code compilation
In-Reply-To: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
Message-ID: <fmYKKJ57X6og6yeX6WZaJ9ynW7adCeuO4aGM5STgGv4=.ba7f9ebd-f5ae-4a30-b24f-a8a4d79d83d4@github.com>

On Wed, 4 Jan 2023 12:44:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
> 
> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.

This pull request has now been integrated.

Changeset: 3bba8995
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bba89957439a8899f5c1f5089227519403f75fe
Stats:     182 lines in 11 files changed: 1 ins; 120 del; 61 mod

8299592: Fix and reenable warnings in java.desktop native code compilation

Reviewed-by: ihse, aivanov

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

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


From aivanov at openjdk.org  Tue Apr 18 10:47:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Apr 2023 10:47:54 GMT
Subject: RFR: 8305920 : Replace String concatenation in a loop in
 SimpleAttributeSet.toString with StringBuilder
In-Reply-To: <937s953Z1USijTA0R_2jwaqU5_JIXsuCfm-Kd1ztgds=.3cf77915-50d4-4973-b4f4-542354611614@github.com>
References: <2fgnsCzuPHZFbQrgfq9FiWat87iyYR1m2OEdAKL87c4=.ad546447-9798-4ea2-828f-9c238c39b6f1@github.com>
 <937s953Z1USijTA0R_2jwaqU5_JIXsuCfm-Kd1ztgds=.3cf77915-50d4-4973-b4f4-542354611614@github.com>
Message-ID: <Sb0pQdFlo-VHBHLba8sUnHpC-h2sWc0ozZsRZ5ZI0xM=.8fd68f9f-ae34-40d2-bf69-d704a95af4df@github.com>

On Fri, 14 Apr 2023 16:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Why is this important ? How often is toString() used on this class ?

I agree it's not too important, `SimpleAttributeSet.toString` is unlikely to be used often, however, it may when one is debugging code and dumping document structure as well as attributes applied.

So, it a low-risk clean-up PR? at the same time it doesn't add much value because the method rarely used.

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

PR Comment: https://git.openjdk.org/jdk/pull/13479#issuecomment-1512857557


From aivanov at openjdk.org  Tue Apr 18 11:13:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Apr 2023 11:13:57 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v4]
In-Reply-To: <Y0nr0DBLn-R_koBQ6BOxMRqFmtCrvThNf7p9asgK4Hw=.d0d5a661-b600-4737-886f-4831ae4831ca@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <Y0nr0DBLn-R_koBQ6BOxMRqFmtCrvThNf7p9asgK4Hw=.d0d5a661-b600-4737-886f-4831ae4831ca@github.com>
Message-ID: <9BJCjotX5OB9s2HpDyBaK9Y3iDPmgehLvvWEcNgi3Cg=.2ca7b37b-23fa-4541-beec-e43b69ea77a1@github.com>

On Tue, 18 Apr 2023 08:21:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
>> 
>> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
>> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
>> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
>> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
>> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
>> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
>> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
>> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
>> ... 17 more
>> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
>> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
>> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
>> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> ... 23 more
>> 
>> Seems this was caused because no fonts were installed on the machine.
>> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
>> should be throw.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shorten long line

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13045#pullrequestreview-1389858395


From mbaesken at openjdk.org  Tue Apr 18 11:13:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Apr 2023 11:13:58 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed [v4]
In-Reply-To: <Y0nr0DBLn-R_koBQ6BOxMRqFmtCrvThNf7p9asgK4Hw=.d0d5a661-b600-4737-886f-4831ae4831ca@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
 <Y0nr0DBLn-R_koBQ6BOxMRqFmtCrvThNf7p9asgK4Hw=.d0d5a661-b600-4737-886f-4831ae4831ca@github.com>
Message-ID: <F_9k-w8wq2pbYXg4F5brJrpxarD19h_KKQsEgX9MLjo=.83928749-82fd-44fc-8184-7281460be501@github.com>

On Tue, 18 Apr 2023 08:21:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
>> 
>> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
>> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
>> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
>> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
>> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
>> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
>> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
>> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
>> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
>> ... 17 more
>> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
>> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
>> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
>> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
>> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> ... 23 more
>> 
>> Seems this was caused because no fonts were installed on the machine.
>> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
>> should be throw.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shorten long line

Hi Alexey, thanks for the review and approval !

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

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1512889965


From mbaesken at openjdk.org  Tue Apr 18 11:14:00 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Apr 2023 11:14:00 GMT
Subject: Integrated: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
References: <CkNUmXVmGtpvAICUiG9CvObzbZt73oQAspPyLizh2hA=.abbaa15e-1ea6-4b10-ae1b-d8bf623e1671@github.com>
Message-ID: <diIq12r-zDipRnLM2EA6Wtm-MGHOhOUuNz9gvi7fUqI=.f7e091f8-78f8-4c5d-a0d2-93981997d1da@github.com>

On Wed, 15 Mar 2023 16:02:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs like this :
> 
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
> at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:148)
> at java.desktop/sun.font.GlyphLayout$SDCache.<init>(GlyphLayout.java:254)
> at java.desktop/sun.font.GlyphLayout$SDCache.get(GlyphLayout.java:328)
> at java.desktop/sun.font.GlyphLayout.layout(GlyphLayout.java:375)
> at java.desktop/java.awt.Font.layoutGlyphVector(Font.java:2858)
> at FontLayoutStressTest.doLayout(FontLayoutStressTest.java:51)
> at FontLayoutStressTest.main(FontLayoutStressTest.java:57)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
> ... 17 more
> Caused by: java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
> at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
> at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
> at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
> at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:315)
> at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> ... 23 more
> 
> Seems this was caused because no fonts were installed on the machine.
> Probably 'head' in FontConfiguration.getVersion() should be checked for null and a specific exception like "Check your fonts or fonts configuration"
> should be throw.

This pull request has now been integrated.

Changeset: 3c7ab805
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c7ab80501d7935d6f65b18c1eb2b47b207ffcf9
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8304054: Linux: NullPointerException from FontConfiguration.getVersion in case no fonts are installed

Reviewed-by: lucy, aivanov

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

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


From djelinski at openjdk.org  Tue Apr 18 12:07:41 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 12:07:41 GMT
Subject: RFR: 8306279: Build failure after JDK-8299592
Message-ID: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>

Please review this patch that disables a warning that appeared on linux builds in slowdebug configuration after [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592).

I plan to investigate why this failure appears only in slowdebug mode; this patch is intended to unblock the CI.

Verified that the slowdebug builds pass with this patch applied.

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

Commit messages:
 - Disable debug mem warning

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

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


From djelinski at openjdk.org  Tue Apr 18 12:12:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 12:12:44 GMT
Subject: RFR: 8306279: Build failure after JDK-8299592
In-Reply-To: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
References: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
Message-ID: <xKiKSpj8Y6WsLT3eDPHVYOk-tUeN8PBCbSrpjff9s8M=.3c68de27-9885-445e-a64a-7677d84f4ffc@github.com>

On Tue, 18 Apr 2023 11:59:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that disables a warning that appeared on linux builds in slowdebug configuration after [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592).
> 
> I plan to investigate why this failure appears only in slowdebug mode; this patch is intended to unblock the CI.
> 
> Verified that the slowdebug builds pass with this patch applied.

note: before [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592) all warnings in debug_mem.c were disabled, so this particular warning is not new.

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

PR Comment: https://git.openjdk.org/jdk/pull/13507#issuecomment-1512980449


From djelinski at openjdk.org  Tue Apr 18 12:28:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 12:28:44 GMT
Subject: RFR: 8306279: Build failure after JDK-8299592
In-Reply-To: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
References: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
Message-ID: <0GZpZf7_-_BNJhR2xniwhqHvw_hH5mtF5P8vvI7SNMU=.6cf32de7-e434-47d3-825f-41e5b8e40fa8@github.com>

On Tue, 18 Apr 2023 11:59:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that disables a warning that appeared on linux builds in slowdebug configuration after [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592).
> 
> I plan to investigate why this failure appears only in slowdebug mode; this patch is intended to unblock the CI.
> 
> Verified that the slowdebug builds pass with this patch applied.

GHA failures unrelated ([JDK-8306282](https://bugs.openjdk.org/browse/JDK-8306282))

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

PR Comment: https://git.openjdk.org/jdk/pull/13507#issuecomment-1513012115


From thartmann at openjdk.org  Tue Apr 18 12:41:43 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Apr 2023 12:41:43 GMT
Subject: RFR: 8306279: Build failure after JDK-8299592
In-Reply-To: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
References: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
Message-ID: <D6DXRerRUycbBx6FdABCW9LuJuxe4ddwGf_hkl6TMM4=.77a555aa-48bc-452d-998b-803bef3a780f@github.com>

On Tue, 18 Apr 2023 11:59:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that disables a warning that appeared on linux builds in slowdebug configuration after [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592).
> 
> I plan to investigate why this failure appears only in slowdebug mode; this patch is intended to unblock the CI.
> 
> Verified that the slowdebug builds pass with this patch applied.

Looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13507#pullrequestreview-1390026167


From djelinski at openjdk.org  Tue Apr 18 12:58:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 18 Apr 2023 12:58:52 GMT
Subject: Integrated: 8306279: Build failure after JDK-8299592
In-Reply-To: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
References: <uX2c3cTHH3DhQNrgTzVg0Dvm0SWMVPMvxeStycye-Zw=.f47278c9-aaaf-4fc3-9d29-f000f3317eb4@github.com>
Message-ID: <bRHjI7yVHEdg0Z-VCBtxG1unjJEXPZzGE8tBkWUTx6I=.1de6d1df-c3f4-4ea1-8d66-20cf0bbc4fbb@github.com>

On Tue, 18 Apr 2023 11:59:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that disables a warning that appeared on linux builds in slowdebug configuration after [JDK-8299592](https://bugs.openjdk.org/browse/JDK-8299592).
> 
> I plan to investigate why this failure appears only in slowdebug mode; this patch is intended to unblock the CI.
> 
> Verified that the slowdebug builds pass with this patch applied.

This pull request has now been integrated.

Changeset: e97fe081
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e97fe081adbcb3ef37d192aab3c889f54d192059
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8306279: Build failure after JDK-8299592

Reviewed-by: thartmann

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

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


From philip.race at oracle.com  Tue Apr 18 17:22:22 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 18 Apr 2023 10:22:22 -0700
Subject: BufferedImage documentation inconsistent with implementation
In-Reply-To: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>
References: <43709e12-9664-84ed-b4ef-348edd78f24d@geomatys.com>
Message-ID: <78307b5b-8aee-c56f-bc73-8ec92ffce3dd@oracle.com>

I submitted https://bugs.openjdk.org/browse/JDK-8306320

The PR should use that bug ID and the summary fom the bug.
We will need a CSR.

-phil.

On 4/12/23 3:08 AM, Martin Desruisseaux wrote:
>
> Hello all
>
> BufferedImage implements WritableRenderedImage, but the javadoc of all 
> WritableRenderedImage methods are inconsistent with implementation:
>
>   * getWritableTile(?) said "All registered TileObservers are notified
>     when a tile goes from having no writers to having one writer" but
>     the implementation doesn't do that.
>   * releaseWritableTile(?) said "All registered TileObservers are
>     notified when a tile goes from having one writer to having no
>     writers" but the implementation does nothing.
>   * isTileWritable(?) said "throws ArrayIndexOutOfBoundsException if
>     both tileX and tileY are not equal to 0" but the implementation
>     throws IllegalArgumentException is *either* tileX or tileY is not 0.
>   * addTileObserver(?) and removeTileObserver(?) are no-op, but the
>     javadoc don't said that.
>
> Should the javadoc be updated for saying that most methods are 
> actually no-op, or should the implementation be updated with real 
> support of listeners? Or should BufferedImage be considered as 
> permanently checkout out for writing, in which case the current 
> javadoc is not wrong (except above-cited throws clause) but a note 
> about the "permanently checkout-out" behavior would be helpfui?
>
> ??? Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230418/77fb029c/attachment.htm>

From philip.race at oracle.com  Tue Apr 18 17:52:27 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 18 Apr 2023 10:52:27 -0700
Subject: JVM hang with Swing and macOS
In-Reply-To: <E_tRKyd0UtKK-LSEom7zomuhBxHFjWLuXRwstZC5zNpd3g0FjMQGHrn2zhfBk0ssh5f2vWjTk3yVUe8uQS3Q2oJIlyC1vLdqKUCvaur3eXo=@protonmail.com>
References: <FYSMEs2Hs62JS_uHzH29FHYQXRfds-Yo-KNgIOwkarsN4wP1gl2lMkleZj8MnMT2lW3nxWqM-_768qpa57RD6ibcVjTRXkSruNbkizozkMY=@protonmail.com>
 <xTznS98iaqXo4QFt5hmB3fK9lHkAio0nVDyzzM4_0bTqPicquvF9YdRdiGqLI_rrjp3KFF36sXMtaU5m2HwGcCkj28qTJn7YjVbrCMXIZLY=@protonmail.com>
 <EEEBB67C-5E19-4B2E-81DD-C2272BAAB5C2@gmail.com>
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 <e6d44b67-a2a6-18a7-fbfc-027c85d7ced7@amazon.com>
 <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
 <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com>
 <E_tRKyd0UtKK-LSEom7zomuhBxHFjWLuXRwstZC5zNpd3g0FjMQGHrn2zhfBk0ssh5f2vWjTk3yVUe8uQS3Q2oJIlyC1vLdqKUCvaur3eXo=@protonmail.com>
Message-ID: <3cbe14ff-8a2f-eabc-6f2c-e5d38ffe1ee6@oracle.com>

1) -XstartOnFirstThread? should be thought of more as -XdontStartAnEventLoop
And with no event loop running, yes, UI apps hang.
To understand why the option is named as it is, you need to know that on 
most platforms
and situations the application's "main" method will run on the first 
thread that is started
But on macOS in order to allow the event loop to run on that thread, it 
hops over to another
thread that is created. But with this special option, that doesn't 
happen, so some other code
has a chance to use it for that.
The reason for it is that a toolkit like SWT may come along later and 
start a loop.
It is possible to check there's already a loop (AWT + JavaFX both do) 
but perhaps SWT doesn't ?
In summary this option is not (SFAICS) for your use case and that bug is 
"not a bug" and I've closed it.

2) The class referenced by Sergey

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/opengl/OGLUtilities.java

isn't one I know anything about. I can see it pre-dates us even having a 
macOS port, and its completely
unsupported, probably unsupportable, no idea if it actually works, 
especially on macOS.
Not sure if its even a direction you should head down. Caveat emptor. 
Big time.

3) JAWT is a JDK native API that lets you use native code to draw into a 
Java-owned window.
https://docs.oracle.com/en/java/javase/17/docs/specs/AWT_Native_Interface.html
It doesn't provide much more than that. Any rendering that needs to 
happen on a particular thread
etc is out of scope of what it provides.

4) Your error isn't obviously directly opengl related even though it 
mentions "GLUT". Its more about the toolkit.

java[92246:2751169] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: NSWindow drag regions should only be invalidated on the Main Thread!

I would have thought that the advice which I think you need (in this 
somewhat confusing thread) people
have already offered and this is to jump onto the main thread when needed.
You can look at the code in the JDK's libosxapp/ThreadUtilities.m as a 
sample to see how you'd do this.
Do not rely on JDK internals. Ultimately you will need to end up using 
this Apple macOS API -
https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread
- if you aren't already on the main thread that is.
If there's some complication with that which I'm not understanding, I 
don't know what you'd do instead.

I don't have time to look into this any more deeply so this reply must 
be taken as not fully researched,
but it is the best I can offer you.

-Phil

On 3/23/23 4:00 AM, Martin Pernollet wrote:
>
>
>> Start another java process -XstartOnMainThread that does the OpenGL 
>> part from a Swing application?
>
> Sorry I do not understand your question. If you speak about triggering 
> two process with -XstartOnFirstThread, I think they might both freeze. 
> Or worse, one freeze and the other one get kick/stopped by the former.
>
> I can try this next week because I do not have a macOS with me up to 
> next thursday.
>
>> One hang up there though might be that I don?t think java 
>> applications that include the java native commands are allowed in the 
>> Mac App Store. Another bug due to each command has it?s own unique 
>> CFBundleIdentifier but that identifier is always the same and Apple 
>> doesn?t allow duplicates in the App Store.
>
> Being able to deploy on App Store is not an immediate need for me but 
> this is a very interesting point to consider. I'll try to understand 
> how CFBundleIdentifier relates to -XstartOnFIrstThread.
>
> Regards,
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230418/eac7ea13/attachment.htm>

From kizune at openjdk.org  Tue Apr 18 19:04:20 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Apr 2023 19:04:20 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests
Message-ID: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>

Cleaning up and open sourcing three AWT tests

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

Commit messages:
 - 8306135: Clean up and open source some AWT tests

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

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


From duke at openjdk.org  Tue Apr 18 19:10:45 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Apr 2023 19:10:45 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <haJzsjOKO-slIoIBIuIi9dO8pvK1FLucht6poi0FnFE=.fa7e94c0-a34c-4832-9177-652ed9f40efb@github.com>

On Tue, 18 Apr 2023 18:55:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up and open sourcing three AWT tests

test/jdk/java/awt/Cursor/SingleColorCursorTest.java line 42:

> 40: import java.awt.image.BufferedImage;
> 41: import java.lang.reflect.InvocationTargetException;
> 42: public class SingleColorCursorTest extends Panel {

Can you add empty line between class and the import statement

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170464906


From duke at openjdk.org  Tue Apr 18 19:14:44 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Apr 2023 19:14:44 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <R53GAK8-jslwQDglo7vnG8m38vSF4YLYD7SVd7cJLr8=.0c5e27fb-0f15-43eb-9f9a-5c5a9134be09@github.com>

On Tue, 18 Apr 2023 18:55:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up and open sourcing three AWT tests

All the 3 tests are new to open repo and there copy right years are different.

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

PR Comment: https://git.openjdk.org/jdk/pull/13518#issuecomment-1513670080


From duke at openjdk.org  Tue Apr 18 19:37:05 2023
From: duke at openjdk.org (Martin Desruisseaux)
Date: Tue, 18 Apr 2023 19:37:05 GMT
Subject: RFR: 8306320: Add @implSpec for explaining BufferedImage default
 behavior
Message-ID: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>

`BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.

This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.

This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.

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

Commit messages:
 - Added @implSpec for explaining the default behavior, which is quite different from what the javadoc said.

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

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


From duke at openjdk.org  Tue Apr 18 20:06:46 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Apr 2023 20:06:46 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <1OD-LUTgV5hOyMKbJpDu_FpaBX0qVW70cGSKiNcFTrQ=.ef3ed6e2-aa2b-4dfb-bc61-959184f3fd19@github.com>

On Tue, 18 Apr 2023 18:55:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up and open sourcing three AWT tests

test/jdk/java/awt/Dialog/DialogAsParentOfFileDialog.java line 182:

> 180:     }
> 181: 
> 182:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {

Can you set to 80-column limit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170515017


From kizune at openjdk.org  Tue Apr 18 20:16:56 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Apr 2023 20:16:56 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v2]
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <s8JLqIQJgpecpVqpwYTXAyxhZ5WmmSVwpLpmMU3vpig=.8a44a358-7a67-4c5f-af7d-fd9d7d661081@github.com>

> Cleaning up and open sourcing three AWT tests

Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:

 - Cosmitic change: couple of extra-long strings were reformatted to be shorter
 - Added a line separating class declaration from imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13518/files
  - new: https://git.openjdk.org/jdk/pull/13518/files/70d5b596..8877ee01

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

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

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


From duke at openjdk.org  Tue Apr 18 20:16:59 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Apr 2023 20:16:59 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <m_UhJO19In_vcH3kenketMtPqeGYj9k0AUM4XmDiADM=.2cffb038-99f4-4b48-b21e-767530379437@github.com>

On Tue, 18 Apr 2023 18:55:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up and open sourcing three AWT tests

Set to 80-column limit where ever it required.

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

PR Comment: https://git.openjdk.org/jdk/pull/13518#issuecomment-1513737817


From kizune at openjdk.org  Tue Apr 18 20:17:02 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Apr 2023 20:17:02 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v2]
In-Reply-To: <haJzsjOKO-slIoIBIuIi9dO8pvK1FLucht6poi0FnFE=.fa7e94c0-a34c-4832-9177-652ed9f40efb@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
 <haJzsjOKO-slIoIBIuIi9dO8pvK1FLucht6poi0FnFE=.fa7e94c0-a34c-4832-9177-652ed9f40efb@github.com>
Message-ID: <kN70u_kG9RVLw11Wf1rdw6Rwwp5FEH1doX2SdIROhr8=.89859a72-3fae-4a20-8569-4333609b0671@github.com>

On Tue, 18 Apr 2023 19:08:19 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Cosmitic change: couple of extra-long strings were reformatted to be shorter
>>  - Added a line separating class declaration from imports
>
> test/jdk/java/awt/Cursor/SingleColorCursorTest.java line 42:
> 
>> 40: import java.awt.image.BufferedImage;
>> 41: import java.lang.reflect.InvocationTargetException;
>> 42: public class SingleColorCursorTest extends Panel {
> 
> Can you add empty line between class and the import statement

Done

> test/jdk/java/awt/Dialog/ComponentShownEvent.java line 86:
> 
>> 84:     }
>> 85: 
>> 86:     public static void main(String[] args) throws InterruptedException, InvocationTargetException, AWTException {
> 
> Can you set to 80-column limit.

Now trying to keep the lines lengths reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170518141
PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170521433


From duke at openjdk.org  Tue Apr 18 20:17:03 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 18 Apr 2023 20:17:03 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v2]
In-Reply-To: <s8JLqIQJgpecpVqpwYTXAyxhZ5WmmSVwpLpmMU3vpig=.8a44a358-7a67-4c5f-af7d-fd9d7d661081@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
 <s8JLqIQJgpecpVqpwYTXAyxhZ5WmmSVwpLpmMU3vpig=.8a44a358-7a67-4c5f-af7d-fd9d7d661081@github.com>
Message-ID: <fdt6R3PqJu01FTFjWUNKj7d-j_AOPj7FVkVdalSkjEw=.a3ef81c1-921f-4888-8cee-9771c28db329@github.com>

On Tue, 18 Apr 2023 20:12:16 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Cleaning up and open sourcing three AWT tests
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cosmitic change: couple of extra-long strings were reformatted to be shorter
>  - Added a line separating class declaration from imports

test/jdk/java/awt/Dialog/ComponentShownEvent.java line 86:

> 84:     }
> 85: 
> 86:     public static void main(String[] args) throws InterruptedException, InvocationTargetException, AWTException {

Can you set to 80-column limit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170519335


From kizune at openjdk.org  Tue Apr 18 20:29:56 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Apr 2023 20:29:56 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v3]
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <ElQgCpFTFcchS8gBKAc0rOImss0FvYyb067b9C2lG6o=.24b78e0e-7c99-4acf-a8c1-b6cc8259c38e@github.com>

> Cleaning up and open sourcing three AWT tests

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

  Splitting couple of extra long lines to keep it more readable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13518/files
  - new: https://git.openjdk.org/jdk/pull/13518/files/8877ee01..2a04dffa

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

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

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


From kizune at openjdk.org  Tue Apr 18 20:29:57 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Apr 2023 20:29:57 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v3]
In-Reply-To: <1OD-LUTgV5hOyMKbJpDu_FpaBX0qVW70cGSKiNcFTrQ=.ef3ed6e2-aa2b-4dfb-bc61-959184f3fd19@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
 <1OD-LUTgV5hOyMKbJpDu_FpaBX0qVW70cGSKiNcFTrQ=.ef3ed6e2-aa2b-4dfb-bc61-959184f3fd19@github.com>
Message-ID: <Ld0IDWpQSJaIJ5svTaKxe4f5yk9BZFi5x2rY04iD9uE=.7ec0ae55-0bb1-49fa-b443-874f6a148b54@github.com>

On Tue, 18 Apr 2023 20:04:19 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Splitting couple of extra long lines to keep it more readable
>
> test/jdk/java/awt/Dialog/DialogAsParentOfFileDialog.java line 182:
> 
>> 180:     }
>> 181: 
>> 182:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
> 
> Can you set to 80-column limit.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13518#discussion_r1170531766


From rriggs at openjdk.org  Tue Apr 18 20:34:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Apr 2023 20:34:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <0mWtWPVJ_Rb3lP1w1l5jS5C0uM8S6LbuDqoG_VoHjp4=.46e0a172-0ac8-4453-badb-fea41c4275ee@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Last call for Reviewers.  Tnx

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

PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1513760009


From prr at openjdk.org  Tue Apr 18 21:31:10 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Apr 2023 21:31:10 GMT
Subject: RFR: 8306134: Open source some AWT tests relating to Button and a few
 other classes
Message-ID: <BCznwITmdy2-s_zwgrSFZPPPrDs0l7fCGVkgGfu3tsE=.143ee34f-234d-4a55-ad7a-ec3a96cc28e2@github.com>

This open sources a few simple AWT jtreg tests that are overdue to be opened.

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

Commit messages:
 - 8306134

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

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


From erikj at openjdk.org  Tue Apr 18 21:54:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Apr 2023 21:54:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <HmrCuYFeASmQWyUayx9CEqPoAOTgGGYjzKK7xNP2ino=.9d99f952-cb89-4d6a-b6b1-47b2237d3916@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1390984858


From azvegint at openjdk.org  Tue Apr 18 21:56:04 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 18 Apr 2023 21:56:04 GMT
Subject: RFR: 8306280: Open source several choice AWT tests
Message-ID: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>

Open sourcing few AWT choice tests.

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

Commit messages:
 - initial

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

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


From psadhukhan at openjdk.org  Wed Apr 19 07:36:08 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Apr 2023 07:36:08 GMT
Subject: RFR: 8305943: Open source few AWT Focus related tests
Message-ID: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>

This opensources few AWT Focus related tests.
CI runs are ok.

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

Commit messages:
 - 8305943: Open source few AWT Focus related tests

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

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


From psadhukhan at openjdk.org  Wed Apr 19 09:25:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Apr 2023 09:25:12 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests
Message-ID: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>

This opensources several other AWT Focus related tests.
CI runs are ok.

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

Commit messages:
 - 8305942: Open source several AWT Focus related tests

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

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


From azvegint at openjdk.org  Wed Apr 19 10:06:45 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 19 Apr 2023 10:06:45 GMT
Subject: RFR: 8306135: Clean up and open source some AWT tests [v3]
In-Reply-To: <ElQgCpFTFcchS8gBKAc0rOImss0FvYyb067b9C2lG6o=.24b78e0e-7c99-4acf-a8c1-b6cc8259c38e@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
 <ElQgCpFTFcchS8gBKAc0rOImss0FvYyb067b9C2lG6o=.24b78e0e-7c99-4acf-a8c1-b6cc8259c38e@github.com>
Message-ID: <MDJbmD8R5xRk1_unPOcm-Nld-ChZRqZXTulfYmHCvq8=.f0dae3d8-ed76-47e8-8ae4-92ef5b1d6e9a@github.com>

On Tue, 18 Apr 2023 20:29:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Cleaning up and open sourcing three AWT tests
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Splitting couple of extra long lines to keep it more readable

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13518#pullrequestreview-1391722502


From azvegint at openjdk.org  Wed Apr 19 10:13:57 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 19 Apr 2023 10:13:57 GMT
Subject: RFR: 8306134: Open source some AWT tests relating to Button and a
 few other classes
In-Reply-To: <BCznwITmdy2-s_zwgrSFZPPPrDs0l7fCGVkgGfu3tsE=.143ee34f-234d-4a55-ad7a-ec3a96cc28e2@github.com>
References: <BCznwITmdy2-s_zwgrSFZPPPrDs0l7fCGVkgGfu3tsE=.143ee34f-234d-4a55-ad7a-ec3a96cc28e2@github.com>
Message-ID: <PUn6-v4jSCsjLkY9O7gMipuQnH3XUWdtE0ch4EilKVs=.02cdf805-725d-48e0-9d87-3a2d613255f6@github.com>

On Tue, 18 Apr 2023 21:22:23 GMT, Phil Race <prr at openjdk.org> wrote:

> This open sources a few simple AWT jtreg tests that are overdue to be opened.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13520#pullrequestreview-1391734564


From mbaesken at openjdk.org  Wed Apr 19 10:45:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Apr 2023 10:45:48 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
Message-ID: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>

After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.

Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

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

Commit messages:
 - JDK-8304291

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

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


From mdoerr at openjdk.org  Wed Apr 19 10:53:51 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Apr 2023 10:53:51 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <tv8X_Px7ppaSb2p0fpThlrpEqrqK1XEDFB43D_YhxkI=.ad55193c-fc1b-4c05-bec8-acd861ff68d5@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

LGTM. Thanks for fixing the AIX build! I think we will need this fix for 11u and 17u because we will probably stick with xlc 16 for these releases.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13529#pullrequestreview-1391795403


From jdv at openjdk.org  Wed Apr 19 11:29:41 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 19 Apr 2023 11:29:41 GMT
Subject: RFR: 8306280: Open source several choice AWT tests
In-Reply-To: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
References: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
Message-ID: <_jEW-O5osjPeHaOXeI9asbrAPtQLWcoJgTdXiKOv94s=.c5c8e539-5ff8-469a-a646-4e793ec4279d@github.com>

On Tue, 18 Apr 2023 21:47:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT choice tests.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13521#pullrequestreview-1391850959


From duke at openjdk.org  Wed Apr 19 13:05:59 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 19 Apr 2023 13:05:59 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <1P4W0dAhJfkFtBtGoeQ0ZQ30sKh1mDJCj6NdEZnrolI=.f8cb190a-ad8a-4ddc-8e06-02dc055371a4@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

Looks good, tests still pass on Debian RISC-V 64.

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

Marked as reviewed by Glavo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392016242


From mdoerr at openjdk.org  Wed Apr 19 13:26:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Apr 2023 13:26:02 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

test/jdk/jdk/internal/util/ArchTest.java line 71:

> 69:             case "aarch64" -> AARCH64;
> 70:             case "riscv64" -> RISCV64;
> 71:             case "s390x", "s390" -> S390;  // unverified

This was also verified according to comments. Right, @offamitkumar?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171335657


From tsteele at openjdk.org  Wed Apr 19 16:25:47 2023
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 19 Apr 2023 16:25:47 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <e-F3sxQefYXv--R3GkGvvxgCL1fep0Bs-VRe3rUIBWM=.d18086b2-8810-43f5-a2ef-f028cb855833@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

I really appreciate your work on this one @MBaesken! This fix looks good.

I agree with Martin that we will want this to make its way to jdk17 and 11. Let me know if you would like me to take point on that task.

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

Marked as reviewed by tsteele (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13529#pullrequestreview-1392448631


From amitkumar at openjdk.org  Wed Apr 19 16:26:02 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 19 Apr 2023 16:26:02 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
 <N_Q4PZHygDCHkRCmB0QS3iSVuqgfNYRzx9YtgKyjUMk=.d987527f-55bb-432e-a450-c7ac6e675ca9@github.com>
Message-ID: <j2mRsyfdr2C1wXxCK9OaKdxMJlluaQ-Ynl22G0JqZ8c=.f382277e-57bb-4976-abe4-37d0f99aa66e@github.com>

On Wed, 19 Apr 2023 13:22:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into 8304915-arch-enum
>>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>>  - Fixed isPPC64().
>>    Consolidated switch cases in ArchTest.
>>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>>    to avoid multiple mappings in more than one place.
>>  - Correct mapping and test of ppc64
>>  - Add ppc64 as mapping to PPC64 Architecture
>>  - Modified test to check Architecture is64bits() and isLittleEndian()
>>    against Unsafe respective values.
>>    Relocated code mapping OS name and arch name from PlatformProps to
>>    OperatingSystem and Architecture. Kept the mapping of names
>>    in the template close to where the values are filled in by the build.
>>  - Remove unused static and import of Stabile
>>  - Rename OperatingSystemProps to PlatformProps.
>>    Refactor OperatingSystem initialization to use strings instead of integers.
>>  - Revised mapping mechanism of build target architecture names to enum values.
>>    Unrecognized values from the build are mapped to enum value "OTHER".
>>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>>  - Revert changes to jdk.accessibility AccessBridge
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e
>
> test/jdk/jdk/internal/util/ArchTest.java line 71:
> 
>> 69:             case "aarch64" -> AARCH64;
>> 70:             case "riscv64" -> RISCV64;
>> 71:             case "s390x", "s390" -> S390;  // unverified
> 
> This was also verified according to comments. Right, @offamitkumar?

Yes, you're correct @TheRealMDoerr

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171580811


From amitkumar at openjdk.org  Wed Apr 19 16:29:57 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 19 Apr 2023 16:29:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v15]
In-Reply-To: <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <v70Qlm6isdELJyKillp5C5xwzw0vdCRthQQDD2o1u0U=.e807d28e-2041-479e-8b26-9778e73f8817@github.com>
Message-ID: <gxHeSPU6S7putMSzEFeMMoFG9Fmeuu7X2bfP8U6_VQc=.6cb3f50a-d1ff-453a-924e-44ba28b74029@github.com>

On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into 8304915-arch-enum
>  - ArchTest on Debian RISC-V 64 confirmed by reviewer
>  - Fixed isPPC64().
>    Consolidated switch cases in ArchTest.
>    Moved mapping of build TARGET_OS and TARGET_CPU to the build
>    to avoid multiple mappings in more than one place.
>  - Correct mapping and test of ppc64
>  - Add ppc64 as mapping to PPC64 Architecture
>  - Modified test to check Architecture is64bits() and isLittleEndian()
>    against Unsafe respective values.
>    Relocated code mapping OS name and arch name from PlatformProps to
>    OperatingSystem and Architecture. Kept the mapping of names
>    in the template close to where the values are filled in by the build.
>  - Remove unused static and import of Stabile
>  - Rename OperatingSystemProps to PlatformProps.
>    Refactor OperatingSystem initialization to use strings instead of integers.
>  - Revised mapping mechanism of build target architecture names to enum values.
>    Unrecognized values from the build are mapped to enum value "OTHER".
>    Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness.
>    Added an `isLittleEndian` method to return the endianness (not currently used anywhere)
>  - Revert changes to jdk.accessibility AccessBridge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e

for s390x, build is fine and tier1 (specifically `ArchTest.java`) passes. 

Thanks for the change.

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

Marked as reviewed by amitkumar (Author).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392455297


From rmahajan at openjdk.org  Wed Apr 19 16:37:56 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 16:37:56 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v3]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <3280qgDBfovZiyTKKkSxwW4llM0Gxiq3BJT00KowDN0=.3ad1f07a-22f6-468d-bfdf-8afe7d6bd1db@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/ea200b96..c8bd3d99

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

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

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


From aivanov at openjdk.org  Wed Apr 19 16:38:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Apr 2023 16:38:04 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v2]
In-Reply-To: <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <6FAOrrset-wlKYwrPwT13t1zmgwf-w0EJdSwRS_2SBk=.24fe9000-54ee-4110-9dcf-f71ef10e36ad@github.com>
Message-ID: <ncZnqEHT6c1Ytwi-qnn0cgNgqtAK9Cae6PzrbLO1Lf4=.a2e5b3de-1a68-452a-b5da-41a471af07f3@github.com>

On Fri, 14 Apr 2023 22:48:41 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and test changes as requested in code review

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2023 Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 1995, 2023, Oracle and/or its affiliates. All rights reserved.

You always update the second year leaving the first one intact. The comma after the year should remain.

src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 113:

> 111:         int missinginfo = flags & ~availinfo;
> 112:         if ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0
> 113:              && missinginfo != 0) {

Suggestion:

        if ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0
            && missinginfo != 0) {

Nit: the wrapped line should be aligned to the opening parenthesis of the `if`, otherwise it looks as if the wrapped condition is part of the condition in the parentheses but it is not.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 1:

> 1: /*

I [still](https://github.com/openjdk/jdk/pull/13414#discussion_r1164573562) think the test should not be in `test/jdk/javax/imageio/plugins/gif` because it does **not** test the GIF Image IO plugin. A better location is under `test/java/awt/Clipboard`.

Now that there's no external GIF image file, the bugid directory has become unnecessary. We're striving to keep test structure flatter without creating a new folder for each test as it used to be done previously.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 80:

> 78:             (byte) 0x8f, (byte) 0x19, (byte) 0x05, (byte) 0x00, (byte) 0x3b
> 79:     };
> 80:     private void createGUI() {

Please add a blank line between methods, fields and methods, between class declarations.

A blank line between unrelated fields is also a good idea.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 95:

> 93:         Clipboard sys = Toolkit.getDefaultToolkit().getSystemClipboard();
> 94:         sys.setContents(new MyTransferable(img), null);
> 95: 

The blank line in the end of the method is redundant.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 122:

> 120:         }
> 121: 
> 122:     }

Suggestion:

        if (!latch.await(TIMEOUT, MILLISECONDS)) {
            throw new RuntimeException("Image copying taking too long.");
        } else {
            EventQueue.invokeAndWait(CopyAnimatedGIFTest::dispose);
        }
    }

Let's follow Java Coding Style conventions.

I can't help [raising the question](https://github.com/openjdk/jdk/pull/13414#discussion_r1164559765) again:
> I think it also deserves a comment why the frame is disposed of only when the test doesn't fail. Perhaps, we can drop disposing altogether and let jtreg do the cleanup.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 129:

> 127:         }
> 128:     }
> 129:     private static class imgCanvas extends Canvas {

Class names start with a capital letter, method names and fields start with a lower-case letter.

> Is `ImageCanvas` a better name?

Other points from [this comment](https://github.com/openjdk/jdk/pull/13414#discussion_r1164566145) have been addressed.

test/jdk/javax/imageio/plugins/gif/6176679/CopyAnimatedGIFTest.java line 168:

> 166:     }
> 167: 
> 168: }

Please add a final blank line.

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

PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1392427528
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171565235
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171570420
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171586456
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171571310
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171571851
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171577529
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171579809
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1171580741


From prr at openjdk.org  Wed Apr 19 16:58:43 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 16:58:43 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <mL9Hbvh_scprNEcjY-RPAJAgx3riHkmfcbW3uhfwO7E=.38f6d9ab-4d08-4a12-822b-735e8e3c0831@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

As a rule, we don't make changes to 3rd party code principally for the reason that it needs to be re-changed every time we upgrade. After some off-line discussion with the devs working on the AIX port of OpenJDK, we can make an exception here, and they will take care of re-applying it if it is still needed next time round.
And these changes only affect AIX of course ..

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13529#pullrequestreview-1392502653


From kizune at openjdk.org  Wed Apr 19 16:59:00 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 19 Apr 2023 16:59:00 GMT
Subject: Integrated: 8306135: Clean up and open source some AWT tests
In-Reply-To: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
References: <2dRArWauOQvxiqlMPWY7TCBBFWQDHRPJozWEFoRFn50=.b3890e86-295c-4b93-b645-c2feee1b6d60@github.com>
Message-ID: <sOr8b6cnJ7GUAEPZM_hhUcbpVQ0HU536fyFMnOJdCy4=.81abb2a0-7e50-4d9d-9d2b-e6b8411b49c3@github.com>

On Tue, 18 Apr 2023 18:55:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up and open sourcing three AWT tests

This pull request has now been integrated.

Changeset: 4ad3ac63
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ad3ac6317f6fc95fdf0340885d4099e785132ad
Stats:     360 lines in 3 files changed: 360 ins; 0 del; 0 mod

8306135: Clean up and open source some AWT tests

Reviewed-by: azvegint

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

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


From prr at openjdk.org  Wed Apr 19 17:01:49 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:01:49 GMT
Subject: RFR: 8306280: Open source several choice AWT tests
In-Reply-To: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
References: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
Message-ID: <i4u1lBABton6T7_WZx_NnyI48sF_bQZkpFf5TZeBpqw=.664b583b-880d-487f-838d-218bcc31196d@github.com>

On Tue, 18 Apr 2023 21:47:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT choice tests.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13521#pullrequestreview-1392508493


From prr at openjdk.org  Wed Apr 19 17:18:51 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:18:51 GMT
Subject: RFR: 8306320: Add @implSpec for explaining BufferedImage default
 behavior
In-Reply-To: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
Message-ID: <OCtVGOrNZ3OC_l5VEnLzDDETEj9CYkv5WSiErfumCfQ=.b2ac189b-4add-4d8f-b18d-8fd5e0aa3dfe@github.com>

On Tue, 18 Apr 2023 09:30:07 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
> 
> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
> 
> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1544:

> 1542:    * it receives multiple notifications.
> 1543:    *
> 1544:    * @implSpec

I don't think this needs to be implSpec. I think we can say : 
This method ignores its parameters and does nothing, since {@code BufferedImage} is always checked out for writing and cannot be made read-only, so there can never be events to dispatch.

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1560:

> 1558:    * notifications, it is now registered for one fewer notification.
> 1559:    *
> 1560:    * @implSpec

ditto

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1596:

> 1594:      * point with (0,0) coordinates since {@code BufferedImage}
> 1595:      * {@linkplain #getRaster() single tile} is always checked out
> 1596:      * for writing.

I think there's some missing punctuation there.

I'd like to slip in some  additional explanation that (0,0) is always going to be the offset because what else can it be if you only have one tile ?
The text about "default implementation" in these updated docs might be misinterpreted as there's an alternative implementation .. I don't think there can be .. not in any compatible way.
All these methods should have been made final. Sadly its too late for that but we need to be clear that this is what you can rely on for a BufferedImage and any subclass that changes it is breaking the contract.

How about -
Since a {@code BufferedImage} consists of a single tile, and that tile is always checked out for writing,
this method, will always return an array of one point.
Further, in  any case of an image with a single tile, the offset will always be (0,0), that will always be the coordinates of the single returned {@code Point}.

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1631:

> 1629:    * {@linkplain #getRaster() single tile} without checking
> 1630:    * the passed values. No listeners are notified since the
> 1631:    * returned tile is always checked out for writing.

similar to above

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1655:

> 1653:    * without checking the passed values. No listeners are notified
> 1654:    * since the {@linkplain #getRaster() single tile} is always
> 1655:    * checked out for writing.

similar to above

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

PR Review: https://git.openjdk.org/jdk/pull/13506#pullrequestreview-1392518605
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1171625687
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1171626413
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1171636385
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1171636760
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1171636811


From prr at openjdk.org  Wed Apr 19 17:20:43 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:20:43 GMT
Subject: RFR: 8305943: Open source few AWT Focus related tests
In-Reply-To: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
References: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
Message-ID: <XnV7bD7pFF10fTV_ZqmGZOYPbahPGSD3IiAIhDOzZ3A=.1d65d84f-deb7-4c29-9002-f1d1f56b2b7d@github.com>

On Wed, 19 Apr 2023 07:28:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Focus related tests.
> CI runs are ok.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13525#pullrequestreview-1392550445


From prr at openjdk.org  Wed Apr 19 17:25:47 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:25:47 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests
In-Reply-To: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
Message-ID: <LBXBMq3o-30ARSlow25ZvHH60PA3G-AUi905HLq48Oo=.6c205a52-5d59-4052-8002-4e95123d4018@github.com>

On Wed, 19 Apr 2023 09:16:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources several other AWT Focus related tests.
> CI runs are ok.

test/jdk/java/awt/Focus/QuickTypeTest.java line 26:

> 24:   @test
> 25:   @bug 4423838
> 26:   @summary KEY_TYPED and KEY_PRESSED generated by the same key are notified to different fi

"fi" ? 
I think a previous bug tracker had a limit on the summary field and truncated "fields"
and that was copied from the tracker to the test .. but really we should fix that.
And I think "TextFields" is the right word.

test/jdk/java/awt/Focus/QuickTypeTest.java line 67:

> 65:             EventQueue.invokeAndWait(() -> {
> 66:                 // Check for Win32 environment. This test is only for Win32.
> 67:                 Properties prop = System.getProperties();

Is it really ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171644427
PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171645106


From prr at openjdk.org  Wed Apr 19 17:40:59 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:40:59 GMT
Subject: Integrated: 8306134: Open source some AWT tests relating to Button and
 a few other classes
In-Reply-To: <BCznwITmdy2-s_zwgrSFZPPPrDs0l7fCGVkgGfu3tsE=.143ee34f-234d-4a55-ad7a-ec3a96cc28e2@github.com>
References: <BCznwITmdy2-s_zwgrSFZPPPrDs0l7fCGVkgGfu3tsE=.143ee34f-234d-4a55-ad7a-ec3a96cc28e2@github.com>
Message-ID: <HwMZ1Cio3NZSHDt8ZaFi4xRaoq0BBrILGWCQ3Yjz5aE=.1f7c7973-3c6c-4371-86a4-95e8e9752aa8@github.com>

On Tue, 18 Apr 2023 21:22:23 GMT, Phil Race <prr at openjdk.org> wrote:

> This open sources a few simple AWT jtreg tests that are overdue to be opened.

This pull request has now been integrated.

Changeset: fdb4bafa
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdb4bafa3142cedeb9eb3cb930890e97b35402de
Stats:     739 lines in 6 files changed: 739 ins; 0 del; 0 mod

8306134: Open source some AWT tests relating to Button and a few other classes

Reviewed-by: azvegint

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

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


From rmahajan at openjdk.org  Wed Apr 19 17:47:47 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 17:47:47 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v4]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <qkcp13Xob4AyTolzCcLYx9Dz3NEdOd5SZpBeA80jEjU=.382d7c96-0f38-4013-a608-e774892ccc7d@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision:

 - code cleanup
 - code cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/c8bd3d99..003eb7ea

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

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

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


From rmahajan at openjdk.org  Wed Apr 19 17:57:01 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 17:57:01 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v5]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <iJ2OSomNaihwL8C02RnKQNQ7JGqsCnUoUVBixaC8mJQ=.eff7e800-09f2-44be-9378-650e5bec6213@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

  remove the bug folder and fix end of line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/003eb7ea..f78f58ff

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

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

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


From prr at openjdk.org  Wed Apr 19 17:56:55 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 17:56:55 GMT
Subject: RFR: 8306372: Open source AWT CardLayout and Checkbox tests
Message-ID: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>

Moves to open some AWT tests, two for CardLayout and four for CheckBox

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

Commit messages:
 - 8306372

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

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


From rmahajan at openjdk.org  Wed Apr 19 17:59:38 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 17:59:38 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v6]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <QT1SSce94PNbt_Wiv0UCJYP72ah92QmDyvQKLsXFvco=.0814f479-7c1b-4ac3-9535-67fc723640a7@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

  fix end of line for file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/f78f58ff..991b8526

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=04-05

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

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


From rriggs at openjdk.org  Wed Apr 19 18:08:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 18:08:40 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v16]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <SFXvfinAdc_NguDE-7Pbg6-e29KfL5xmDl1a8gtjKSk=.b07c2f89-f489-44bb-8c31-39035e6969ca@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Use and test of "s390" verified by reviewer.
 - Merge branch 'master' into 8304915-arch-enum
 - Merge branch 'master' into 8304915-arch-enum
 - ArchTest on Debian RISC-V 64 confirmed by reviewer
 - Fixed isPPC64().
   Consolidated switch cases in ArchTest.
   Moved mapping of build TARGET_OS and TARGET_CPU to the build
   to avoid multiple mappings in more than one place.
 - Correct mapping and test of ppc64
 - Add ppc64 as mapping to PPC64 Architecture
 - Modified test to check Architecture is64bits() and isLittleEndian()
   against Unsafe respective values.
   Relocated code mapping OS name and arch name from PlatformProps to
   OperatingSystem and Architecture. Kept the mapping of names
   in the template close to where the values are filled in by the build.
 - Remove unused static and import of Stabile
 - Rename OperatingSystemProps to PlatformProps.
   Refactor OperatingSystem initialization to use strings instead of integers.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/0f3828dd...b95a312d

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

Changes: https://git.openjdk.org/jdk/pull/13357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15
  Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

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


From serb at openjdk.org  Wed Apr 19 18:25:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Apr 2023 18:25:51 GMT
Subject: RFR: 8306372: Open source AWT CardLayout and Checkbox tests
In-Reply-To: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
References: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
Message-ID: <_yMk6KTzBZs9DnBPrd_PoJK9v7XIqaEEA8SBgiIVwHA=.2c76c026-618d-401f-bf65-061f868e91d1@github.com>

On Wed, 19 Apr 2023 17:48:25 GMT, Phil Race <prr at openjdk.org> wrote:

> Moves to open some AWT tests, two for CardLayout and four for CheckBox

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13543#pullrequestreview-1392653524


From serb at openjdk.org  Wed Apr 19 18:28:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Apr 2023 18:28:43 GMT
Subject: RFR: 8305943: Open source few AWT Focus related tests
In-Reply-To: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
References: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
Message-ID: <WAlU7ZoMjPMU3qNgZiy81aXtHMg_GQ1idGYd3iu3Qts=.0f97b095-69a4-46c0-b6ea-1aba940d8f80@github.com>

On Wed, 19 Apr 2023 07:28:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Focus related tests.
> CI runs are ok.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13525#pullrequestreview-1392656875


From serb at openjdk.org  Wed Apr 19 18:28:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Apr 2023 18:28:43 GMT
Subject: RFR: 8306280: Open source several choice AWT tests
In-Reply-To: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
References: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
Message-ID: <VeIKLF1Kju0LM6Wms3INMCbwJBrPt1YqhCmfjkieehI=.494ad377-0d1e-44b0-b622-3786e191c0f9@github.com>

On Tue, 18 Apr 2023 21:47:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT choice tests.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13521#pullrequestreview-1392657652


From honkar at openjdk.org  Wed Apr 19 18:28:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 19 Apr 2023 18:28:45 GMT
Subject: RFR: 8306372: Open source AWT CardLayout and Checkbox tests
In-Reply-To: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
References: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
Message-ID: <d2EpevIlb-T2v5s5_7oKK5yLNAHexfm3sJPIR1aj2ZM=.b3cc3cc8-8b06-4b64-b0a0-556072184d6e@github.com>

On Wed, 19 Apr 2023 17:48:25 GMT, Phil Race <prr at openjdk.org> wrote:

> Moves to open some AWT tests, two for CardLayout and four for CheckBox

Marked as reviewed by honkar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13543#pullrequestreview-1392657898


From azvegint at openjdk.org  Wed Apr 19 18:59:01 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 19 Apr 2023 18:59:01 GMT
Subject: Integrated: 8306280: Open source several choice AWT tests
In-Reply-To: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
References: <5htc753ZJLKcTrABnjd_phCA6qHrj_wz52rbkQiBrd0=.abc00729-a0a7-44e8-827d-0741fa8e6695@github.com>
Message-ID: <mThMy3xXN0petwuGpjjWIKplhMzuDeXkCXcqDN1Idf8=.ed045156-c388-4b9b-be50-2a0400e24d5a@github.com>

On Tue, 18 Apr 2023 21:47:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT choice tests.

This pull request has now been integrated.

Changeset: d03128d0
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d03128d0e5158ea967e714341c019b9af00ac4a1
Stats:     435 lines in 4 files changed: 435 ins; 0 del; 0 mod

8306280: Open source several choice AWT tests

Reviewed-by: jdv, prr, serb

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

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


From aturbanov at openjdk.org  Wed Apr 19 18:59:45 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 19 Apr 2023 18:59:45 GMT
Subject: RFR: 8306372: Open source AWT CardLayout and Checkbox tests
In-Reply-To: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
References: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
Message-ID: <bgaLQwFdz2tJH9ZhLUONdMWV6TfXK2PQ3CqMNesrWPc=.e3afb8ec-ce6f-4fc6-bca9-bce63cfc01d9@github.com>

On Wed, 19 Apr 2023 17:48:25 GMT, Phil Race <prr at openjdk.org> wrote:

> Moves to open some AWT tests, two for CardLayout and four for CheckBox

test/jdk/java/awt/Checkbox/CheckboxCrashTest.java line 35:

> 33: import java.awt.Frame;
> 34: 
> 35: public class CheckboxCrashTest  {

nit
Suggestion:

public class CheckboxCrashTest {

test/jdk/java/awt/Checkbox/MultiCheckedCheckboxGroupTest.java line 48:

> 46:         System.out.println("gr.getSelectedCheckbox="+gr.getSelectedCheckbox());
> 47: 
> 48:         if(chb1.getState()

Suggestion:

        if (chb1.getState()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13543#discussion_r1171742395
PR Review Comment: https://git.openjdk.org/jdk/pull/13543#discussion_r1171742665


From aturbanov at openjdk.org  Wed Apr 19 19:14:47 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 19 Apr 2023 19:14:47 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests
In-Reply-To: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
Message-ID: <YFa4fXtUA4ZuwouhYB6ol_X6GuTLBJZXWeaLUixKHPw=.1ccfde38-5f19-4fb6-97b8-7c3ec9f54439@github.com>

On Wed, 19 Apr 2023 09:16:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources several other AWT Focus related tests.
> CI runs are ok.

test/jdk/java/awt/Focus/TemporaryLostComponentDeadlock.java line 52:

> 50:         Thread t1 = new Thread() {
> 51:             public void run() {
> 52:                 synchronized(frame1) {

Suggestion:

                synchronized (frame1) {

test/jdk/java/awt/Focus/TemporaryLostComponentDeadlock.java line 54:

> 52:                 synchronized(frame1) {
> 53:                     frame1.dispose();
> 54:                     synchronized(frame1) {

Suggestion:

                    synchronized (frame1) {

test/jdk/java/awt/Focus/TemporaryLostComponentDeadlock.java line 61:

> 59:         };
> 60:         try {
> 61:             synchronized(frame1) {

Suggestion:

            synchronized (frame1) {

test/jdk/java/awt/Focus/TemporaryLostComponentDeadlock.java line 65:

> 63:                 frame1.wait();
> 64:             }
> 65:         } catch( InterruptedException ie) {

Suggestion:

        } catch (InterruptedException ie) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171754879
PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171755129
PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171755394
PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1171755534


From rmahajan at openjdk.org  Wed Apr 19 20:17:54 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 20:17:54 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v7]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <RRpbjxSie3nCtB8rAvUwQ_Ck5b5lS3MaEJv99HCl3gg=.4cfd6360-e122-4cf7-af46-9ff99137c85b@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

  remove dispose() since jtreg will take care of disposing of the frame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/991b8526..eac1565e

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

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

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


From rmahajan at openjdk.org  Wed Apr 19 20:26:54 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 19 Apr 2023 20:26:54 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v8]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <g1M3jWZJtAPjUYjRyht9dmD6lWSfuG63cUPkn-FF61s=.586bb168-242d-4ee7-971f-b535b3cf971f@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

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

  code cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/eac1565e..a2302d49

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

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

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


From prr at openjdk.org  Wed Apr 19 20:56:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 19 Apr 2023 20:56:54 GMT
Subject: Integrated: 8306372: Open source AWT CardLayout and Checkbox tests
In-Reply-To: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
References: <vE9Dx8-p8VZEw--ykBf5bAoTrxU0ARDPOLhjb9mNcnE=.844e333c-afe2-403d-b861-fb3b43a12dc8@github.com>
Message-ID: <qqQhikZU4C2ZsTTUfAMiwkbrnpXugjdGmjVvGmdrhkM=.b3da2429-6416-4bbd-ac99-7e7f0a031561@github.com>

On Wed, 19 Apr 2023 17:48:25 GMT, Phil Race <prr at openjdk.org> wrote:

> Moves to open some AWT tests, two for CardLayout and four for CheckBox

This pull request has now been integrated.

Changeset: 781d6d79
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/781d6d793ad4cecb774bcbcb362c726779408ffd
Stats:     364 lines in 6 files changed: 364 ins; 0 del; 0 mod

8306372: Open source AWT CardLayout and Checkbox tests

Reviewed-by: serb, honkar

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

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


From duke at openjdk.org  Wed Apr 19 21:37:46 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 19 Apr 2023 21:37:46 GMT
Subject: RFR: 8182025: PropertyDescriptor ignores default methods from
 interfaces implemented by superclasses
Message-ID: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>

The `Introspector` class was never updated to include `default` methods inherited from interfaces.

This patch attempts to fix that omission.

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

Commit messages:
 - Include default methods inherited from interfaces in bean introspection.

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

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


From liach at openjdk.org  Wed Apr 19 21:44:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 21:44:42 GMT
Subject: RFR: 8182025: PropertyDescriptor ignores default methods from
 interfaces implemented by superclasses
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <Dig_ro5tq6jJd_Rchyvpxrinakl9XWnLb6kKJE_Ks_k=.0015bcda-173f-4dd1-81e4-9d554a7ce776@github.com>

On Wed, 19 Apr 2023 21:29:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 46:

> 44: final class MethodInfo {
> 45: 
> 46:     static final HashSet<Class<?>> IGNORABLE_INTERFACES = new HashSet<>(6);

Suggestion:

    static final HashSet<Class<?>> IGNORABLE_INTERFACES = HashSet.newHashSet(6);

Or even better, use Set.of instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1171880936


From duke at openjdk.org  Wed Apr 19 21:58:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 19 Apr 2023 21:58:44 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <W__mW92btaQ-uZCjHDDbZ_VL9bwojekBQg1Qx3c4xAE=.5c784da1-6b92-4664-b9f0-bda71b37aa33@github.com>

On Wed, 19 Apr 2023 21:29:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

This one probably needs a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1515434981


From duke at openjdk.org  Wed Apr 19 22:05:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 19 Apr 2023 22:05:33 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Use Set.of() to initialize IGNORABLE_INTERFACES set.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/b343ba1f..e37a1467

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

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

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


From duke at openjdk.org  Wed Apr 19 22:05:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 19 Apr 2023 22:05:36 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <Dig_ro5tq6jJd_Rchyvpxrinakl9XWnLb6kKJE_Ks_k=.0015bcda-173f-4dd1-81e4-9d554a7ce776@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Dig_ro5tq6jJd_Rchyvpxrinakl9XWnLb6kKJE_Ks_k=.0015bcda-173f-4dd1-81e4-9d554a7ce776@github.com>
Message-ID: <4g0Vdo7T9qsjPkaUuOTckdCeOb1WVRsVg5Vk3U16Gfs=.57868bd5-5925-4ed1-bd17-dcd26e4258dc@github.com>

On Wed, 19 Apr 2023 21:40:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Set.of() to initialize IGNORABLE_INTERFACES set.
>
> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 46:
> 
>> 44: final class MethodInfo {
>> 45: 
>> 46:     static final HashSet<Class<?>> IGNORABLE_INTERFACES = new HashSet<>(6);
> 
> Suggestion:
> 
>     static final HashSet<Class<?>> IGNORABLE_INTERFACES = HashSet.newHashSet(6);
> 
> Or even better, use Set.of instead.

Thanks, much cleaner. Fixed in e37a1467a57.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1171894172


From psadhukhan at openjdk.org  Thu Apr 20 02:37:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Apr 2023 02:37:56 GMT
Subject: Integrated: 8305943: Open source few AWT Focus related tests
In-Reply-To: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
References: <DCztPXNSjGqeIJBWQyOiJGB4_AHJARKciWZl0BJ9yiE=.201bdb0b-018b-462a-bd17-039636908eb6@github.com>
Message-ID: <HXY20_qdZ21bHMOiz3YdlAbnFByDp0VEAmM0fxefyLM=.64f8f263-11f8-409a-b7a9-4aa9f36af50c@github.com>

On Wed, 19 Apr 2023 07:28:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Focus related tests.
> CI runs are ok.

This pull request has now been integrated.

Changeset: 64ed816a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64ed816ad9f1a9773c9865a013e89b709a130e9c
Stats:     765 lines in 5 files changed: 765 ins; 0 del; 0 mod

8305943: Open source few AWT Focus related tests

Reviewed-by: prr, serb

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

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


From psadhukhan at openjdk.org  Thu Apr 20 02:57:08 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Apr 2023 02:57:08 GMT
Subject: RFR: 8306060: Open source few AWT Insets related tests
Message-ID: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>

This PR opensources few AWT Insets tests

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

Commit messages:
 - 8306060: Open source few AWT Insets related tests

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

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


From psadhukhan at openjdk.org  Thu Apr 20 03:53:04 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Apr 2023 03:53:04 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests [v2]
In-Reply-To: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
Message-ID: <cRnA2JJowrm8k-T6DrskIpgqFdK5Imq0_7Qxgtgx28Y=.bc94f110-8b36-41a1-81e2-993a4c740914@github.com>

> This opensources several other AWT Focus related tests.
> CI runs are ok.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Remove start comment
 - Made test to run on all headful platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13527/files
  - new: https://git.openjdk.org/jdk/pull/13527/files/1a76dbae..29ad21bb

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

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

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


From psadhukhan at openjdk.org  Thu Apr 20 03:53:06 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Apr 2023 03:53:06 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests [v2]
In-Reply-To: <LBXBMq3o-30ARSlow25ZvHH60PA3G-AUi905HLq48Oo=.6c205a52-5d59-4052-8002-4e95123d4018@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
 <LBXBMq3o-30ARSlow25ZvHH60PA3G-AUi905HLq48Oo=.6c205a52-5d59-4052-8002-4e95123d4018@github.com>
Message-ID: <Rcdzv2yPS4euHM4xJdlo7qvNNfUwfFRdOA0e0oau7-I=.d3d49d30-120f-431d-bffc-c0002d2f61e5@github.com>

On Wed, 19 Apr 2023 17:22:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove start comment
>>  - Made test to run on all headful platforms
>
> test/jdk/java/awt/Focus/QuickTypeTest.java line 26:
> 
>> 24:   @test
>> 25:   @bug 4423838
>> 26:   @summary KEY_TYPED and KEY_PRESSED generated by the same key are notified to different fi
> 
> "fi" ? 
> I think a previous bug tracker had a limit on the summary field and truncated "fields"
> and that was copied from the tracker to the test .. but really we should fix that.
> And I think "TextFields" is the right word.

ok

> test/jdk/java/awt/Focus/QuickTypeTest.java line 67:
> 
>> 65:             EventQueue.invokeAndWait(() -> {
>> 66:                 // Check for Win32 environment. This test is only for Win32.
>> 67:                 Properties prop = System.getProperties();
> 
> Is it really ?

Took the test as it is..maybe at the time of test being wriiten, there was some issue with other platforms..
seems to be working on mach5 headful platforms, so remove the windows restriction

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1172050753
PR Review Comment: https://git.openjdk.org/jdk/pull/13527#discussion_r1172051189


From duke at openjdk.org  Thu Apr 20 05:04:49 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Thu, 20 Apr 2023 05:04:49 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v3]
In-Reply-To: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
Message-ID: <z3QvFGOO9QNb_-hXlGkQPyMMkn03aiGEZkuAXHU9IOY=.03e185c3-9f50-420e-a255-b00da2374321@github.com>

> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  8305427: Code modified to wait for FOCUS_GAINED event to perform.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13293/files
  - new: https://git.openjdk.org/jdk/pull/13293/files/1905d463..2f071815

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

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

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


From itakiguchi at openjdk.org  Thu Apr 20 05:54:34 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 20 Apr 2023 05:54:34 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded
Message-ID: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>

"character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1"
https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf
It refers windgi.h
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica

Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542)

Additional change:
Special character `\line` should `\n`

**Note:** Following GitHub actions were failed
linux-x86 / test (jdk/tier1 part 1) was failed, it seems it was already reported
> [JDK-8305875](https://bugs.openjdk.org/browse/JDK-8305875) Test TraceVirtualThreadLocals should be run with continuations only

windows-aarch64 / build (debug) was failed, but I have no idea...

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

Commit messages:
 - 6928542: Chinese characters in RTF are not decoded

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

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


From duke at openjdk.org  Thu Apr 20 05:58:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 20 Apr 2023 05:58:42 GMT
Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans
 projects
In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com>
Message-ID: <qM4NtGusT3g3_hriV7iUtYgCIk0PvL-ndOFBQCAY44E=.649c11dd-76a6-42a1-83bc-6b7c69d3e504@github.com>

On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. 
> 
> The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging:
> 
> 
> <jvmarg value="-Xdebug"/>
> <jvmarg value="-Xnoagent"/>
> <jvmarg value="-Djava.compiler=none"/>
> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
> 
> 
> They should instead just do:
> 
> 
> <jvmarg value="-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=${jpda.address}"/>
> 
> 
> Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout.
> 
> `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/`

The removal of the `java.compiler` system property just got integrated:

https://github.com/openjdk/jdk/pull/13475

It would be good to get the arcaic usage of `java.compiler` in these Netbeans projects updated.

Looking for reviewers :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1515754069


From serb at openjdk.org  Thu Apr 20 06:38:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Apr 2023 06:38:43 GMT
Subject: RFR: 8306060: Open source few AWT Insets related tests
In-Reply-To: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
References: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
Message-ID: <4iCsoY4A89b22dR9iRBydzuBHPK88QtDON8R8FsSVMI=.cc92f95a-939c-4fed-a449-4da4741ad311@github.com>

On Thu, 20 Apr 2023 02:49:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This PR opensources few AWT Insets tests

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13552#pullrequestreview-1393293353


From mbaesken at openjdk.org  Thu Apr 20 07:10:54 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Apr 2023 07:10:54 GMT
Subject: RFR: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <zKF2hiY-1kHe_uc_locmnT6U4xbX43E9KnMb4d7ioss=.8a5bdadc-82ea-4acd-a20d-1c43827fa87a@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

Hi Tyler, Phil, Martin, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/13529#issuecomment-1515818013


From mbaesken at openjdk.org  Thu Apr 20 07:10:56 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Apr 2023 07:10:56 GMT
Subject: Integrated: JDK-8304291: [AIX] Broken build after JDK-8301998
In-Reply-To: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
References: <zINjMdCOULeEVrdqkd30fA2OqaG60c4XemQxRLui3I0=.4380a0a9-cd9a-4dc8-9f85-f7b116a71438@github.com>
Message-ID: <4h9GD_kv2rKug8C0_ROC9h_wqYFovarsMSIbWcZ83TQ=.e5d6c8de-cbbd-4290-9d9e-0673ced0e328@github.com>

On Wed, 19 Apr 2023 10:38:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After the latest harfbuzz update, the AIX build is broken.  The old clang compiler from xlc16 does not compile harfbuzz correctly.
> First issue in hb-algs.hh is that xlc16 clang still sets some GNUC-related macros, so we do not run into the  `__clang_major__ >= 8`  check that should prevent to try to compile  `__builtin_mul_overflow`   with ancient clang.
> The other issue in  `hb-subset.cc`  is a bit tricky and has been observed as well on macOS when very old clang versions were used.
> 
> Probably we can get rid of those 2 workarounds in some months after switching to xlc17 which includes a rather new clang version.

This pull request has now been integrated.

Changeset: 310aa934
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/310aa9347861922af5f0311e9e93a5f49dee6adc
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8304291: [AIX] Broken build after JDK-8301998

Reviewed-by: mdoerr, tsteele, prr

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

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


From duke at openjdk.org  Thu Apr 20 07:20:59 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Thu, 20 Apr 2023 07:20:59 GMT
Subject: RFR: 8305427: Write a test Check whether focus changes as expected
 when requestFocus is used to traverse randomly around the window [v2]
In-Reply-To: <D3Q2PIEfukIUlQqne0LLTKXxq5gdHSD6z7zTzfFWysg=.f6bee040-4f91-4dba-88a4-23890728a123@github.com>
References: <KXVuclBqT0N1Gsgxuw0mR_v6LJqTDmltZNNcitdob4s=.23734422-c3d4-4804-b9cb-d8e9050d1908@github.com>
 <qpJwWXyowmEtHkHAwqickzOMHMfukv5tGNG9RCSmQ_w=.3ee926e6-6964-4ad1-9bd9-dd3494775bf2@github.com>
 <D3Q2PIEfukIUlQqne0LLTKXxq5gdHSD6z7zTzfFWysg=.f6bee040-4f91-4dba-88a4-23890728a123@github.com>
Message-ID: <cl99VnQ2gSw3izX3kMF2_28Jlejc2v4NUIJ7Sw1nSJQ=.46504753-b02e-46ab-859c-8372e44da247@github.com>

On Fri, 7 Apr 2023 22:39:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8305427: code formatting
>
> test/jdk/java/awt/Focus/RequestFocusOwnerTest/RequestFocusOwnerTest.java line 144:
> 
>> 142:             robot.waitForIdle();
>> 143: 
>> 144:             if (!requestStatus) {
> 
> According to the requestFocusInWindow() documentation https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/java/awt/Component.html#requestFocusInWindow() . Developers must never assume that this Component is the focus owner until this Component receives a FOCUS_GAINED event.   
> 
> So dn't depend on requestFocusInWindow()  return value

Modified the test to wait until the FOCUS_GAINED event over for the components i am expecting for focus to be gained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13293#discussion_r1172177723


From duke at openjdk.org  Thu Apr 20 08:48:51 2023
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 20 Apr 2023 08:48:51 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
Message-ID: <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>

> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
> 
> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
> 
> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.

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

  Update documentation for adressing comment on pull requests, with two changes to be discussed:
  
  - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
  - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13506/files
  - new: https://git.openjdk.org/jdk/pull/13506/files/2bb3a5ce..0f339543

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

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

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


From aturbanov at openjdk.org  Thu Apr 20 08:49:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 20 Apr 2023 08:49:56 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
Message-ID: <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>

On Wed, 19 Apr 2023 22:05:33 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Set.of() to initialize IGNORABLE_INTERFACES set.

src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 46:

> 44: final class MethodInfo {
> 45: 
> 46:     static final Set<Class<?>> IGNORABLE_INTERFACES = Set.of(

Hm. Why only this specific interfaces?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1172278787


From duke at openjdk.org  Thu Apr 20 09:11:45 2023
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 20 Apr 2023 09:11:45 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <OCtVGOrNZ3OC_l5VEnLzDDETEj9CYkv5WSiErfumCfQ=.b2ac189b-4add-4d8f-b18d-8fd5e0aa3dfe@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <OCtVGOrNZ3OC_l5VEnLzDDETEj9CYkv5WSiErfumCfQ=.b2ac189b-4add-4d8f-b18d-8fd5e0aa3dfe@github.com>
Message-ID: <u2lAnHz5wk8d4Vp3VMfRM0_5ESf24TV7qA9AdwyzR2g=.20601055-bb52-489c-bcf1-2362c941ed53@github.com>

On Wed, 19 Apr 2023 17:15:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update documentation for adressing comment on pull requests, with two changes to be discussed:
>>   
>>   - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
>>   - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.
>
> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1596:
> 
>> 1594:      * point with (0,0) coordinates since {@code BufferedImage}
>> 1595:      * {@linkplain #getRaster() single tile} is always checked out
>> 1596:      * for writing.
> 
> I think there's some missing punctuation there.
> 
> I'd like to slip in some  additional explanation that (0,0) is always going to be the offset because what else can it be if you only have one tile ?
> The text about "default implementation" in these updated docs might be misinterpreted as there's an alternative implementation .. I don't think there can be .. not in any compatible way.
> All these methods should have been made final. Sadly its too late for that but we need to be clear that this is what you can rely on for a BufferedImage and any subclass that changes it is breaking the contract.
> 
> How about -
> Since a {@code BufferedImage} consists of a single tile, and that tile is always checked out for writing,
> this method, will always return an array of one point.
> Further, in  any case of an image with a single tile, the offset will always be (0,0), that will always be the coordinates of the single returned {@code Point}.

I pushed a new commit which tries to address those comments. The _"default implementation"_ texts have not yet been removed, pending discussion about whether the following scenario is acceptable: A library creates a private `BufferedImage` subclass with `TileObserver` support added. That library returns instances of that subclass only through public methods having `WritableRenderedImage` return type, never exposing the `BufferedImage` type directly. It seems to me that no contract would be broken as long as the user does not cast to `BufferedImage`.

Of course we can not prevent the user to cast to `BufferedImage`, but this issue already exists elsewhere in the library. For example all `Raster.createRaster(?)` static methods may return an instance of `WritableRaster`, when they decided to return a subclass such as `sun.awt.image.ByteInterleavedRaster` optimized for a specific sample model. So we can not have a truly read-only `Raster` through the standard Java API. We already have to tell users _"Don't try to get write access by casting"_.

Regarding tile indices, in the general `RenderedImage` case they do not necessarily start at (0,0). They start at the values given by `getMinTileX()` and `getMinTileY()`. In the particular case of `BufferedImage`, the Javadoc of those two methods said _"This is always zero."_. So the text saying that the offset will always be (0,0) is an indirect constraint. I tried to explain that in the text.

I will create a third commit if the preference is still to remove the _"default implementation"_ text or for other changes.

Regarding the CRS, I do not have the power to create one on https://bugs.openjdk.org/.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1172303229


From aivanov at openjdk.org  Thu Apr 20 11:14:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Apr 2023 11:14:10 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
Message-ID: <ExqM39un8nSJeTlvVmldK3xq5cWwkUBth57kSy_NOJA=.58637cec-9898-4156-83d7-ce59697f0014@github.com>

On Wed, 19 Apr 2023 22:05:33 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Set.of() to initialize IGNORABLE_INTERFACES set.

src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 112:

> 110:                     if ((method.getModifiers() & Modifier.ABSTRACT) == 0)
> 111:                         (list = createIfNeeded(list)).add(method);
> 112:                 }

Please always use braces even if the body has only one statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1172437134


From duke at openjdk.org  Thu Apr 20 13:51:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 20 Apr 2023 13:51:20 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v3]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <wM0xp_phAFifAGglKKCCrRf9tLwSZ84ocjIizOYk2cQ=.7ee57be4-5323-44f3-8125-ef0d1fcd6ff8@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Put braces around single-line "if" statement clauses.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/e37a1467..0326aa13

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

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

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


From duke at openjdk.org  Thu Apr 20 13:51:21 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 20 Apr 2023 13:51:21 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>
Message-ID: <C5q2Z_gyny_b15Sb11aPfnKiQk3-7GHrsJlqINKxk0k=.6d491557-5d90-4122-9b6f-d1afdda06165@github.com>

On Thu, 20 Apr 2023 08:47:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Set.of() to initialize IGNORABLE_INTERFACES set.
>
> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 46:
> 
>> 44: final class MethodInfo {
>> 45: 
>> 46:     static final Set<Class<?>> IGNORABLE_INTERFACES = Set.of(
> 
> Hm. Why only this specific interfaces?

This a list of commonly implemented interfaces that don't need to be inspected because they are "known empty". This list is inspired by [Spring's ClassUtils](https://github.com/spring-projects/spring-framework/blob/ea83d66fb5ac7e8358015f6ad938607a96ae1b41/spring-core/src/main/java/org/springframework/util/ClassUtils.java#L820-L831). Happy to add any others that deserve to be in there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1172620583


From duke at openjdk.org  Thu Apr 20 13:51:21 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 20 Apr 2023 13:51:21 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <ExqM39un8nSJeTlvVmldK3xq5cWwkUBth57kSy_NOJA=.58637cec-9898-4156-83d7-ce59697f0014@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <ExqM39un8nSJeTlvVmldK3xq5cWwkUBth57kSy_NOJA=.58637cec-9898-4156-83d7-ce59697f0014@github.com>
Message-ID: <CaXhkViBoMxRXJLK_rnW_bpWpSyujb-x7IWHrrKSR2g=.946774cb-abcb-42ed-af14-35bc872ddb67@github.com>

On Thu, 20 Apr 2023 11:11:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Set.of() to initialize IGNORABLE_INTERFACES set.
>
> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 112:
> 
>> 110:                     if ((method.getModifiers() & Modifier.ABSTRACT) == 0)
>> 111:                         (list = createIfNeeded(list)).add(method);
>> 112:                 }
> 
> Please always use braces even if the body has only one statement.

OK, I'll fix. I've seen examples of both styles in the JDK so am never really sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1172620735


From duke at openjdk.org  Thu Apr 20 14:22:47 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 20 Apr 2023 14:22:47 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Verify static method is not mistakenly identified as property getter.
 - Use Modifier.isAbstract() convenience method instead of bit masking test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/0326aa13..106edcd6

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

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544

PR: https://git.openjdk.org/jdk/pull/13544


From jdv at openjdk.org  Thu Apr 20 16:35:02 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 20 Apr 2023 16:35:02 GMT
Subject: RFR: 8306430: Open source some AWT tests related to TextComponent and
 Toolkit
Message-ID: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>

This PR open sources few AWT tests related to TextComponent and Toolkit.

-------------

Commit messages:
 - 8306430: Open source some AWT tests related to TextComponent and Toolkit

Changes: https://git.openjdk.org/jdk/pull/13561/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13561&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306430
  Stats: 563 lines in 5 files changed: 563 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13561/head:pull/13561

PR: https://git.openjdk.org/jdk/pull/13561


From serb at openjdk.org  Thu Apr 20 16:54:44 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Apr 2023 16:54:44 GMT
Subject: RFR: 8306430: Open source some AWT tests related to TextComponent
 and Toolkit
In-Reply-To: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
References: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
Message-ID: <gT_60UkApeuv90RJ_b_0H5sCAfOtncwydd8N50fpdTY=.b1e7a9ef-3f33-4f1c-9fb0-0ea3d70d5674@github.com>

On Thu, 20 Apr 2023 16:26:02 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources few AWT tests related to TextComponent and Toolkit.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13561#pullrequestreview-1394409863


From psadhukhan at openjdk.org  Thu Apr 20 17:05:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Apr 2023 17:05:47 GMT
Subject: RFR: 8306430: Open source some AWT tests related to TextComponent
 and Toolkit
In-Reply-To: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
References: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
Message-ID: <d3rQc9lq0rjfqzmYxbPY25I7Tq_8aA1vh21zsfsn7NY=.bb2314bf-5a6c-4a4e-b5d0-ba67e37d2bcb@github.com>

On Thu, 20 Apr 2023 16:26:02 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources few AWT tests related to TextComponent and Toolkit.

test/jdk/java/awt/TextComponent/SelectionBounds/SelectionBounds.java line 106:

> 104: 
> 105:         System.out.println("\nAll tests PASSED.");
> 106:         System.out.println("\nAll tests PASSED.");

duplicate println still not removed...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13561#discussion_r1172872665


From honkar at openjdk.org  Thu Apr 20 17:32:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Apr 2023 17:32:51 GMT
Subject: RFR: JDK-8305874: Open source AWT Key, Text Event related tests
Message-ID: <qBV4A7SSMTWXCNUNp8mMTGCa3oSiJvZiBfIy9O64Lqo=.cd5d1bea-05b3-4e12-8a2a-ccd600da59f4@github.com>

This PR open sources few AWT Key, Text event related tests.

-------------

Commit messages:
 - EOF new line added
 - AWT Events tests

Changes: https://git.openjdk.org/jdk/pull/13563/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305874
  Stats: 547 lines in 5 files changed: 547 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13563/head:pull/13563

PR: https://git.openjdk.org/jdk/pull/13563


From azvegint at openjdk.org  Thu Apr 20 17:59:41 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Apr 2023 17:59:41 GMT
Subject: RFR: JDK-8305874: Open source AWT Key, Text Event related tests
In-Reply-To: <qBV4A7SSMTWXCNUNp8mMTGCa3oSiJvZiBfIy9O64Lqo=.cd5d1bea-05b3-4e12-8a2a-ccd600da59f4@github.com>
References: <qBV4A7SSMTWXCNUNp8mMTGCa3oSiJvZiBfIy9O64Lqo=.cd5d1bea-05b3-4e12-8a2a-ccd600da59f4@github.com>
Message-ID: <ejB6WpiZsFcu2hTam3odkqttckidtIyUAItQOa9kQvY=.f4261569-5141-42b4-8271-a2b9c8a31989@github.com>

On Thu, 20 Apr 2023 17:25:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This PR open sources few AWT Key, Text event related tests.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13563#pullrequestreview-1394507663


From honkar at openjdk.org  Thu Apr 20 18:37:58 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Apr 2023 18:37:58 GMT
Subject: Integrated: JDK-8305874: Open source AWT Key, Text Event related tests
In-Reply-To: <qBV4A7SSMTWXCNUNp8mMTGCa3oSiJvZiBfIy9O64Lqo=.cd5d1bea-05b3-4e12-8a2a-ccd600da59f4@github.com>
References: <qBV4A7SSMTWXCNUNp8mMTGCa3oSiJvZiBfIy9O64Lqo=.cd5d1bea-05b3-4e12-8a2a-ccd600da59f4@github.com>
Message-ID: <vcU3ZX9Xb3XReHha7pM8fJJ_LvfvT2G2yCn490pD0cw=.10f6c6fe-5f46-40c0-ad34-7d3ca047b11b@github.com>

On Thu, 20 Apr 2023 17:25:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This PR open sources few AWT Key, Text event related tests.

This pull request has now been integrated.

Changeset: d6cf4aa1
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6cf4aa1551df591c7bc75cb8c5e90d57630ca2a
Stats:     547 lines in 5 files changed: 547 ins; 0 del; 0 mod

8305874: Open source AWT Key, Text Event related tests

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/13563


From aivanov at openjdk.org  Thu Apr 20 19:15:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Apr 2023 19:15:49 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v8]
In-Reply-To: <g1M3jWZJtAPjUYjRyht9dmD6lWSfuG63cUPkn-FF61s=.586bb168-242d-4ee7-971f-b535b3cf971f@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <g1M3jWZJtAPjUYjRyht9dmD6lWSfuG63cUPkn-FF61s=.586bb168-242d-4ee7-971f-b535b3cf971f@github.com>
Message-ID: <sbOokrjDZCUc1PYWfB2SAhG-Claw1WZGbqwvdAb8aHY=.17f4569f-20fc-40d6-b2df-d3c912c123ea@github.com>

On Wed, 19 Apr 2023 20:26:54 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 98:

> 96:         sys.setContents(new MyTransferable(img), null);
> 97: 
> 98:     }

Suggestion:

    private void copyImage() {
        Clipboard sys = Toolkit.getDefaultToolkit().getSystemClipboard();
        sys.setContents(new MyTransferable(img), null);
    }

Let's remove unnecessary blank line.

test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 132:

> 130:         }
> 131:     }
> 132:     private static class MyTransferable implements Transferable {

Suggestion:

    }

    private static class MyTransferable implements Transferable {

A blank line between class declarations.

test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 161:

> 159: 
> 160: }
> 161: 

Suggestion:

}

Now there are two blank lines in the end of the file for some reason. The thing is, GitHub and `git diff` don't usually show the blank line in the end of the file.

It's not too important, however, it may create noise when someone else updates the file and IDE removes the extra blank lines or adds ones if it's missing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1394606699
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1172987332
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1172987735
PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1172990156


From prr at openjdk.org  Thu Apr 20 19:18:42 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Apr 2023 19:18:42 GMT
Subject: RFR: 8306060: Open source few AWT Insets related tests
In-Reply-To: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
References: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
Message-ID: <6IpbXxPCuOYt5qvhogTeFoR4sCXG5LdKGrP2pCZ_-NA=.635e5823-7f04-4f31-8bfc-51244271b2ca@github.com>

On Thu, 20 Apr 2023 02:49:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This PR opensources few AWT Insets tests

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13552#pullrequestreview-1394614744


From prr at openjdk.org  Thu Apr 20 19:19:44 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Apr 2023 19:19:44 GMT
Subject: RFR: 8305942: Open source several AWT Focus related tests [v2]
In-Reply-To: <cRnA2JJowrm8k-T6DrskIpgqFdK5Imq0_7Qxgtgx28Y=.bc94f110-8b36-41a1-81e2-993a4c740914@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
 <cRnA2JJowrm8k-T6DrskIpgqFdK5Imq0_7Qxgtgx28Y=.bc94f110-8b36-41a1-81e2-993a4c740914@github.com>
Message-ID: <PYmqgaiN2jsFOGVhCYUVM3TpAy_TfK2JnM3VKvzA2g4=.01d6822c-9336-4753-9d72-18361628b275@github.com>

On Thu, 20 Apr 2023 03:53:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This opensources several other AWT Focus related tests.
>> CI runs are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove start comment
>  - Made test to run on all headful platforms

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13527#pullrequestreview-1394616470


From rmahajan at openjdk.org  Thu Apr 20 19:21:56 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 20 Apr 2023 19:21:56 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v9]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <7wRwVPS8YuImW1XNO1M_qbn0dhe-H4XRjRCiyRtm3j8=.d1a220ca-c465-4f51-bf39-f3bf8b18e028@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/a2302d49..c8854330

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=07-08

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414

PR: https://git.openjdk.org/jdk/pull/13414


From rmahajan at openjdk.org  Thu Apr 20 19:26:52 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 20 Apr 2023 19:26:52 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v10]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <WGduTXodBNvaUdJJI1Ba-y9nK_oaa6E9SYqr9PtcnUo=.6841c81b-347e-4702-bb44-5a0fe46d62d3@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  Update CopyAnimatedGIFTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/c8854330..79874ada

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414

PR: https://git.openjdk.org/jdk/pull/13414


From prr at openjdk.org  Thu Apr 20 19:32:44 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Apr 2023 19:32:44 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
Message-ID: <Zu6pyC1lkcLPT1zyfLg_nON56iEDyZmuaV6VMyDLXxs=.d967f352-8d36-4d65-bb6f-5376c5204d7f@github.com>

On Thu, 20 Apr 2023 14:22:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.

The fix overall looks fine, but I'm not seeing why you think it needs a CSR.
It is just a bug fix. And if there were a CSR, it would be about the visible change, not the internals.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1394632684


From prr at openjdk.org  Thu Apr 20 19:32:44 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Apr 2023 19:32:44 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <C5q2Z_gyny_b15Sb11aPfnKiQk3-7GHrsJlqINKxk0k=.6d491557-5d90-4122-9b6f-d1afdda06165@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>
 <C5q2Z_gyny_b15Sb11aPfnKiQk3-7GHrsJlqINKxk0k=.6d491557-5d90-4122-9b6f-d1afdda06165@github.com>
Message-ID: <LjlhbMg7xOka0r_ZLy1pSXMwI73VB7K2xsDo_FSck6w=.3077a871-7497-4623-8633-0e7261e3010a@github.com>

On Thu, 20 Apr 2023 13:47:19 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 46:
>> 
>>> 44: final class MethodInfo {
>>> 45: 
>>> 46:     static final Set<Class<?>> IGNORABLE_INTERFACES = Set.of(
>> 
>> Hm. Why only this specific interfaces?
>
> This a list of commonly implemented interfaces that don't need to be inspected because they are "known empty". This list is inspired by [Spring's ClassUtils](https://github.com/spring-projects/spring-framework/blob/ea83d66fb5ac7e8358015f6ad938607a96ae1b41/spring-core/src/main/java/org/springframework/util/ClassUtils.java#L820-L831). Happy to add any others that deserve to be in there.

given that serializable is commonly implemented, this may be a worthwhile optimisation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1173005019


From duke at openjdk.org  Thu Apr 20 21:04:46 2023
From: duke at openjdk.org (Jeremy)
Date: Thu, 20 Apr 2023 21:04:46 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v5]
In-Reply-To: <82bWrzRL0XLOt1Wz12EWp3QxbUBggwizbj7qJGn4VDc=.0c0cbe67-6a71-4822-80d6-421365bbf0ce@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <eMqgkT15yM1jasSxmxSzuVKw4AZ4ioleY56Hy7ADYJA=.04102920-f75b-408d-8cb1-fb9b593b8ade@github.com>
 <82bWrzRL0XLOt1Wz12EWp3QxbUBggwizbj7qJGn4VDc=.0c0cbe67-6a71-4822-80d6-421365bbf0ce@github.com>
Message-ID: <-h8hOvMOa6gGvrbNRm7wtbsCciKRuW3klsQn8WvNvzY=.e6908748-4df0-4f04-98cc-58943af20753@github.com>

On Wed, 12 Apr 2023 22:55:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4200096: updating test class header to better describe test
>
> src/java.desktop/share/classes/sun/awt/image/OffScreenImageSource.java line 178:
> 
>> 176:                 }
>> 177:                 theConsumer.setPixels(0, y, width, 1, newcm, scanline, 0,
>> 178:                         width);
> 
> can we revert the white space changes ?

OK, done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1173088254


From duke at openjdk.org  Thu Apr 20 22:24:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 20 Apr 2023 22:24:43 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <Zu6pyC1lkcLPT1zyfLg_nON56iEDyZmuaV6VMyDLXxs=.d967f352-8d36-4d65-bb6f-5376c5204d7f@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
 <Zu6pyC1lkcLPT1zyfLg_nON56iEDyZmuaV6VMyDLXxs=.d967f352-8d36-4d65-bb6f-5376c5204d7f@github.com>
Message-ID: <pax2JYHRsh3fq8qpYzZN8to9TXAHv0W4mwFsVjdADSk=.9ed137be-0356-4423-bf54-49fe4e388a4a@github.com>

On Thu, 20 Apr 2023 19:29:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix overall looks fine, but I'm not seeing why you think it needs a CSR. It is just a bug fix.

I'm not sure if it does or not. According to the [CSR FAQ](https://wiki.openjdk.org/display/csr/CSR+FAQs), _Behavioral compatibility involves operational equivalence; with "the same" inputs, does a program behave "the same way" before and after a change._

I've been dinged before for mere "bug fixes" without a CSR (see for example #10856 which made the compiler behave more closely to the spec and was eventually reverted because of it :) So, just being conservative I guess.

I'd be happy to be wrong. @jddarcy, your opinion?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1517015607


From psadhukhan at openjdk.org  Fri Apr 21 02:45:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Apr 2023 02:45:52 GMT
Subject: Integrated: 8306060: Open source few AWT Insets related tests
In-Reply-To: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
References: <s1ZuRJ_cEm-mfzHJqNvNVdyXftzlh_nAHPa81PeqnAg=.e43c0d54-33e8-49f3-8b39-f0a0dfd3f879@github.com>
Message-ID: <qJ4j6JG-JGW7lsnBxmEH02y8wNQsWIj4HSVz4UCwVo0=.7bf97a05-26ee-4efa-8057-491d4dfd6fb4@github.com>

On Thu, 20 Apr 2023 02:49:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This PR opensources few AWT Insets tests

This pull request has now been integrated.

Changeset: 9a68d1d9
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a68d1d952c308c03c29747794d409831008c144
Stats:     270 lines in 4 files changed: 270 ins; 0 del; 0 mod

8306060: Open source few AWT Insets related tests

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13552


From psadhukhan at openjdk.org  Fri Apr 21 02:54:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Apr 2023 02:54:56 GMT
Subject: Integrated: 8305942: Open source several AWT Focus related tests
In-Reply-To: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
References: <OpRLOAiC-oDtbpE89TT31ik9qXEiCJn5_lCZdsIy9uQ=.dd632e42-c823-4e00-abc0-601292f942ac@github.com>
Message-ID: <cWm8I9-bh7wmvSlZZVt7Ulso1eO9pH08dxmDUYiVSYw=.99d3bb84-540a-46db-aa21-7313dd72ad83@github.com>

On Wed, 19 Apr 2023 09:16:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources several other AWT Focus related tests.
> CI runs are ok.

This pull request has now been integrated.

Changeset: 8346ae2b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8346ae2bc1152f13bc77c643252d84e2043ffe0b
Stats:     831 lines in 6 files changed: 831 ins; 0 del; 0 mod

8305942: Open source several AWT Focus related tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13527


From psadhukhan at openjdk.org  Fri Apr 21 04:07:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Apr 2023 04:07:57 GMT
Subject: RFR: 8306067: Open source AWT Graphics,GridBagLayout related tests
Message-ID: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>

This opensources few AWT Graphics & GridBagLayout tests

-------------

Commit messages:
 - 8306067: Open source AWT Graphics,GridBagLayout related tests

Changes: https://git.openjdk.org/jdk/pull/13570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306067
  Stats: 302 lines in 4 files changed: 302 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13570/head:pull/13570

PR: https://git.openjdk.org/jdk/pull/13570


From psadhukhan at openjdk.org  Fri Apr 21 05:07:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Apr 2023 05:07:05 GMT
Subject: RFR: 8306076: Open source AWT misc tests
Message-ID: <zpcEXSJPslUcCSjR5xUA-_852bQC2uqZ3nj7SpUSN7E=.85257550-3689-432a-91cb-697e794cb241@github.com>

This opensources few AWT tests

-------------

Commit messages:
 - 8306076: Open source AWT misc tests

Changes: https://git.openjdk.org/jdk/pull/13572/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306076
  Stats: 169 lines in 3 files changed: 169 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13572/head:pull/13572

PR: https://git.openjdk.org/jdk/pull/13572


From tr at openjdk.org  Fri Apr 21 05:26:59 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 21 Apr 2023 05:26:59 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests
Message-ID: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>

This open source AWT Mouse Info related tests.

-------------

Commit messages:
 - Moved test from closed

Changes: https://git.openjdk.org/jdk/pull/13573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306072
  Stats: 182 lines in 2 files changed: 182 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From darcy at openjdk.org  Fri Apr 21 05:27:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 21 Apr 2023 05:27:45 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <pax2JYHRsh3fq8qpYzZN8to9TXAHv0W4mwFsVjdADSk=.9ed137be-0356-4423-bf54-49fe4e388a4a@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
 <Zu6pyC1lkcLPT1zyfLg_nON56iEDyZmuaV6VMyDLXxs=.d967f352-8d36-4d65-bb6f-5376c5204d7f@github.com>
 <pax2JYHRsh3fq8qpYzZN8to9TXAHv0W4mwFsVjdADSk=.9ed137be-0356-4423-bf54-49fe4e388a4a@github.com>
Message-ID: <dhpHx3dqDMuP1cCmpVDGU1VwLnocCveZftfd5JifM_A=.33b7a770-f497-4230-b956-969c28f6133f@github.com>

On Thu, 20 Apr 2023 22:21:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> > The fix overall looks fine, but I'm not seeing why you think it needs a CSR. It is just a bug fix.
> 
> I'm not sure if it does or not. According to the [CSR FAQ](https://wiki.openjdk.org/display/csr/CSR+FAQs), _Behavioral compatibility involves operational equivalence; with "the same" inputs, does a program behave "the same way" before and after a change._
> 
> I've been dinged before for mere "bug fixes" without a CSR (see for example #10856 which made the compiler behave more closely to the spec and was eventually reverted because of it :) So, just being conservative I guess.
> 
> I'd be happy to be wrong. @jddarcy, your opinion?

Hmmm. I'm not an expert on Introspectors, but my impression is the behavior change is CSR-worthy. HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1517278847


From jdv at openjdk.org  Fri Apr 21 05:32:45 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 21 Apr 2023 05:32:45 GMT
Subject: RFR: 8306430: Open source some AWT tests related to TextComponent
 and Toolkit [v2]
In-Reply-To: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
References: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
Message-ID: <xlK4NJnA9zd48klT1un90JF8RThPo7VgAk3YNlFshoM=.485ae6ca-789c-47f1-b2eb-b6c1c3c0e940@github.com>

> This PR open sources few AWT tests related to TextComponent and Toolkit.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra println

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13561/files
  - new: https://git.openjdk.org/jdk/pull/13561/files/ae9bada3..bf221afc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13561&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13561&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13561/head:pull/13561

PR: https://git.openjdk.org/jdk/pull/13561


From jdv at openjdk.org  Fri Apr 21 05:32:47 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 21 Apr 2023 05:32:47 GMT
Subject: RFR: 8306430: Open source some AWT tests related to TextComponent
 and Toolkit [v2]
In-Reply-To: <d3rQc9lq0rjfqzmYxbPY25I7Tq_8aA1vh21zsfsn7NY=.bb2314bf-5a6c-4a4e-b5d0-ba67e37d2bcb@github.com>
References: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
 <d3rQc9lq0rjfqzmYxbPY25I7Tq_8aA1vh21zsfsn7NY=.bb2314bf-5a6c-4a4e-b5d0-ba67e37d2bcb@github.com>
Message-ID: <dNwfVDIEAqcF3AyDp3mMP89MZ4kkqEEzK6iGOCAwAX8=.3ce4ebd1-f141-480c-bd70-8b56b8b5f563@github.com>

On Thu, 20 Apr 2023 17:02:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra println
>
> test/jdk/java/awt/TextComponent/SelectionBounds/SelectionBounds.java line 106:
> 
>> 104: 
>> 105:         System.out.println("\nAll tests PASSED.");
>> 106:         System.out.println("\nAll tests PASSED.");
> 
> duplicate println still not removed...

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13561#discussion_r1173316325


From jdv at openjdk.org  Fri Apr 21 05:41:53 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 21 Apr 2023 05:41:53 GMT
Subject: Integrated: 8306430: Open source some AWT tests related to
 TextComponent and Toolkit
In-Reply-To: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
References: <CdzxEMWumhESvhlaeSgijqQRJIqSDnL7omZmGk8EQ6A=.68f30df4-e952-48b4-a8ea-44a1027bc35b@github.com>
Message-ID: <C3MP4zY8CF4Lj0b3VNz1IBvW7fIdg7yY1PYKSjjqR2c=.85af53c9-bf2c-40e5-886e-fc4e4ac3bbcd@github.com>

On Thu, 20 Apr 2023 16:26:02 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources few AWT tests related to TextComponent and Toolkit.

This pull request has now been integrated.

Changeset: 36ec05d5
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36ec05d52a79185d8c6669713fd17933128c032a
Stats:     562 lines in 5 files changed: 562 ins; 0 del; 0 mod

8306430: Open source some AWT tests related to TextComponent and Toolkit

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13561


From aturbanov at openjdk.org  Fri Apr 21 10:48:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 21 Apr 2023 10:48:41 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <LjlhbMg7xOka0r_ZLy1pSXMwI73VB7K2xsDo_FSck6w=.3077a871-7497-4623-8633-0e7261e3010a@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>
 <C5q2Z_gyny_b15Sb11aPfnKiQk3-7GHrsJlqINKxk0k=.6d491557-5d90-4122-9b6f-d1afdda06165@github.com>
 <LjlhbMg7xOka0r_ZLy1pSXMwI73VB7K2xsDo_FSck6w=.3077a871-7497-4623-8633-0e7261e3010a@github.com>
Message-ID: <ANO11R0PRvEY2sgRuS5fDMm12Y9qCe0wRfB3qa4vqKs=.95f7bb6e-aabb-41e2-83c7-1b85ccd3489c@github.com>

On Thu, 20 Apr 2023 19:28:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> This a list of commonly implemented interfaces that don't need to be inspected because they are "known empty". This list is inspired by [Spring's ClassUtils](https://github.com/spring-projects/spring-framework/blob/ea83d66fb5ac7e8358015f6ad938607a96ae1b41/spring-core/src/main/java/org/springframework/util/ClassUtils.java#L820-L831). Happy to add any others that deserve to be in there.
>
> given that serializable is commonly implemented, this may be a worthwhile optimisation.

I think it should have some explanation comment, about why this interfaces are ignored and how they were chosen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1173624812


From duke at openjdk.org  Fri Apr 21 13:34:49 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 21 Apr 2023 13:34:49 GMT
Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java
Message-ID: <nCx3TBowXgr6A2NqaNaOSzq8tHwd6CwgkxPZ_CPIf68=.71605e80-c2ee-43e1-9bf7-bf386ff6a64e@github.com>

Hi Reviewers,
Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox).

 Evaluating conditions:
1. Not enough space for showing popup downwards(default layout), it should show upwards
2. Window starts from negative position, Popup should show on visible area

For achieving this following areas are modified
- Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified)
- Menu creation made as function and reused for all menu creation.
- Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener.
- This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out.
- Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings.

Please review this

Regards,
Renjith.

-------------

Commit messages:
 - Removed executable mode
 - JDK-8289547 : Update javax/swing/Popup/TaskbarPositionTest.java

Changes: https://git.openjdk.org/jdk/pull/13578/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289547
  Stats: 244 lines in 1 file changed: 130 ins; 54 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/13578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13578/head:pull/13578

PR: https://git.openjdk.org/jdk/pull/13578


From dcherepanov at openjdk.org  Fri Apr 21 15:09:43 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 21 Apr 2023 15:09:43 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <-6wNY5cssf-oazwqnicJ7ilYAzMt5sf98J3vPlar6w0=.da416751-19b1-41c2-ae85-58951f6c23b9@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
 <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>
 <-6wNY5cssf-oazwqnicJ7ilYAzMt5sf98J3vPlar6w0=.da416751-19b1-41c2-ae85-58951f6c23b9@github.com>
Message-ID: <54yIiMsqXFck3QsWJlSJ67j2VSW8X2xQisnO2xiLq9g=.57c8cddc-8550-4f28-a928-7f0283fc8cbb@github.com>

On Tue, 11 Apr 2023 00:12:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But it will be ignored if the window is invisible.

If we show/hide a window and then change DPI settings, then notifications will be ignored. But as soon as we show the window next time, we'll get new updateGC notification artifically initiated from WWindowPeer.show (https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#L287). Later, when the window will be displayed on the screen, it will have the updated icon without delay.

It's a low-risk change that fixes the regression and keeps the original scenario working. It looks safe to backport to JDK 20 update.

> It is better to fix the https://bugs.openjdk.org/browse/JDK-6995195

Created new PR for this issue: https://github.com/openjdk/jdk/pull/13459

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1517975533


From aivanov at openjdk.org  Fri Apr 21 16:38:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 16:38:48 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <t6lHcPlxKtHFjbR0d9V82b6CpAfsd4UWAiuW7wHWprQ=.962e58e9-2fb1-4b71-a739-0039cf1a0705@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <t6lHcPlxKtHFjbR0d9V82b6CpAfsd4UWAiuW7wHWprQ=.962e58e9-2fb1-4b71-a739-0039cf1a0705@github.com>
Message-ID: <9CshDXqxT48B9AIyWqSmDaYPJ6UjNCUtg1HRsL7ixKI=.0037f3bd-098c-4ac3-8bd1-5f5c22c78cb6@github.com>

On Fri, 31 Mar 2023 18:29:01 GMT, Phil Race <prr at openjdk.org> wrote:

> Even for AWT (non-swing) apps, it is recommended to do it on the EDT to avoid threading issues - such as this. Lots of apps do use the main thread, and have no issues but that's not guaranteed.
> 
> I can't find where this is documented .. I do remember it was quite a number of years ago that this advice was first offered.

I tried to find any documentation stating the threading model for AWT components but I didn't find any. I presume AWT should be thread-safe. A couple of times on code review I saw it had been proposed to drop `EventQueue.invokeLater` because creating and changing AWT components from main thread is _safe_.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1518078254


From aivanov at openjdk.org  Fri Apr 21 16:50:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 16:50:48 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <54yIiMsqXFck3QsWJlSJ67j2VSW8X2xQisnO2xiLq9g=.57c8cddc-8550-4f28-a928-7f0283fc8cbb@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
 <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>
 <-6wNY5cssf-oazwqnicJ7ilYAzMt5sf98J3vPlar6w0=.da416751-19b1-41c2-ae85-58951f6c23b9@github.com>
 <54yIiMsqXFck3QsWJlSJ67j2VSW8X2xQisnO2xiLq9g=.57c8cddc-8550-4f28-a928-7f0283fc8cbb@github.com>
Message-ID: <T-fM4z_n-eb1AocP9rQEvTAMfgu4wsw0h7YgzRZLVHI=.bf3cb7a7-cc8f-4de9-8adc-40c7ddafe8fe@github.com>

On Fri, 21 Apr 2023 15:07:17 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> > But it will be ignored if the window is invisible.
> 
> If we show/hide a window and then change DPI settings, then notifications will be ignored. But as soon as we show the window next time, we'll get new updateGC notification artifically initiated from WWindowPeer.show (https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#L287). Later, when the window will be displayed on the screen, it will have the updated icon without delay.
> 
> It's a low-risk change that fixes the regression and keeps the original scenario working. It looks safe to backport to JDK 20 update.

If the window is not visible, `updateGC` gets called when the window is shown; if the window is already visible, nothing changes. Thus, the icon will be updated in all the cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1518091534


From prr at openjdk.org  Fri Apr 21 16:57:49 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 16:57:49 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in
 the Little-CMS 2.13 [v2]
In-Reply-To: <WwVDDzOehZz7VE4ARo7gsMhbmrLoBrxrCZB2_trcG-k=.80ee0868-6311-46c9-9df2-eb41fcbfee6a@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
 <WwVDDzOehZz7VE4ARo7gsMhbmrLoBrxrCZB2_trcG-k=.80ee0868-6311-46c9-9df2-eb41fcbfee6a@github.com>
Message-ID: <Aagdw0T4Kgij__nUddU56JzBqTXtZhRPm3XQBtuZbW4=.1de45ae2-fc8e-4df1-963e-ff52eeb32535@github.com>

On Thu, 13 Apr 2023 21:24:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
>> 
>> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
>> 
>> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
>> 
>> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
>> 
>> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
>> 
>> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
>> | ------------- | ------------- | ------------- |------------- |
>> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
>> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
>> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
>> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
>> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
>> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SkipSampleModel

re-ran all tests including your new one. This time everything definitely passes.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13095#pullrequestreview-1396111348


From aivanov at openjdk.org  Fri Apr 21 16:59:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 16:59:43 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
Message-ID: <d2ImvImc61iIzIt-tEvVlRJ-fSEUlGfRAZQ6OdwiesU=.4f816f76-b828-4bda-8932-31c342a6fc03@github.com>

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13263#pullrequestreview-1396114435


From prr at openjdk.org  Fri Apr 21 17:04:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 17:04:45 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <dhpHx3dqDMuP1cCmpVDGU1VwLnocCveZftfd5JifM_A=.33b7a770-f497-4230-b956-969c28f6133f@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
 <Zu6pyC1lkcLPT1zyfLg_nON56iEDyZmuaV6VMyDLXxs=.d967f352-8d36-4d65-bb6f-5376c5204d7f@github.com>
 <pax2JYHRsh3fq8qpYzZN8to9TXAHv0W4mwFsVjdADSk=.9ed137be-0356-4423-bf54-49fe4e388a4a@github.com>
 <dhpHx3dqDMuP1cCmpVDGU1VwLnocCveZftfd5JifM_A=.33b7a770-f497-4230-b956-969c28f6133f@github.com>
Message-ID: <BZO-Bz92Mkx94VKfG2CxP2DOJoVbePdhBUKCB0QTpaA=.1a2915d2-de62-4f30-98b6-d832291312c7@github.com>

On Fri, 21 Apr 2023 05:24:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > The fix overall looks fine, but I'm not seeing why you think it needs a CSR. It is just a bug fix.
> > 
> > 
> > I'm not sure if it does or not. According to the [CSR FAQ](https://wiki.openjdk.org/display/csr/CSR+FAQs), _Behavioral compatibility involves operational equivalence; with "the same" inputs, does a program behave "the same way" before and after a change._

By that criterion every change needs a CSR.
Gosh, it used to SEGV, now it doesn't - I'd better file a CSR !

> > I've been dinged before for mere "bug fixes" without a CSR (see for example #10856 which made the compiler behave more closely to the spec and was eventually reverted because of it :) So, just being conservative I guess.
> > I'd be happy to be wrong. @jddarcy, your opinion?
> 
> Hmmm. I'm not an expert on Introspectors, but my impression is the behavior change is CSR-worthy. HTH

Maybe but regardless the CSR that has been written is very wrong, as I already commented there.
If you could write something up that sticks to specification or describing behaviour that rises to the level of implied
specification, using words, not code, then we can consider it.

All it needs to say is 
"Previously, the introspector would ignore interfaces, since before default methods were added to the language, there
could be no implementation. Now  interfaces are considered like other classes"

That's it, isn't it ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1518105723


From aivanov at openjdk.org  Fri Apr 21 18:00:47 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 18:00:47 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
Message-ID: <xKVx0qNTkDIhwZ6eaWAhGrxbZnhKAc2YWKcDOmpPeao=.66a79687-7c83-4ae0-9351-e58cc3c985f6@github.com>

On Mon, 17 Apr 2023 08:14:13 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
>> 
>> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.
>
> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed long lines

test/jdk/sun/java2d/loops/GraphicsPrimitiveMgrTest.java line 28:

> 26: import java.util.concurrent.CountDownLatch;
> 27: 
> 28: /**

Suggestion:

/*

It's not a javadoc, so to avoid lots of warnings from IDE because of invalid tags, it's better to use a single asterisk.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1174035954


From aivanov at openjdk.org  Fri Apr 21 18:25:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 18:25:45 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <CaXhkViBoMxRXJLK_rnW_bpWpSyujb-x7IWHrrKSR2g=.946774cb-abcb-42ed-af14-35bc872ddb67@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <ExqM39un8nSJeTlvVmldK3xq5cWwkUBth57kSy_NOJA=.58637cec-9898-4156-83d7-ce59697f0014@github.com>
 <CaXhkViBoMxRXJLK_rnW_bpWpSyujb-x7IWHrrKSR2g=.946774cb-abcb-42ed-af14-35bc872ddb67@github.com>
Message-ID: <xjX4vbpZOKxAbTaevRPzQ69KfMA_V8jNPgm0sgkekyM=.9b90df49-f411-4bed-bfcb-1f362fa2d9c8@github.com>

On Thu, 20 Apr 2023 13:47:25 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 112:
>> 
>>> 110:                     if ((method.getModifiers() & Modifier.ABSTRACT) == 0)
>>> 111:                         (list = createIfNeeded(list)).add(method);
>>> 112:                 }
>> 
>> Please always use braces even if the body has only one statement.
>
> OK, I'll fix. I've seen examples of both styles in the JDK so am never really sure.

In client libs, we tend to use the braces all the time.

By this comment, I meant adding braces to all the statements where you omitted them, including the test.

If you look through `MethodInfo.java` class, you see that braces are used consistently even if the body has only one statement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1174054770


From aivanov at openjdk.org  Fri Apr 21 19:00:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 19:00:50 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
Message-ID: <d4oCmEcQPw-7c6qZTqboNNd0X7UIO3Br-LO20B-__NM=.40284973-cca7-49dc-879b-ab3e88dc5462@github.com>

On Thu, 20 Apr 2023 14:22:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 1:

> 1: /*

Is it expected that the test file doesn't compile with simple `javac DefaultMethodBeanPropertyTest.java`? It complains about `BeanUtils` not found. When run with jtreg, the test compiles successfully.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1174080179


From serb at openjdk.org  Fri Apr 21 19:20:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 19:20:57 GMT
Subject: Integrated: 8279216: Investigate implementation of premultiplied alpha
 in the Little-CMS 2.13
In-Reply-To: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
References: <ch8u3SExLjwa5ttbYszX1Ql3h-xiTqoNsa6qxVTJ5gc=.ff96968b-5631-42ed-8e24-15e00528dfd5@github.com>
Message-ID: <RlXMf7epVO_p3dXVMSKZcXbaDKGsZ8HlkkW8ixh-OlA=.0dc28528-7f42-4cf7-8e4f-b544c5f0fd5a@github.com>

On Mon, 20 Mar 2023 01:07:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.
> 
> The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.
> 
> After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
>  * lcms does not convert pre-alpha for transparent src if dst is opaque
>  * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque
> 
> Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.
> 
> Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.
> 
> | Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
> | ------------- | ------------- | ------------- |------------- |
> | 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
> | 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
> | 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
> | 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
> | 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
> | 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

This pull request has now been integrated.

Changeset: 117c5b11
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/117c5b116b0c4e98ad34b3ddd3af844ed247ea09
Stats:     515 lines in 5 files changed: 485 ins; 7 del; 23 mod

8279216: Investigate implementation of premultiplied alpha in the Little-CMS 2.13

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13095


From abhiscxk at openjdk.org  Fri Apr 21 19:29:58 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Apr 2023 19:29:58 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests
Message-ID: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>

This PR is to open source MenuItem AWT tests.

-------------

Commit messages:
 - Open source MenuItem AWT tests

Changes: https://git.openjdk.org/jdk/pull/13589/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306652
  Stats: 323 lines in 4 files changed: 323 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13589/head:pull/13589

PR: https://git.openjdk.org/jdk/pull/13589


From serb at openjdk.org  Fri Apr 21 20:20:44 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 20:20:44 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v4]
In-Reply-To: <n1aD0-m9lIT6m4zYLM2bS0X7Z6p4I-oFYuXcYreUL3Q=.73f70fe5-2383-43d4-8c25-b40cb5bc0515@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
 <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
 <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>
 <ARN9hx1kDtJk01JkFF9OHtJbVNbUXaL52yujttRttBg=.9e53f587-4825-48d0-aebc-c75e91d68c5b@github.com>
 <n1aD0-m9lIT6m4zYLM2bS0X7Z6p4I-oFYuXcYreUL3Q=.73f70fe5-2383-43d4-8c25-b40cb5bc0515@github.com>
Message-ID: <KzbEb36-WJD-MCL2IR78rGTanfD5MD9NBpu7gqMTxAY=.e4057fe5-7afb-47f1-9927-fdb2f75459b1@github.com>

On Mon, 17 Apr 2023 10:19:37 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>>> II suggest to check how it works on win/mac, does we trigger displayChanged in that case?
>> 
>> I doubt it: see comments in [CGraphicsDevice.getScreenInsets()](https://github.com/openjdk/jdk/blob/2a062f165491d599eb0dcfb6050eb9186ae31b71/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L185)
>> 
>>         // the insets are queried synchronously and are not cached
>>         // since there are no Quartz or Cocoa means to receive notifications
>>         // on insets changes (e.g. when the Dock is resized):
>>         // the existing CGDisplayReconfigurationCallBack is not notified
>>         // as well as the NSApplicationDidChangeScreenParametersNotification
>>         // is fired on the Dock location changes only
>
>> it is better to inject the field to the GC, and update it on demand
> 
> I'm not sure this will look as pretty as in `CGraphicsDevice`. The code to obtain insets is located in `XToolkit` and is not easily moveable; insets are queried from and updated in `XToolkit` also, so by moving insets outside of `XToolkit` we're going to create more cross-package dependencies without really improving anything. Redesigning the entire toolkit so that insets fit more naturally to be a property of `X11GraphicsConfig` (or rather `X11GraphicsDevice` where I think they belong) is a task way beyond the scope of 8305578.

You do not need to move the code around, just cache it in the GC instead of the hashmap, and then re-cache it by some notification.

BTW Are you sure that hashmap does not required some synchronization to update/read?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1174132446


From serb at openjdk.org  Fri Apr 21 20:25:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 20:25:51 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <xKVx0qNTkDIhwZ6eaWAhGrxbZnhKAc2YWKcDOmpPeao=.66a79687-7c83-4ae0-9351-e58cc3c985f6@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
 <xKVx0qNTkDIhwZ6eaWAhGrxbZnhKAc2YWKcDOmpPeao=.66a79687-7c83-4ae0-9351-e58cc3c985f6@github.com>
Message-ID: <UyXegBPKDRMPvVGvbidWQQkJPVGFNo6JdWJLg1ncnhQ=.28a14455-2485-4936-bafa-a0dbb17f66b0@github.com>

On Fri, 21 Apr 2023 17:57:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed long lines
>
> test/jdk/sun/java2d/loops/GraphicsPrimitiveMgrTest.java line 28:
> 
>> 26: import java.util.concurrent.CountDownLatch;
>> 27: 
>> 28: /**
> 
> Suggestion:
> 
> /*
> 
> It's not a javadoc, so to avoid lots of warnings from IDE because of invalid tags, it's better to use a single asterisk.

or probably it is better to save that tags as custom in IDE, so it will actually check that all of them are correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1174135237


From rriggs at openjdk.org  Fri Apr 21 20:26:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 20:26:12 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v17]
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13357/files
  - new: https://git.openjdk.org/jdk/pull/13357/files/b95a312d..accf67f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15-16

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357

PR: https://git.openjdk.org/jdk/pull/13357


From duke at openjdk.org  Fri Apr 21 20:27:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:27:59 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
Message-ID: <zgaq7vOxGw4Yub_wPnnCyDz2F25SElcl75dJ6jNeCUU=.be92f10c-9d14-40b3-84b1-3ec7ec7ea55a@github.com>

On Thu, 20 Apr 2023 14:22:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.

Let's make this CSR question easy. I'll remove the CSR and see if anybody actually complains :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1518296614


From duke at openjdk.org  Fri Apr 21 20:28:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:28:00 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <ANO11R0PRvEY2sgRuS5fDMm12Y9qCe0wRfB3qa4vqKs=.95f7bb6e-aabb-41e2-83c7-1b85ccd3489c@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <o54cemxlRnTTXveYawIK5KJp1MD-KOPZpBPtXSCA6n4=.b8062761-20f1-479a-943a-13d79cd7d884@github.com>
 <C5q2Z_gyny_b15Sb11aPfnKiQk3-7GHrsJlqINKxk0k=.6d491557-5d90-4122-9b6f-d1afdda06165@github.com>
 <LjlhbMg7xOka0r_ZLy1pSXMwI73VB7K2xsDo_FSck6w=.3077a871-7497-4623-8633-0e7261e3010a@github.com>
 <ANO11R0PRvEY2sgRuS5fDMm12Y9qCe0wRfB3qa4vqKs=.95f7bb6e-aabb-41e2-83c7-1b85ccd3489c@github.com>
Message-ID: <-LhYsV9adlLO3jGM7dhhL0jfwragtv3cOpWuBTir6Us=.1bc77559-b118-461c-8702-090b48f9fb87@github.com>

On Fri, 21 Apr 2023 10:45:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> given that serializable is commonly implemented, this may be a worthwhile optimisation.
>
> I think it should have some explanation comment, about why this interfaces are ignored and how they were chosen.

Fixed in ac90a10e238.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1174133613


From duke at openjdk.org  Fri Apr 21 20:27:57 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:27:57 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie L. Cobbs 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:

 - Add comment describing what IGNORABLE_INTERFACES is for.
 - Put braces around single-line "if" statement clauses in test.
 - Merge branch 'master' into JDK-8071693
 - Verify static method is not mistakenly identified as property getter.
 - Use Modifier.isAbstract() convenience method instead of bit masking test.
 - Put braces around single-line "if" statement clauses.
 - Use Set.of() to initialize IGNORABLE_INTERFACES set.
 - Include default methods inherited from interfaces in bean introspection.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/106edcd6..ac90a10e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=03-04

  Stats: 2952 lines in 52 files changed: 2819 ins; 50 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/13544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544

PR: https://git.openjdk.org/jdk/pull/13544


From duke at openjdk.org  Fri Apr 21 20:28:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:28:00 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v2]
In-Reply-To: <xjX4vbpZOKxAbTaevRPzQ69KfMA_V8jNPgm0sgkekyM=.9b90df49-f411-4bed-bfcb-1f362fa2d9c8@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <Uywy4jX9cEwxXi11ux1IF0MxCQhI_Vniob1wPU2-zH0=.4a6c6584-8466-44aa-b4f5-199f63e2ebc1@github.com>
 <ExqM39un8nSJeTlvVmldK3xq5cWwkUBth57kSy_NOJA=.58637cec-9898-4156-83d7-ce59697f0014@github.com>
 <CaXhkViBoMxRXJLK_rnW_bpWpSyujb-x7IWHrrKSR2g=.946774cb-abcb-42ed-af14-35bc872ddb67@github.com>
 <xjX4vbpZOKxAbTaevRPzQ69KfMA_V8jNPgm0sgkekyM=.9b90df49-f411-4bed-bfcb-1f362fa2d9c8@github.com>
Message-ID: <HuCuR9aNOSCeNqEA9i1YUOnl7_2F8UkYty4PF8L-qDQ=.ca1f638f-707c-434d-a653-b435ac1edafd@github.com>

On Fri, 21 Apr 2023 18:23:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> OK, I'll fix. I've seen examples of both styles in the JDK so am never really sure.
>
> In client libs, we tend to use the braces all the time.
> 
> By this comment, I meant adding braces to all the statements where you omitted them, including the test.
> 
> If you look through `MethodInfo.java` class, you see that braces are used consistently even if the body has only one statement.

Fixed in ac90a10e238.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1174133590


From duke at openjdk.org  Fri Apr 21 20:28:03 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:28:03 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <d4oCmEcQPw-7c6qZTqboNNd0X7UIO3Br-LO20B-__NM=.40284973-cca7-49dc-879b-ab3e88dc5462@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
 <d4oCmEcQPw-7c6qZTqboNNd0X7UIO3Br-LO20B-__NM=.40284973-cca7-49dc-879b-ab3e88dc5462@github.com>
Message-ID: <8zNBxs-FaFXMCFIOsKXyoesVsGlrAqdAEGiRHDBCZ5s=.9c8905ee-7751-46a3-9f5c-e52a4c407cdf@github.com>

On Fri, 21 Apr 2023 18:58:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is it expected that the test file doesn't compile with simple javac DefaultMethodBeanPropertyTest.java?

Definitely not. For example, many regression tests use classes that are not part of the standard JDK such as `toolbox.ToolBox`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1174133504


From aivanov at openjdk.org  Fri Apr 21 20:32:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Apr 2023 20:32:44 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <UyXegBPKDRMPvVGvbidWQQkJPVGFNo6JdWJLg1ncnhQ=.28a14455-2485-4936-bafa-a0dbb17f66b0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
 <xKVx0qNTkDIhwZ6eaWAhGrxbZnhKAc2YWKcDOmpPeao=.66a79687-7c83-4ae0-9351-e58cc3c985f6@github.com>
 <UyXegBPKDRMPvVGvbidWQQkJPVGFNo6JdWJLg1ncnhQ=.28a14455-2485-4936-bafa-a0dbb17f66b0@github.com>
Message-ID: <hx3nFvbQeZNcxgbkenmc3urfdGh4iKUiywMcf-U-oFk=.574989d1-3dd8-4ce1-8e01-bdd50d35c90c@github.com>

On Fri, 21 Apr 2023 20:22:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/sun/java2d/loops/GraphicsPrimitiveMgrTest.java line 28:
>> 
>>> 26: import java.util.concurrent.CountDownLatch;
>>> 27: 
>>> 28: /**
>> 
>> Suggestion:
>> 
>> /*
>> 
>> It's not a javadoc, so to avoid lots of warnings from IDE because of invalid tags, it's better to use a single asterisk.
>
> or probably it is better to save that tags as custom in IDE, so it will actually check that all of them are correct.

Since it's not a javadoc, I don't see much value in it, and IDE won't complain if you accidentally use such a tag in a source file where a regular javadoc comment is expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1174140839


From duke at openjdk.org  Fri Apr 21 20:37:45 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Apr 2023 20:37:45 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v4]
In-Reply-To: <zgaq7vOxGw4Yub_wPnnCyDz2F25SElcl75dJ6jNeCUU=.be92f10c-9d14-40b3-84b1-3ec7ec7ea55a@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <CCu5joWmG7cAfCAU7bJe9Hrlf73IKCO7KVWUd8UW27I=.65794b5b-43ee-4919-82c0-aa1f619184b1@github.com>
 <zgaq7vOxGw4Yub_wPnnCyDz2F25SElcl75dJ6jNeCUU=.be92f10c-9d14-40b3-84b1-3ec7ec7ea55a@github.com>
Message-ID: <AHjSNE8X3mw65zff6OWoHs-9qJjDSyI-ZnNy81tSVP4=.9f4b0f82-7267-4482-b330-996569a098b7@github.com>

On Fri, 21 Apr 2023 20:21:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Let's make this CSR question easy. I'll remove the CSR and see if anybody actually complains :)

Ugh, it looks like the bot won't let me do that. A reviewer will have to remove the CSR....

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1518309633


From javalists at cbfiddle.com  Fri Apr 21 21:06:02 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 21 Apr 2023 14:06:02 -0700
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v10]
In-Reply-To: <WGduTXodBNvaUdJJI1Ba-y9nK_oaa6E9SYqr9PtcnUo=.6841c81b-347e-4702-bb44-5a0fe46d62d3@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <WGduTXodBNvaUdJJI1Ba-y9nK_oaa6E9SYqr9PtcnUo=.6841c81b-347e-4702-bb44-5a0fe46d62d3@github.com>
Message-ID: <A6F13465-62FD-4E01-83F5-91E05C68D3E3@cbfiddle.com>

I was hoping to be able to run your test program, but I cannot because on macOS there is no support for transferring a native image.

It also appears that I cannot simulate the transfer code because that code depends upon the reconstruct method, which is not public.

Just looking at the code, I think it is not correct.

It looks to me that the ImageRepresentation.drawToBufImage method is called only once, and it will do nothing unless ALLBITS or FRAMEBITS is true.
I do not see any loop that would call it multiple times. (If I am correct about this, then only the first frame is drawn into the buffered image, which makes much more sense than drawing every frame into the buffered image. One might ask, however, what a user is trying to accomplish by copying an animated image to the system clipboard?)

So, it works if reconstruct() waits until ALLBITS or FRAMEBITS is true. But your change does not test for FRAMEBITS in the loop, so it will only work if FRAMEBITS is already true when reconstruct() is called.

How can that happen?

I think it works because you are displaying the image on the screen, and the animation code is reading frames.

I suggest trying the test without displaying the image.

Also, your test would better if it retrieved the native image from the system clipboard to verify that it was successfully transferred. You would need to clear the system clipboard before running the test to be sure you are not retrieving something from a previous test run.





> On Apr 20, 2023, at 12:26 PM, Rajat Mahajan <rmahajan at openjdk.org> wrote:
> 
>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
> 
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>  Update CopyAnimatedGIFTest.java
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.org/jdk/pull/13414/files
>  - new: https://git.openjdk.org/jdk/pull/13414/files/c8854330..79874ada
> 
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=09
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=08-09
> 
>  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
>  Patch: https://git.openjdk.org/jdk/pull/13414.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414
> 
> PR: https://git.openjdk.org/jdk/pull/13414
> 



From serb at openjdk.org  Fri Apr 21 21:11:48 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:11:48 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <-ax6p6tWRHpenDT9y-502GDFh0M-FdK8lhHZwwf45BE=.fd778c64-aa01-4e1f-9d67-3df727283e16@github.com>

On Fri, 21 Apr 2023 19:23:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source MenuItem AWT tests.

test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 29:

> 27:   @summary Menu display problem when changing the text of the menu(window 98)
> 28:   @key headful
> 29:   @run main/timeout=600 MenuSetLabelTest

Why the timeout is so big?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1174164403


From honkar at openjdk.org  Fri Apr 21 21:12:06 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Apr 2023 21:12:06 GMT
Subject: RFR: 8306634: Open source AWT Event related tests
Message-ID: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>

This PR open sources few AWT Event related tests.

-------------

Commit messages:
 - added AWT Event tests

Changes: https://git.openjdk.org/jdk/pull/13590/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306634
  Stats: 488 lines in 5 files changed: 488 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13590/head:pull/13590

PR: https://git.openjdk.org/jdk/pull/13590


From serb at openjdk.org  Fri Apr 21 21:12:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:12:07 GMT
Subject: RFR: 8306634: Open source AWT Event related tests
In-Reply-To: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
Message-ID: <k9e1uAipMO9HzoDZpDWBK0bnMlGWKaqUFA_hD6-_2PM=.17a00e69-5130-4031-b3ae-527abfaba2f0@github.com>

On Fri, 21 Apr 2023 21:00:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This PR open sources few AWT Event related tests.

test/jdk/java/awt/Component/RepaintTest.java line 61:

> 59:             robot.delay(500);
> 60: 
> 61:             Color expected = robot.getPixelColor(150, 150);

It is better to check where the frame is located, probably it will be a good idea to move the frame to the center of the screen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13590#discussion_r1174163038


From serb at openjdk.org  Fri Apr 21 21:14:46 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:14:46 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <9i1jG8GPPs3pWwQrdJFRDvHAPpFjlQWxeQqLLfApioI=.164b8dda-2c82-4878-bcdd-32a204476f0a@github.com>

On Fri, 21 Apr 2023 05:19:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> This open source AWT Mouse Info related tests.

test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 136:

> 134:             System.out.println("ComponentMousePositionTest PASSED.");
> 135:         } finally {
> 136:             if (frame != null) {

frame var is assigned on EDT and then used on non-EDT thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1174166142


From serb at openjdk.org  Fri Apr 21 21:15:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:15:42 GMT
Subject: RFR: 8306076: Open source AWT misc tests
In-Reply-To: <zpcEXSJPslUcCSjR5xUA-_852bQC2uqZ3nj7SpUSN7E=.85257550-3689-432a-91cb-697e794cb241@github.com>
References: <zpcEXSJPslUcCSjR5xUA-_852bQC2uqZ3nj7SpUSN7E=.85257550-3689-432a-91cb-697e794cb241@github.com>
Message-ID: <o7qJXQXIhxjxBRE1UCVu8sLNUh-Aen5xblbDXwBRH4A=.0a4ae527-bc68-44e6-b6a5-4c632d16c11f@github.com>

On Fri, 21 Apr 2023 04:59:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT tests

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13572#pullrequestreview-1396404130


From dnguyen at openjdk.org  Fri Apr 21 21:15:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 21 Apr 2023 21:15:59 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
Message-ID: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>

This PR open sources few AWT DnD related tests

-------------

Commit messages:
 - Open source few DnD AWT tests

Changes: https://git.openjdk.org/jdk/pull/13591/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13591&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306133
  Stats: 1064 lines in 5 files changed: 1064 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13591.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13591/head:pull/13591

PR: https://git.openjdk.org/jdk/pull/13591


From serb at openjdk.org  Fri Apr 21 21:19:48 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:19:48 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests
In-Reply-To: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
Message-ID: <-jTc5CWi68FEjwEwPtulQm_8ukF7lE-vPk8L5cl3SYo=.0bb45c43-2b37-4e77-aead-2538eb9c7a14@github.com>

On Fri, 21 Apr 2023 04:00:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Graphics & GridBagLayout tests

test/jdk/java/awt/Graphics/GetGraphicsTest.java line 35:

> 33: import java.awt.Graphics;
> 34: 
> 35: public class GetGraphicsTest {

What this test is expected to test? the getBackground/getForeground/getFont seems to be all unused.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174168135


From kizune at openjdk.org  Fri Apr 21 21:20:58 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 21 Apr 2023 21:20:58 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
Message-ID: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>

Cleaned up and stabilized four Dialog-related tests.

-------------

Commit messages:
 - 8306575: Clean up and open source four Dialog related tests

Changes: https://git.openjdk.org/jdk/pull/13592/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306575
  Stats: 585 lines in 4 files changed: 585 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13592/head:pull/13592

PR: https://git.openjdk.org/jdk/pull/13592


From serb at openjdk.org  Fri Apr 21 21:21:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:21:42 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <hx3nFvbQeZNcxgbkenmc3urfdGh4iKUiywMcf-U-oFk=.574989d1-3dd8-4ce1-8e01-bdd50d35c90c@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
 <xKVx0qNTkDIhwZ6eaWAhGrxbZnhKAc2YWKcDOmpPeao=.66a79687-7c83-4ae0-9351-e58cc3c985f6@github.com>
 <UyXegBPKDRMPvVGvbidWQQkJPVGFNo6JdWJLg1ncnhQ=.28a14455-2485-4936-bafa-a0dbb17f66b0@github.com>
 <hx3nFvbQeZNcxgbkenmc3urfdGh4iKUiywMcf-U-oFk=.574989d1-3dd8-4ce1-8e01-bdd50d35c90c@github.com>
Message-ID: <bIRoTkhGODbxO5LfUHS_91uzr-GarIIKHdJA3IWLf3M=.17f79727-07e9-4057-9ba5-09723af2ac6e@github.com>

On Fri, 21 Apr 2023 20:30:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> or probably it is better to save that tags as custom in IDE, so it will actually check that all of them are correct.
>
> Since it's not a javadoc, I don't see much value in it, and IDE won't complain if you accidentally use such a tag in a source file where a regular javadoc comment is expected.

Why it is not a javadoc? It has all that information, like a description of what the class doing and some references. but it is up to the submitter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1174169860


From duke at openjdk.org  Fri Apr 21 21:26:46 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 21 Apr 2023 21:26:46 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
In-Reply-To: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
Message-ID: <Yk9TS4z_tpzjnhsumIqKBWTeMHEZ47K83-Q-Ltm6Uxk=.e34fd2c3-0c03-49fc-a0a4-7c0f2faef7d9@github.com>

On Fri, 21 Apr 2023 21:11:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and stabilized four Dialog-related tests.

test/jdk/java/awt/Dialog/DialogLocationTest.java line 142:

> 140:         int lastX, lastY;
> 141:         String message = "Failed in componentMoved() expect:[%d,%d]"
> 142:                 + " reported: [%d,%d] diff [%d,%d]";

Can you leave a blank line to separate the method .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1174172213


From serb at openjdk.org  Fri Apr 21 21:26:46 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:26:46 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
Message-ID: <lpv_rlvuAeYDKWeNBmjjYElZL3H667eE3MefshY6vqg=.3bbbb607-ba2c-486d-95a1-aec526241c51@github.com>

On Mon, 17 Apr 2023 08:14:13 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
>> 
>> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.
>
> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed long lines

Marked as reviewed by serb (Reviewer).

src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java line 258:

> 256:          * @param gen the graphics primitive to be registered as the general loop
> 257:          */
> 258:         static synchronized void register(GraphicsPrimitive gen) {

The change looks fine, but it seems we have a good opportunity here to change all that synchronized methods to read/write locks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13459#pullrequestreview-1396412580
PR Review Comment: https://git.openjdk.org/jdk/pull/13459#discussion_r1174171201


From duke at openjdk.org  Fri Apr 21 21:29:45 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 21 Apr 2023 21:29:45 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
In-Reply-To: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
Message-ID: <ju1SsD2W3KYay7CGusKdeDgpOz0-zHZr7sEMdxXXF94=.c566d187-db3b-43c7-92d5-645d4d3ceb0e@github.com>

On Fri, 21 Apr 2023 21:11:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and stabilized four Dialog-related tests.

test/jdk/java/awt/Dialog/ModalDialogOnNonEdt.java line 47:

> 45: 
> 46: public class ModalDialogOnNonEdt {
> 47:     public void start () {

Can you leave a blank line here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1174173864


From honkar at openjdk.org  Fri Apr 21 21:32:08 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Apr 2023 21:32:08 GMT
Subject: RFR: 8306634: Open source AWT Event related tests [v2]
In-Reply-To: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
Message-ID: <qXU-wo678X-E5WDKyb7heY8Ny8gHRoRRLg0_tWWKpRY=.24a3d6b7-d278-46ca-bd68-ee8cf187ec09@github.com>

> This PR open sources few AWT Event related tests.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  moved frame to center

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13590/files
  - new: https://git.openjdk.org/jdk/pull/13590/files/524f26a9..3fe4e764

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13590&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13590&range=00-01

  Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13590/head:pull/13590

PR: https://git.openjdk.org/jdk/pull/13590


From honkar at openjdk.org  Fri Apr 21 21:32:08 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Apr 2023 21:32:08 GMT
Subject: RFR: 8306634: Open source AWT Event related tests [v2]
In-Reply-To: <k9e1uAipMO9HzoDZpDWBK0bnMlGWKaqUFA_hD6-_2PM=.17a00e69-5130-4031-b3ae-527abfaba2f0@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
 <k9e1uAipMO9HzoDZpDWBK0bnMlGWKaqUFA_hD6-_2PM=.17a00e69-5130-4031-b3ae-527abfaba2f0@github.com>
Message-ID: <sZrbsSXkbAlmZDmqyRY8oXrsnw9-MTGHAuvzgjlin8U=.c51a48b2-7a84-4e90-90ab-896c38335416@github.com>

On Fri, 21 Apr 2023 21:06:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved frame to center
>
> test/jdk/java/awt/Component/RepaintTest.java line 61:
> 
>> 59:             robot.delay(500);
>> 60: 
>> 61:             Color expected = robot.getPixelColor(150, 150);
> 
> It is better to check where the frame is located, probably it will be a good idea to move the frame to the center of the screen.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13590#discussion_r1174173528


From serb at openjdk.org  Fri Apr 21 21:34:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 21:34:45 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v6]
In-Reply-To: <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
Message-ID: <A0GvNrKXEuILCwuYY5-BR57ZJhTDTxnx3qSd60nKt30=.6e646656-250c-4c04-8855-c275840c8a03@github.com>

On Fri, 14 Apr 2023 01:54:49 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4200096: removing whitespace diffs
>   
>   prrace pointed out this branch introduced some pointless whitespace changes.
>   https://github.com/openjdk/jdk/pull/13408#discussion_r1164740594

src/java.desktop/share/classes/sun/awt/image/OffScreenImageSource.java line 208:

> 206:             // ImageConsumer detaches itself from this ImageProducer mid-production.
> 207: 
> 208:             if (theConsumer != null) {

Do we need here and a few lines above save the theConsumer to the local, then check to null, then call imageComplete?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1174176182


From duke at openjdk.org  Fri Apr 21 21:37:41 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 21 Apr 2023 21:37:41 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
Message-ID: <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>

On Fri, 21 Apr 2023 21:07:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources few AWT DnD related tests

test/jdk/java/awt/dnd/NextDropActionTest/NextDropActionTest.java line 159:

> 157:             }
> 158:         } finally {
> 159:             if (frame != null) {

frame is created with in EDT but disposing without EDT ?

test/jdk/java/awt/dnd/NoTargetNoDragExitTest/NoTargetNoDragExitTest.java line 136:

> 134:             }
> 135:         }
> 136: 

You can remove extra lines

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1174176703
PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1174177661


From duke at openjdk.org  Fri Apr 21 21:38:41 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 21 Apr 2023 21:38:41 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <mTKHR6Oen71dc02kIpCNU21yclT96sxGZPyhM6R1EZw=.cc5da785-7965-402e-8155-a07511ca2d4d@github.com>

On Fri, 21 Apr 2023 05:19:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> This open source AWT Mouse Info related tests.

test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 92:

> 90:                 throw new RuntimeException("Test failed: Container is overlapped by " + " child and it should be taken into account");
> 91:             }
> 92:             System.out.println("Test stage completed: Container is overlapped by " + " child and it was taken into account");

Can you limit to 80 column length.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1174178177


From prr at openjdk.org  Fri Apr 21 22:11:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 22:11:45 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
Message-ID: <-Gcp3MNwd51QH4vgVrcZlOaR5SBCddnd2S8anNRw6iw=.f603ca0b-8260-4a37-8bbb-8a52fda3723b@github.com>

On Fri, 21 Apr 2023 21:07:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources few AWT DnD related tests

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13591#pullrequestreview-1396439924


From prr at openjdk.org  Fri Apr 21 22:11:47 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 22:11:47 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
Message-ID: <_2bJwut7-7QWhcIqIgi2Mju_e4fsHPTsj2WTsfHEFmY=.8d1d492c-a5d2-4284-95ce-3e2a2d76ae1b@github.com>

On Fri, 21 Apr 2023 21:33:00 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> This PR open sources few AWT DnD related tests
>
> test/jdk/java/awt/dnd/NextDropActionTest/NextDropActionTest.java line 159:
> 
>> 157:             }
>> 158:         } finally {
>> 159:             if (frame != null) {
> 
> frame is created with in EDT but disposing without EDT ?

There's no harm in doing that but I'm not sure its necessary for the dispose().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1174191617


From prr at openjdk.org  Fri Apr 21 22:22:45 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 22:22:45 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
Message-ID: <zD6QKK6QH9JH0tvIqCPlWfW6D2_OcLtJjmo0VLgJfD0=.64188099-96fa-40c0-98df-b9e3e98dbd04@github.com>

On Fri, 21 Apr 2023 20:27:57 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie L. Cobbs 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:
> 
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - Put braces around single-line "if" statement clauses.
>  - Use Set.of() to initialize IGNORABLE_INTERFACES set.
>  - Include default methods inherited from interfaces in bean introspection.

I am submitting a test job to see if there are any unexpected failures from this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1518386795


From serb at openjdk.org  Fri Apr 21 22:26:44 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 22:26:44 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
Message-ID: <cLFRlLRe3PpTX7P2VcUcKUXQYpuZTtr_d4Ku66ztsKI=.b611da56-5808-4eab-adab-364927a61557@github.com>

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13263#pullrequestreview-1396447904


From serb at openjdk.org  Fri Apr 21 22:26:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 22:26:45 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <T-fM4z_n-eb1AocP9rQEvTAMfgu4wsw0h7YgzRZLVHI=.bf3cb7a7-cc8f-4de9-8adc-40c7ddafe8fe@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
 <z1wm37OeqjDt8-0stJoA9L7FHTXtDQ21Xim_GQqj-Fk=.a3e4dde4-2b88-4335-b88f-949626143b96@github.com>
 <h6-B_ny36_NWXC_yggYl8m_rROYRcmIvoguC6vVfBNo=.15aab45e-a8f4-4836-a8ae-4d153e7fdc47@github.com>
 <-6wNY5cssf-oazwqnicJ7ilYAzMt5sf98J3vPlar6w0=.da416751-19b1-41c2-ae85-58951f6c23b9@github.com>
 <54yIiMsqXFck3QsWJlSJ67j2VSW8X2xQisnO2xiLq9g=.57c8cddc-8550-4f28-a928-7f0283fc8cbb@github.com>
 <T-fM4z_n-eb1AocP9rQEvTAMfgu4wsw0h7YgzRZLVHI=.bf3cb7a7-cc8f-4de9-8adc-40c7ddafe8fe@github.com>
Message-ID: <bRnXrSh8EjNS_IgVB5CLZgW2kqqq9meXQTMHfipAerw=.8dae9e6f-b565-4343-856d-8d0ec5fe905a@github.com>

On Fri, 21 Apr 2023 16:48:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If the window is not visible, `updateGC` gets called when the window is shown; if the window is already visible, nothing changes. Thus, the icon will be updated in all the cases.

Then it looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1518388728


From prr at openjdk.org  Fri Apr 21 22:36:41 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 22:36:41 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
In-Reply-To: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
Message-ID: <OdUKKDr9St91vD7pubJgoj-weziUJSoLI2zlNvD9Zso=.4e8305b4-de0c-480d-989e-3e5b9d6a6883@github.com>

On Fri, 21 Apr 2023 21:11:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and stabilized four Dialog-related tests.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13592#pullrequestreview-1396453202


From prr at openjdk.org  Fri Apr 21 22:37:42 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 21 Apr 2023 22:37:42 GMT
Subject: RFR: 8306634: Open source AWT Event related tests [v2]
In-Reply-To: <qXU-wo678X-E5WDKyb7heY8Ny8gHRoRRLg0_tWWKpRY=.24a3d6b7-d278-46ca-bd68-ee8cf187ec09@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
 <qXU-wo678X-E5WDKyb7heY8Ny8gHRoRRLg0_tWWKpRY=.24a3d6b7-d278-46ca-bd68-ee8cf187ec09@github.com>
Message-ID: <CVVLNeGo6mGKeLVpX89RAYMwNKTeeZO7qzo1Aj3KfFo=.7de3380d-8a74-4f72-a8d3-33e661a0d115@github.com>

On Fri, 21 Apr 2023 21:32:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This PR open sources few AWT Event related tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved frame to center

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13590#pullrequestreview-1396455815


From serb at openjdk.org  Fri Apr 21 23:12:44 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 23:12:44 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <_2bJwut7-7QWhcIqIgi2Mju_e4fsHPTsj2WTsfHEFmY=.8d1d492c-a5d2-4284-95ce-3e2a2d76ae1b@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
 <_2bJwut7-7QWhcIqIgi2Mju_e4fsHPTsj2WTsfHEFmY=.8d1d492c-a5d2-4284-95ce-3e2a2d76ae1b@github.com>
Message-ID: <9SkAJmCXwSILkucD99-PGTVz3sJ7aqnBZWpY5dALmGQ=.d258efcf-9f1f-40ec-9578-1edcb52c2bca@github.com>

On Fri, 21 Apr 2023 22:07:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/dnd/NextDropActionTest/NextDropActionTest.java line 159:
>> 
>>> 157:             }
>>> 158:         } finally {
>>> 159:             if (frame != null) {
>> 
>> frame is created with in EDT but disposing without EDT ?
>
> There's no harm in doing that but I'm not sure its necessary for the dispose().

it is fine to call dispose here on the main, but the frame possibly can be null here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1174217484


From duke at openjdk.org  Fri Apr 21 23:18:46 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 21 Apr 2023 23:18:46 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v6]
In-Reply-To: <A0GvNrKXEuILCwuYY5-BR57ZJhTDTxnx3qSd60nKt30=.6e646656-250c-4c04-8855-c275840c8a03@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
 <A0GvNrKXEuILCwuYY5-BR57ZJhTDTxnx3qSd60nKt30=.6e646656-250c-4c04-8855-c275840c8a03@github.com>
Message-ID: <1Tzoitn5sCOL2lPco831YP5eFnMEh7OLGKY0-nHDyZM=.6e70e59a-90a1-4b41-b55c-95ccf2d8be01@github.com>

On Fri, 21 Apr 2023 21:31:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4200096: removing whitespace diffs
>>   
>>   prrace pointed out this branch introduced some pointless whitespace changes.
>>   https://github.com/openjdk/jdk/pull/13408#discussion_r1164740594
>
> src/java.desktop/share/classes/sun/awt/image/OffScreenImageSource.java line 208:
> 
>> 206:             // ImageConsumer detaches itself from this ImageProducer mid-production.
>> 207: 
>> 208:             if (theConsumer != null) {
> 
> Do we need here and a few lines above save the theConsumer to the local, then check to null, then call imageComplete?

My understanding is:

This ticket focuses on the use case where an ImageConsumer detaches itself from this OffScreenImageSource mid-production by calling `removeConsumer(ImageConsumer)`. So in this situation: I'd argue no, the ImageConsumer should not get an `imageComplete(int)` notification. Because it opted to remove itself.

Does this answer your question, or are you considering a different use case?

(Note: `addConsumer` is synchronized, so it's *usually* reasonable to assume the field `OffScreeImageSource#theConsumer` acts *mostly* like a local variable. I could contrive a new failing test case if one ImageConsumer called `addConsumer(newDifferentConsumer)` while receiving a notification, but that's a separate discussion. It's beyond the scope of this ticket, and (to my knowledge) it's a contrived edge case that nobody has ever actually complained about in the real world. And it would fail with or without the changes in this PR...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1174219442


From azvegint at openjdk.org  Fri Apr 21 23:22:12 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 21 Apr 2023 23:22:12 GMT
Subject: RFR: 8306566: Open source several clipboard AWT tests
Message-ID: <VWFnyKEVausrJB7O9dRp8NSvuyo9ckND2Sw1nPFonS4=.4595e16b-32f3-4372-b12f-9f07bed745e3@github.com>

Open sourcing few AWT clipboard tests.

Testing looks good.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/13595/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306566
  Stats: 864 lines in 6 files changed: 864 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13595/head:pull/13595

PR: https://git.openjdk.org/jdk/pull/13595


From serb at openjdk.org  Fri Apr 21 23:45:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 23:45:42 GMT
Subject: RFR: 8306566: Open source several clipboard AWT tests
In-Reply-To: <VWFnyKEVausrJB7O9dRp8NSvuyo9ckND2Sw1nPFonS4=.4595e16b-32f3-4372-b12f-9f07bed745e3@github.com>
References: <VWFnyKEVausrJB7O9dRp8NSvuyo9ckND2Sw1nPFonS4=.4595e16b-32f3-4372-b12f-9f07bed745e3@github.com>
Message-ID: <bOJa8bY-76wBbqfUjQJf8bQ8CaMuIKLIf7kDJMKwxi8=.ab2ddb3c-5378-4814-b98c-c4d32d0632de@github.com>

On Fri, 21 Apr 2023 23:13:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT clipboard tests.
> 
> Testing looks good.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13595#pullrequestreview-1396485106


From serb at openjdk.org  Fri Apr 21 23:46:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 23:46:43 GMT
Subject: RFR: 8306634: Open source AWT Event related tests [v2]
In-Reply-To: <qXU-wo678X-E5WDKyb7heY8Ny8gHRoRRLg0_tWWKpRY=.24a3d6b7-d278-46ca-bd68-ee8cf187ec09@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
 <qXU-wo678X-E5WDKyb7heY8Ny8gHRoRRLg0_tWWKpRY=.24a3d6b7-d278-46ca-bd68-ee8cf187ec09@github.com>
Message-ID: <D-WatVYblRYyZaNoPsX2okQZmg-rlq07XiUI_OWJ7Tk=.0da51644-ac79-4fa7-b790-7c1f938ea53e@github.com>

On Fri, 21 Apr 2023 21:32:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This PR open sources few AWT Event related tests.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved frame to center

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13590#pullrequestreview-1396485473


From honkar at openjdk.org  Fri Apr 21 23:58:59 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Apr 2023 23:58:59 GMT
Subject: Integrated: 8306634: Open source AWT Event related tests
In-Reply-To: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
References: <QjroWv9z8C900A8VlC6N6nDMwmMi0ySttAmQQyGDkaA=.8d76b89d-91bc-4283-8ac0-f112ff9b2e3c@github.com>
Message-ID: <-5ECU70d24j5adpLHMYdnkfuJl0LzRweiPwOILTY-C4=.c0b98473-0d3a-4927-9816-cdb47d9ff017@github.com>

On Fri, 21 Apr 2023 21:00:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This PR open sources few AWT Event related tests.

This pull request has now been integrated.

Changeset: 9ed456fa
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ed456fac87f598af7d71f9c0887234a09e10eed
Stats:     495 lines in 5 files changed: 495 ins; 0 del; 0 mod

8306634: Open source AWT Event related tests

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13590


From kizune at openjdk.org  Sat Apr 22 00:21:06 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 22 Apr 2023 00:21:06 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
 [v2]
In-Reply-To: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
Message-ID: <mR8FT20hD3sE0IgqaYKDH3EoIB9YnRBJkQVdd1sT2h8=.600c64b2-1ee9-419a-a28a-5b92ed8f45d7@github.com>

> Cleaned up and stabilized four Dialog-related tests.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Added couple of empty lines to make code nore readable.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13592/files
  - new: https://git.openjdk.org/jdk/pull/13592/files/233bc71b..de12275d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13592&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13592&range=00-01

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13592/head:pull/13592

PR: https://git.openjdk.org/jdk/pull/13592


From kizune at openjdk.org  Sat Apr 22 00:21:07 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 22 Apr 2023 00:21:07 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
 [v2]
In-Reply-To: <Yk9TS4z_tpzjnhsumIqKBWTeMHEZ47K83-Q-Ltm6Uxk=.e34fd2c3-0c03-49fc-a0a4-7c0f2faef7d9@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
 <Yk9TS4z_tpzjnhsumIqKBWTeMHEZ47K83-Q-Ltm6Uxk=.e34fd2c3-0c03-49fc-a0a4-7c0f2faef7d9@github.com>
Message-ID: <syMbGmh8YpVsetWsWgZzHRNXreI0x1o8Dc0NcttLc5Y=.169809dd-19c9-4b36-b480-14a01c50d9a0@github.com>

On Fri, 21 Apr 2023 21:23:57 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added couple of empty lines to make code nore readable.
>
> test/jdk/java/awt/Dialog/DialogLocationTest.java line 142:
> 
>> 140:         int lastX, lastY;
>> 141:         String message = "Failed in componentMoved() expect:[%d,%d]"
>> 142:                 + " reported: [%d,%d] diff [%d,%d]";
> 
> Can you leave a blank line to separate the method .

Done.

> test/jdk/java/awt/Dialog/ModalDialogOnNonEdt.java line 47:
> 
>> 45: 
>> 46: public class ModalDialogOnNonEdt {
>> 47:     public void start () {
> 
> Can you leave a blank line here

Sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1174232601
PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1174232561


From kizune at openjdk.org  Sat Apr 22 00:21:09 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 22 Apr 2023 00:21:09 GMT
Subject: Integrated: 8306575: Clean up and open source four Dialog related
 tests
In-Reply-To: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
Message-ID: <uvny8pbgoPPW6Dx198pae0_hOugm7QiLRcLbs8z4N1g=.9e18d499-bfb3-4706-8a8a-9516c3c25eb7@github.com>

On Fri, 21 Apr 2023 21:11:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and stabilized four Dialog-related tests.

This pull request has now been integrated.

Changeset: 8d696aea
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d696aea9e1cefca97a760c017a5fde545facaa9
Stats:     587 lines in 4 files changed: 587 ins; 0 del; 0 mod

8306575: Clean up and open source four Dialog related tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13592


From serb at openjdk.org  Sat Apr 22 05:39:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 22 Apr 2023 05:39:45 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v6]
In-Reply-To: <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
Message-ID: <JLCwmffGxXuKzZURB0Tfg94u4IG37EPklFwgpIMKXCk=.19235cf6-b3a1-46bd-8281-f6842307c37f@github.com>

On Fri, 14 Apr 2023 01:54:49 GMT, Jeremy <duke at openjdk.org> wrote:

>> This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly.
>> 
>> This resolution involves confirming that an ImageConsumer is still registered before every notification.
>> 
>> I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4200096: removing whitespace diffs
>   
>   prrace pointed out this branch introduced some pointless whitespace changes.
>   https://github.com/openjdk/jdk/pull/13408#discussion_r1164740594

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13408#pullrequestreview-1396575914


From serb at openjdk.org  Sat Apr 22 05:39:47 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 22 Apr 2023 05:39:47 GMT
Subject: RFR: 4200096: OffScreenImageSource.removeConsumer
 NullPointerException [v6]
In-Reply-To: <1Tzoitn5sCOL2lPco831YP5eFnMEh7OLGKY0-nHDyZM=.6e70e59a-90a1-4b41-b55c-95ccf2d8be01@github.com>
References: <ROLiyZj9M37ZBJDEcuWqkKswx4feT6Kp2MQM6gdto3w=.563e5446-35f4-44b5-930c-d2fc0521f2bd@github.com>
 <V-nmQu5pGqACp6agbk8ZWQPCwCtIxDhRukiXfnnFFt8=.3f917539-e591-4afd-893f-11e0b1975a92@github.com>
 <A0GvNrKXEuILCwuYY5-BR57ZJhTDTxnx3qSd60nKt30=.6e646656-250c-4c04-8855-c275840c8a03@github.com>
 <1Tzoitn5sCOL2lPco831YP5eFnMEh7OLGKY0-nHDyZM=.6e70e59a-90a1-4b41-b55c-95ccf2d8be01@github.com>
Message-ID: <lyNlPxO22bs3BFpVvjtiqhIOP9HBNQcE1N5LjtNBbYg=.06a84c5c-ed18-461d-b920-6d1aa419a864@github.com>

On Fri, 21 Apr 2023 23:16:06 GMT, Jeremy <duke at openjdk.org> wrote:

> Does this answer your question, or are you considering a different use case?

Yes, if it is safe to assume that it is not possible to change the `theConsumer` by a different thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13408#discussion_r1174297664


From duke at openjdk.org  Sat Apr 22 16:42:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 22 Apr 2023 16:42:43 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <zD6QKK6QH9JH0tvIqCPlWfW6D2_OcLtJjmo0VLgJfD0=.64188099-96fa-40c0-98df-b9e3e98dbd04@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
 <zD6QKK6QH9JH0tvIqCPlWfW6D2_OcLtJjmo0VLgJfD0=.64188099-96fa-40c0-98df-b9e3e98dbd04@github.com>
Message-ID: <GUNNt1gDhMkIcyYv1bd3sS7lBOyEqwqTIdcJzga50dU=.78823475-4f5e-4851-b653-c1f6defcde69@github.com>

On Fri, 21 Apr 2023 22:19:28 GMT, Phil Race <prr at openjdk.org> wrote:

> I am submitting a test job to see if there are any unexpected failures from this change.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1518699818


From aturbanov at openjdk.org  Sun Apr 23 19:42:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 23 Apr 2023 19:42:43 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <6o7mHooe8Tg92_x_2Q_ZrKuFjkSme5WwzVMuJ18HDYU=.4bd6db3f-c1f3-4b1c-9ead-4ffb67452d72@github.com>

On Fri, 21 Apr 2023 19:23:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source MenuItem AWT tests.

test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 82:

> 80:     Menu f = new Menu(s1);
> 81:     Menu m = new Menu(s1);
> 82:     boolean  flag = true;

Suggestion:

    boolean flag = true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1174633088


From aturbanov at openjdk.org  Sun Apr 23 19:44:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 23 Apr 2023 19:44:44 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests
In-Reply-To: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
Message-ID: <bmyAtFiwGyguQRMbMREzTb1LcQP9lVWIHc41_4I8A1g=.65078229-9718-40fd-84dc-065b6ed3db2a@github.com>

On Fri, 21 Apr 2023 04:00:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Graphics & GridBagLayout tests

test/jdk/java/awt/GridBagLayout/GridBagLayoutButtonsOverlapTest.java line 81:

> 79: 
> 80:         c.weightx = 0.0;
> 81:         b5 =  makeButton("button5", gridbag, c);

Suggestion:

        b5 = makeButton("button5", gridbag, c);

test/jdk/java/awt/GridBagLayout/GridBagLayoutButtonsOverlapTest.java line 107:

> 105: 
> 106:         int b1Corner = b1.getLocation().y + b1.getHeight();
> 107:         int  b5Corner = b5.getLocation().y;

Suggestion:

        int b5Corner = b5.getLocation().y;

test/jdk/java/awt/GridBagLayout/GridBagLayoutButtonsOverlapTest.java line 114:

> 112:     }
> 113: 
> 114:     protected static Button  makeButton(String name,

Suggestion:

    protected static Button makeButton(String name,

test/jdk/java/awt/GridBagLayout/GridBagLayoutButtonsOverlapTest.java line 117:

> 115:                                  GridBagLayout gridbag,
> 116:                                  GridBagConstraints c) {
> 117:         Button button  = new Button(name);

Suggestion:

        Button button = new Button(name);

test/jdk/java/awt/GridBagLayout/GridBagLayoutOutOfBoundsTest.java line 51:

> 49:                 GridBagConstraints gridBagConstraints;
> 50: 
> 51:                 Button[]  mb = new Button[L];

Suggestion:

                Button[] mb = new Button[L];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174633174
PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174633209
PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174633222
PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174633248
PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174633284


From psadhukhan at openjdk.org  Mon Apr 24 03:13:53 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 24 Apr 2023 03:13:53 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests
In-Reply-To: <-jTc5CWi68FEjwEwPtulQm_8ukF7lE-vPk8L5cl3SYo=.0bb45c43-2b37-4e77-aead-2538eb9c7a14@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
 <-jTc5CWi68FEjwEwPtulQm_8ukF7lE-vPk8L5cl3SYo=.0bb45c43-2b37-4e77-aead-2538eb9c7a14@github.com>
Message-ID: <0hRcDArZsGBa1jU9tvkvnV9oOVwy20c_L2MBQgyEfcg=.432bc089-5383-4890-ac7a-11cc7b060707@github.com>

On Fri, 21 Apr 2023 21:15:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This opensources few AWT Graphics & GridBagLayout tests
>
> test/jdk/java/awt/Graphics/GetGraphicsTest.java line 35:
> 
>> 33: import java.awt.Graphics;
>> 34: 
>> 35: public class GetGraphicsTest {
> 
> What this test is expected to test? the getBackground/getForeground/getFont seems to be all unused.

As the test summary mentioned, it supposed to "Check getGraphics doesn't throw NullPointerExcepton for invalid colors and font"...the closed test was also like it...was applet based which is just converted to use BufferedImage.getGraphics to be a headless test..
Seems [4746122](https://bugs.openjdk.org/browse/JDK-4746122):Failed to load applet fix is about applet,
Once comment in the bug says 

The problem is applet overrides Component.getBackground()/getForeground() to
return null. So SunGraphics2D is created with null params


 so I guess this test is redundant now and we can remove..please suggest..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1174740376


From tr at openjdk.org  Mon Apr 24 06:35:49 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 06:35:49 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v2]
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <6sHKqEH-jIt7jdddcodJflSVRsrqUz3NnsLbrVrXf5w=.f75c3e46-9655-4e8c-b7fb-343e743faaf8@github.com>

> This open source AWT Mouse Info related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13573/files
  - new: https://git.openjdk.org/jdk/pull/13573/files/55213afa..46095a01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=00-01

  Stats: 78 lines in 1 file changed: 33 ins; 0 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From tr at openjdk.org  Mon Apr 24 06:40:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 06:40:54 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v2]
In-Reply-To: <mTKHR6Oen71dc02kIpCNU21yclT96sxGZPyhM6R1EZw=.cc5da785-7965-402e-8155-a07511ca2d4d@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <mTKHR6Oen71dc02kIpCNU21yclT96sxGZPyhM6R1EZw=.cc5da785-7965-402e-8155-a07511ca2d4d@github.com>
Message-ID: <btq055n26CTfTH3M2t9fGEKdTK6KoqjCLbx1OefotBU=.e3173417-efac-4ecf-ab7a-56858bdb7865@github.com>

On Fri, 21 Apr 2023 21:36:16 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 92:
> 
>> 90:                 throw new RuntimeException("Test failed: Container is overlapped by " + " child and it should be taken into account");
>> 91:             }
>> 92:             System.out.println("Test stage completed: Container is overlapped by " + " child and it was taken into account");
> 
> Can you limit to 80 column length.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1174844434


From tr at openjdk.org  Mon Apr 24 06:40:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 06:40:56 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v2]
In-Reply-To: <9i1jG8GPPs3pWwQrdJFRDvHAPpFjlQWxeQqLLfApioI=.164b8dda-2c82-4878-bcdd-32a204476f0a@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <9i1jG8GPPs3pWwQrdJFRDvHAPpFjlQWxeQqLLfApioI=.164b8dda-2c82-4878-bcdd-32a204476f0a@github.com>
Message-ID: <oLVg-kys18mPRDbSRT8XC3RIDdKjoQF4zrrmHgCTqTs=.ebffe6fb-c89b-4772-97f8-1abd89554296@github.com>

On Fri, 21 Apr 2023 21:12:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 136:
> 
>> 134:             System.out.println("ComponentMousePositionTest PASSED.");
>> 135:         } finally {
>> 136:             if (frame != null) {
> 
> frame var is assigned on EDT and then used on non-EDT thread.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1174844325


From psadhukhan at openjdk.org  Mon Apr 24 07:55:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 24 Apr 2023 07:55:58 GMT
Subject: Integrated: 8306076: Open source AWT misc tests
In-Reply-To: <zpcEXSJPslUcCSjR5xUA-_852bQC2uqZ3nj7SpUSN7E=.85257550-3689-432a-91cb-697e794cb241@github.com>
References: <zpcEXSJPslUcCSjR5xUA-_852bQC2uqZ3nj7SpUSN7E=.85257550-3689-432a-91cb-697e794cb241@github.com>
Message-ID: <OpnIsgH31fNeoT-PmE6lsIMGhEdWsDvMN7RyI1wkCXw=.5a858e7a-dd39-41f7-8e3a-dbe8c6fc8846@github.com>

On Fri, 21 Apr 2023 04:59:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT tests

This pull request has now been integrated.

Changeset: f7d45b85
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7d45b85a5c664a87c94e0baccd8b9eddce27e2c
Stats:     169 lines in 3 files changed: 169 ins; 0 del; 0 mod

8306076: Open source AWT misc tests

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13572


From mdoerr at openjdk.org  Mon Apr 24 09:55:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 24 Apr 2023 09:55:57 GMT
Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply
 [v17]
In-Reply-To: <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
 <vjrFk-Qfyw2CzxBi-Sh0ZgkeeMUqhWW5f72bdqyqHFE=.1e5f2fb4-6bb3-4fcb-831c-20bd0765b17b@github.com>
Message-ID: <uFsylWCuJJd928I1OAvB2B5eHZQXtjb_wQo9K9JHAPQ=.7be13e5c-1636-485f-b4bd-d26b50f2cb99@github.com>

On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE

Thanks for the comment updates!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1397600716


From psadhukhan at openjdk.org  Mon Apr 24 10:00:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 24 Apr 2023 10:00:05 GMT
Subject: RFR: 8306714: Open source few Swing event and AbstractAction tests
Message-ID: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>

This opensources few Swing event and AbstractAction tests

-------------

Commit messages:
 - 8306714: Open source few Swing event and AbstractAction tests
 - 8306714: Open source few Swing event and AbstractAction tests

Changes: https://git.openjdk.org/jdk/pull/13608/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13608&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306714
  Stats: 329 lines in 6 files changed: 329 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13608/head:pull/13608

PR: https://git.openjdk.org/jdk/pull/13608


From tr at openjdk.org  Mon Apr 24 10:04:49 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 10:04:49 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>

> This open source AWT Mouse Info related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13573/files
  - new: https://git.openjdk.org/jdk/pull/13573/files/46095a01..9be33246

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From azvegint at openjdk.org  Mon Apr 24 10:59:59 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 24 Apr 2023 10:59:59 GMT
Subject: Integrated: 8306566: Open source several clipboard AWT tests
In-Reply-To: <VWFnyKEVausrJB7O9dRp8NSvuyo9ckND2Sw1nPFonS4=.4595e16b-32f3-4372-b12f-9f07bed745e3@github.com>
References: <VWFnyKEVausrJB7O9dRp8NSvuyo9ckND2Sw1nPFonS4=.4595e16b-32f3-4372-b12f-9f07bed745e3@github.com>
Message-ID: <YUztIb5BjxclvAwu3Wx6WCy3k2dEfnZyV0I4U64G55s=.9fe84f4f-260a-43cb-9042-cbe45d580f75@github.com>

On Fri, 21 Apr 2023 23:13:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open sourcing few AWT clipboard tests.
> 
> Testing looks good.

This pull request has now been integrated.

Changeset: 136dad71
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/136dad7197a1969b2b1fc325f4336c20386c5d3b
Stats:     864 lines in 6 files changed: 864 ins; 0 del; 0 mod

8306566: Open source several clipboard AWT tests

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13595


From aivanov at openjdk.org  Mon Apr 24 12:16:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 12:16:57 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
Message-ID: <Q5BKC5W01gNQLaIzZq0BEcsmZb6LRsN4BEICB3RLaH4=.ee105947-36c9-43c3-bd6c-8c73d9c2398c@github.com>

On Mon, 17 Apr 2023 08:14:13 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
>> 
>> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.
>
> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed long lines

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13459#pullrequestreview-1397851896


From duke at openjdk.org  Mon Apr 24 13:37:54 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 24 Apr 2023 13:37:54 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
Message-ID: <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>

On Mon, 24 Apr 2023 10:04:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> This open source AWT Mouse Info related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated

test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 88:

> 86:             EventQueue.invokeAndWait(() -> {
> 87:                 Point p = button.getLocationOnScreen();
> 88:                 xPos = p.x + button.getWidth() / 2;

xPos & yPos are used within EDT and outside EDT ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175295899


From tr at openjdk.org  Mon Apr 24 14:10:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 14:10:56 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
Message-ID: <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>

On Mon, 24 Apr 2023 13:35:20 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated
>
> test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 88:
> 
>> 86:             EventQueue.invokeAndWait(() -> {
>> 87:                 Point p = button.getLocationOnScreen();
>> 88:                 xPos = p.x + button.getWidth() / 2;
> 
> xPos & yPos are used within EDT and outside EDT ?

Yeah, getting the values within EDT and used for `Robot` operations outside. Isn't it allowed ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175342742


From duke at openjdk.org  Mon Apr 24 14:13:46 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 24 Apr 2023 14:13:46 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
 <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
Message-ID: <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>

On Mon, 24 Apr 2023 14:08:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 88:
>> 
>>> 86:             EventQueue.invokeAndWait(() -> {
>>> 87:                 Point p = button.getLocationOnScreen();
>>> 88:                 xPos = p.x + button.getWidth() / 2;
>> 
>> xPos & yPos are used within EDT and outside EDT ?
>
> Yeah, getting the values within EDT and used for `Robot` operations outside. Isn't it allowed ?

It is allowed please use transient keyword for xPos & yPos

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175346404


From tr at openjdk.org  Mon Apr 24 14:25:52 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 14:25:52 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
 <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
 <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
Message-ID: <yeYgSKHR_nqKonNMsMsnzy-nCcHAxwKgEkhd4K4ceHw=.97e9f346-c7aa-4498-8197-93293fd17fdf@github.com>

On Mon, 24 Apr 2023 14:11:00 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Yeah, getting the values within EDT and used for `Robot` operations outside. Isn't it allowed ?
>
> It is allowed please use transient keyword for xPos & yPos

Sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175363356


From tr at openjdk.org  Mon Apr 24 14:42:14 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 14:42:14 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v4]
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <v1LgUcBhC98cJOoL4ILHzIQM4nti7R_Xbe7eT7nMOGA=.e5ae42e8-2d8a-4f91-8b21-a1162e650863@github.com>

> This open source AWT Mouse Info related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13573/files
  - new: https://git.openjdk.org/jdk/pull/13573/files/9be33246..3d20f395

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From duke at openjdk.org  Mon Apr 24 15:00:55 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Mon, 24 Apr 2023 15:00:55 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
 <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
 <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
Message-ID: <sEoLFP25SGtEzrdZm8kyTad8qQ8Su2Q-NJW2TI79hzE=.ca15a5cc-08b4-4b60-90d1-f648fc12af27@github.com>

On Mon, 24 Apr 2023 14:11:00 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Yeah, getting the values within EDT and used for `Robot` operations outside. Isn't it allowed ?
>
> It is allowed please use transient keyword for xPos & yPos

@lawrence-andrew, BTW, why `transient`? Should it be `volatile` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175418130


From duke at openjdk.org  Mon Apr 24 15:39:56 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 24 Apr 2023 15:39:56 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <sEoLFP25SGtEzrdZm8kyTad8qQ8Su2Q-NJW2TI79hzE=.ca15a5cc-08b4-4b60-90d1-f648fc12af27@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
 <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
 <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
 <sEoLFP25SGtEzrdZm8kyTad8qQ8Su2Q-NJW2TI79hzE=.ca15a5cc-08b4-4b60-90d1-f648fc12af27@github.com>
Message-ID: <LSFxEQbL8D6XTfJMIOafFjwW6yq87s3PbvmTQsqGJWY=.a9571c54-0659-4671-bfa2-4295a916d0f2@github.com>

On Mon, 24 Apr 2023 14:58:06 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> It is allowed please use transient keyword for xPos & yPos
>
> @lawrence-andrew, BTW, why `transient`? Should it be `volatile` instead?

Oh, yes, sorry I was meant to say volatile but I typed transient. Sorry for the confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175469201


From tr at openjdk.org  Mon Apr 24 16:40:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 16:40:53 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v5]
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>

> This open source AWT Mouse Info related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13573/files
  - new: https://git.openjdk.org/jdk/pull/13573/files/3d20f395..86ba000c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From duke at openjdk.org  Mon Apr 24 16:40:55 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 24 Apr 2023 16:40:55 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v3]
In-Reply-To: <LSFxEQbL8D6XTfJMIOafFjwW6yq87s3PbvmTQsqGJWY=.a9571c54-0659-4671-bfa2-4295a916d0f2@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <gKENmTiwXCwjWrEDcsEQq228rAQSx9Mf7Ok82b0KJa8=.70a40c2b-ddcd-40c6-b225-570f57da250f@github.com>
 <l9gVV8831QyfCOEB_AkbBxD0y1cMoSdGgpUYtJB7Zfw=.777aee27-357a-427f-9802-f7b6367d0369@github.com>
 <yNvSTIeJSfUUuuGq0ZJjKHFhLsiSIKggT6EbSBRFWr8=.339eb31f-957f-45fe-baeb-a9de1aecc78a@github.com>
 <kYpSCXKhY9t7URNinPKtC8rmZXZLNJ1TXoVMTj7CZGU=.88891f3a-efc9-4015-965c-67e92f8e984b@github.com>
 <sEoLFP25SGtEzrdZm8kyTad8qQ8Su2Q-NJW2TI79hzE=.ca15a5cc-08b4-4b60-90d1-f648fc12af27@github.com>
 <LSFxEQbL8D6XTfJMIOafFjwW6yq87s3PbvmTQsqGJWY=.a9571c54-0659-4671-bfa2-4295a916d0f2@github.com>
Message-ID: <5Oc78xsA_eG5Y5EhK-wKnPr51lhQXuAyVhOLWTEaGUM=.b840783d-ca69-4a35-ba12-2d7637f82397@github.com>

On Mon, 24 Apr 2023 15:36:34 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> @lawrence-andrew, BTW, why `transient`? Should it be `volatile` instead?
>
> Oh, yes, sorry I was meant to say volatile but I typed transient. Sorry for the confusion.

Looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1175538318


From prr at openjdk.org  Mon Apr 24 17:01:47 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 17:01:47 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
Message-ID: <an582WmnXFcaQwMbibJZZTtACUkD3qy7IIBDbwIz4Dw=.c2165289-431f-4426-bf3f-f0b6bef50bbd@github.com>

On Fri, 21 Apr 2023 20:27:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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:
> 
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - Put braces around single-line "if" statement clauses.
>  - Use Set.of() to initialize IGNORABLE_INTERFACES set.
>  - Include default methods inherited from interfaces in bean introspection.

All tests passed.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1398455946


From acobbs at openjdk.org  Mon Apr 24 17:07:03 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Apr 2023 17:07:03 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
Message-ID: <EPu8V3RN8d6HGfhV_DiAgb8YRhSXbHvSZIKGFHIGIag=.77319344-073d-4b26-8988-6afe7f17aadb@github.com>

On Fri, 21 Apr 2023 20:27:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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:
> 
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - Put braces around single-line "if" statement clauses.
>  - Use Set.of() to initialize IGNORABLE_INTERFACES set.
>  - Include default methods inherited from interfaces in bean introspection.

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1520530800


From prr at openjdk.org  Mon Apr 24 17:34:29 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 17:34:29 GMT
Subject: RFR: 8306484: Open source several AWT Choice jtreg tests
Message-ID: <pUW4t0HRVjP-408o8mNllpKH_RjKy_QGHdTMooXpyBg=.0bb4dbd1-dc5f-477b-b013-2e32f9284c49@github.com>

Open sourcing several AWT Choice regression tests

-------------

Commit messages:
 - 8306484

Changes: https://git.openjdk.org/jdk/pull/13620/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13620&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306484
  Stats: 1048 lines in 6 files changed: 1048 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13620/head:pull/13620

PR: https://git.openjdk.org/jdk/pull/13620


From aivanov at openjdk.org  Mon Apr 24 17:34:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 17:34:48 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
Message-ID: <Wucy2QQV_EFd03Q-fc9f7h9cP-KS9tUH36uqxuiUxGM=.80088c77-72be-4ad6-abc3-8ee2b0e41b2b@github.com>

On Fri, 21 Apr 2023 20:27:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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:
> 
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - Put braces around single-line "if" statement clauses.
>  - Use Set.of() to initialize IGNORABLE_INTERFACES set.
>  - Include default methods inherited from interfaces in bean introspection.

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 111:

> 109:             for (Class<?> iface : type.getInterfaces()) {
> 110:                 if (IGNORABLE_INTERFACES.contains(iface))
> 111:                     continue;

Suggestion:

                if (IGNORABLE_INTERFACES.contains(iface)) {
                    continue;
                }

-------------

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1398503534
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175593473


From prr at openjdk.org  Mon Apr 24 17:47:08 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 17:47:08 GMT
Subject: RFR: 8306682: Open source a few more AWT Choice tests
Message-ID: <kSR6kiYMZC38OaksCPwdRYXAlQUBRjemHgY1cAmvagg=.c874970f-4fb9-4169-baeb-050fdff3b244@github.com>

Open source a few more AWT Choice tests

-------------

Commit messages:
 - 8306682

Changes: https://git.openjdk.org/jdk/pull/13622/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306682
  Stats: 535 lines in 4 files changed: 535 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13622/head:pull/13622

PR: https://git.openjdk.org/jdk/pull/13622


From tr at openjdk.org  Mon Apr 24 17:47:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 17:47:25 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
Message-ID: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>

Open source few AWT ScrollPane related tests.

-------------

Commit messages:
 - Converted test

Changes: https://git.openjdk.org/jdk/pull/13621/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306137
  Stats: 822 lines in 7 files changed: 822 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621

PR: https://git.openjdk.org/jdk/pull/13621


From acobbs at openjdk.org  Mon Apr 24 17:48:37 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Apr 2023 17:48:37 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v6]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add braces around if clause.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/ac90a10e..8c129960

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544

PR: https://git.openjdk.org/jdk/pull/13544


From acobbs at openjdk.org  Mon Apr 24 17:49:03 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Apr 2023 17:49:03 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v5]
In-Reply-To: <Wucy2QQV_EFd03Q-fc9f7h9cP-KS9tUH36uqxuiUxGM=.80088c77-72be-4ad6-abc3-8ee2b0e41b2b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <sK7HV9fi23qu2UzvLelbvmbAzU0XVIUDV_q302gPdro=.c894a25d-1c2f-4e8e-bd7c-43b22e279205@github.com>
 <Wucy2QQV_EFd03Q-fc9f7h9cP-KS9tUH36uqxuiUxGM=.80088c77-72be-4ad6-abc3-8ee2b0e41b2b@github.com>
Message-ID: <yqc9TlrrnC737MINHJTR2CJXixJkfgGpo0Inrw-88CQ=.640559b0-1a58-4214-a54e-ef9e770311dd@github.com>

On Mon, 24 Apr 2023 17:30:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Archie Cobbs 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:
>> 
>>  - Add comment describing what IGNORABLE_INTERFACES is for.
>>  - Put braces around single-line "if" statement clauses in test.
>>  - Merge branch 'master' into JDK-8071693
>>  - Verify static method is not mistakenly identified as property getter.
>>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>>  - Put braces around single-line "if" statement clauses.
>>  - Use Set.of() to initialize IGNORABLE_INTERFACES set.
>>  - Include default methods inherited from interfaces in bean introspection.
>
> src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java line 111:
> 
>> 109:             for (Class<?> iface : type.getInterfaces()) {
>> 110:                 if (IGNORABLE_INTERFACES.contains(iface))
>> 111:                     continue;
> 
> Suggestion:
> 
>                 if (IGNORABLE_INTERFACES.contains(iface)) {
>                     continue;
>                 }

Thanks - fixed in 8c129960a37.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175600707


From duke at openjdk.org  Mon Apr 24 18:08:14 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 24 Apr 2023 18:08:14 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <_i919Sm2wt1tqcPcNGq4V1OuHmSoye2YtOFc9rV072M=.109c0ef1-9448-4601-b587-2c7f41b584c7@github.com>

On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT ScrollPane related tests.

test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java line 48:

> 46:     public Frame frame;
> 47:     public int count = 0;
> 48:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {

Can you please leave a blank line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175613396


From serb at openjdk.org  Mon Apr 24 18:17:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:17:54 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v6]
In-Reply-To: <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>
Message-ID: <L6EcLKxoTp9Tgk--44Wqirxa9XashROXSA3ARmx67Ik=.089e165f-ca6e-49a0-80f5-618d4518d60d@github.com>

On Mon, 24 Apr 2023 17:48:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add braces around if clause.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 34:

> 32: import java.util.HashSet;
> 33: 
> 34: public class DefaultMethodBeanPropertyTest {

Can we please add two additional tests to verify the "diamond" case:
 - getFoo is in the top interfaceA, two empty subinterfaces B anc C , and one class D of B and C, will the D have one correct prop Foo?
- getFoo is in the top interfaceA, two non-empty subinterfaces B and C and each override getFoo by the different return types, and then one class D of B and C which override getFoo again by compatible type from B and C, will the D have one correct prop Foo?

We also can test the case if the D from the cases above is interface and implemented by the class E.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 78:

> 76: 
> 77:         // Expected properties
> 78:         final HashSet<PropertyDescriptor> expected = new HashSet<>();

please split the long lines to use 80 chars per line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175633760
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175634936


From serb at openjdk.org  Mon Apr 24 18:24:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:24:54 GMT
Subject: RFR: 8306682: Open source a few more AWT Choice tests
In-Reply-To: <kSR6kiYMZC38OaksCPwdRYXAlQUBRjemHgY1cAmvagg=.c874970f-4fb9-4169-baeb-050fdff3b244@github.com>
References: <kSR6kiYMZC38OaksCPwdRYXAlQUBRjemHgY1cAmvagg=.c874970f-4fb9-4169-baeb-050fdff3b244@github.com>
Message-ID: <LJAUAf0iLll3RAtefYzrhX9FBPRS0E1MF1r8q9Y_T5g=.ceea548d-8cff-43f4-800d-b9ec72ad28bd@github.com>

On Mon, 24 Apr 2023 17:39:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source a few more AWT Choice tests

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13622#pullrequestreview-1398575644


From serb at openjdk.org  Mon Apr 24 18:25:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:25:38 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>

On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT ScrollPane related tests.

test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java line 87:

> 85:             });
> 86:         } finally {
> 87:             EventQueue.invokeLater(() -> {

Why the invokeLater is used here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175641942


From serb at openjdk.org  Mon Apr 24 18:27:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:27:14 GMT
Subject: RFR: 8306484: Open source several AWT Choice jtreg tests
In-Reply-To: <pUW4t0HRVjP-408o8mNllpKH_RjKy_QGHdTMooXpyBg=.0bb4dbd1-dc5f-477b-b013-2e32f9284c49@github.com>
References: <pUW4t0HRVjP-408o8mNllpKH_RjKy_QGHdTMooXpyBg=.0bb4dbd1-dc5f-477b-b013-2e32f9284c49@github.com>
Message-ID: <OqXLWE90YTTshjG_nIF75ybzLroka6hGDyDZ9fYKI0U=.5b840c82-4ca2-4eb9-858e-f2ce8dacfcc2@github.com>

On Mon, 24 Apr 2023 17:25:31 GMT, Phil Race <prr at openjdk.org> wrote:

> Open sourcing several AWT Choice regression tests

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13620#pullrequestreview-1398579071


From serb at openjdk.org  Mon Apr 24 18:28:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:28:58 GMT
Subject: RFR: 8306714: Open source few Swing event and AbstractAction tests
In-Reply-To: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
References: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
Message-ID: <VG2ndMyY5qPi6BszbnSccD7yrpE9pgaH3BmQ-kY0JSY=.f0c344a4-5e5b-4a92-bb04-d261255890c4@github.com>

On Mon, 24 Apr 2023 09:51:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few Swing event and AbstractAction tests

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13608#pullrequestreview-1398581656


From aivanov at openjdk.org  Mon Apr 24 18:34:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 18:34:32 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v6]
In-Reply-To: <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>
Message-ID: <erN8MRh4QkWfOd69oTLwz1POmNOr1mx0pn2Nq4FOqgE=.7085ba12-4de5-40db-a3e5-7d3b79d8d09f@github.com>

On Mon, 24 Apr 2023 17:48:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add braces around if clause.

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1398588735


From tr at openjdk.org  Mon Apr 24 18:40:06 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 24 Apr 2023 18:40:06 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>
Message-ID: <9W_vad0YRz-C8xT3Lxa42JnTfxcpxVJxQk_DN9OU4zE=.da0d10bc-c9ac-4565-8787-9e1979db050c@github.com>

On Mon, 24 Apr 2023 18:23:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java line 87:
> 
>> 85:             });
>> 86:         } finally {
>> 87:             EventQueue.invokeLater(() -> {
> 
> Why the invokeLater is used here?

I preferred asynchronous EDT would be better since its finally block. Is there any particular reason that we should use `invokeAndWait` than `invokeLater`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175654305


From serb at openjdk.org  Mon Apr 24 18:44:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:44:02 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
 [v2]
In-Reply-To: <mR8FT20hD3sE0IgqaYKDH3EoIB9YnRBJkQVdd1sT2h8=.600c64b2-1ee9-419a-a28a-5b92ed8f45d7@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
 <mR8FT20hD3sE0IgqaYKDH3EoIB9YnRBJkQVdd1sT2h8=.600c64b2-1ee9-419a-a28a-5b92ed8f45d7@github.com>
Message-ID: <1U7F11Wws94lb4nQ5ZNQWKzgsLatO7YN5s5rcoJlCEI=.9520098d-c3cd-4075-8cb3-f8439ba5a5f2@github.com>

On Sat, 22 Apr 2023 00:21:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Cleaned up and stabilized four Dialog-related tests.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added couple of empty lines to make code nore readable.

test/jdk/java/awt/Dialog/DialogLocationTest.java line 175:

> 173:             test.start();
> 174:         } finally {
> 175:             EventQueue.invokeLater(() -> {

invokeLater may not be executed before the test stops by the jtreg, EDT could be killed at that point. It is better to use invokeAndWait or somehow make sure it will ends.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1175658476


From aivanov at openjdk.org  Mon Apr 24 18:46:11 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 18:46:11 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <9W_vad0YRz-C8xT3Lxa42JnTfxcpxVJxQk_DN9OU4zE=.da0d10bc-c9ac-4565-8787-9e1979db050c@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>
 <9W_vad0YRz-C8xT3Lxa42JnTfxcpxVJxQk_DN9OU4zE=.da0d10bc-c9ac-4565-8787-9e1979db050c@github.com>
Message-ID: <9dkW-9Lw2wrtIU7T6CuJ8moJXYDhhiJM5xO8aIpEBK8=.c3e857fa-9598-4493-835f-a6e6563ef959@github.com>

On Mon, 24 Apr 2023 18:36:56 GMT, Tejesh R <tr at openjdk.org> wrote:

> I preferred asynchronous EDT would be better since its finally block. Is there any particular reason that we should use `invokeAndWait` than `invokeLater`?

You want to **wait** until the frame is disposed of before exiting the main thread otherwise it doesn't make sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175660257


From serb at openjdk.org  Mon Apr 24 18:46:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 18:46:11 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests
In-Reply-To: <0hRcDArZsGBa1jU9tvkvnV9oOVwy20c_L2MBQgyEfcg=.432bc089-5383-4890-ac7a-11cc7b060707@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
 <-jTc5CWi68FEjwEwPtulQm_8ukF7lE-vPk8L5cl3SYo=.0bb45c43-2b37-4e77-aead-2538eb9c7a14@github.com>
 <0hRcDArZsGBa1jU9tvkvnV9oOVwy20c_L2MBQgyEfcg=.432bc089-5383-4890-ac7a-11cc7b060707@github.com>
Message-ID: <AOJA8Q9EsYlyULPRLUl3NeoY4Gqy16bpTX2D4QX-r2M=.3671762d-7b4c-4a5b-9151-5a5f3a012613@github.com>

On Mon, 24 Apr 2023 03:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/Graphics/GetGraphicsTest.java line 35:
>> 
>>> 33: import java.awt.Graphics;
>>> 34: 
>>> 35: public class GetGraphicsTest {
>> 
>> What this test is expected to test? the getBackground/getForeground/getFont seems to be all unused.
>
> As the test summary mentioned, it supposed to "Check getGraphics doesn't throw NullPointerExcepton for invalid colors and font"...the closed test was also like it...was applet based which is just converted to use BufferedImage.getGraphics to be a headless test..
> Seems [4746122](https://bugs.openjdk.org/browse/JDK-4746122):Failed to load applet fix is about applet,
> Once comment in the bug says 
> 
> The problem is applet overrides Component.getBackground()/getForeground() to
> return null. So SunGraphics2D is created with null params
> 
> 
>  so I guess this test is redundant now and we can remove..please suggest..

Probably we may try to extend the Frame by the GetGraphicsTest, and then get a graphics from it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1175660660


From aivanov at openjdk.org  Mon Apr 24 18:54:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 18:54:50 GMT
Subject: RFR: 8306575: Clean up and open source four Dialog related tests
 [v2]
In-Reply-To: <1U7F11Wws94lb4nQ5ZNQWKzgsLatO7YN5s5rcoJlCEI=.9520098d-c3cd-4075-8cb3-f8439ba5a5f2@github.com>
References: <HilvYShvW5d3TAmI4gUnPjnDtvD81ABr95n2Cvp3Xck=.8f4815b3-dd39-4b95-84b1-3e71b7266640@github.com>
 <mR8FT20hD3sE0IgqaYKDH3EoIB9YnRBJkQVdd1sT2h8=.600c64b2-1ee9-419a-a28a-5b92ed8f45d7@github.com>
 <1U7F11Wws94lb4nQ5ZNQWKzgsLatO7YN5s5rcoJlCEI=.9520098d-c3cd-4075-8cb3-f8439ba5a5f2@github.com>
Message-ID: <fmut3ZSZXaZC74lUhU6xUXqerGCrU5irl1DVly_BstI=.b8e858af-a46e-427a-9b12-09e4b60c107a@github.com>

On Mon, 24 Apr 2023 18:41:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> invokeLater may not be executed before the test stops by the jtreg, EDT could be killed at that point. It is better to use invokeAndWait or somehow make sure it will ends.

Totally agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13592#discussion_r1175667904


From aivanov at openjdk.org  Mon Apr 24 18:56:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 18:56:14 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <_LDUykyiPrvqF5jYDvsOmMMOKHKxaMMHprpmef09Zmw=.a9b1a170-d8dc-439d-8980-ebdd38ffdfb9@github.com>

On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT ScrollPane related tests.

I thought the preferred layout for tests is to use a flat layout without creating *additional folder* for each test.

So, `test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java` should be under `ScrollPane`: `test/jdk/java/awt/ScrollPane/ComponentScrollTest.java`.

Similarly, `test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java` goes to `test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java`.

The test `test/jdk/java/awt/ScrollPane/RemoveChild` consists of two .java source files. Can the Semaphore class be moved into `ScrollPaneRemoveAdd.java` as a static nested class?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1398613298


From prr at openjdk.org  Mon Apr 24 18:56:15 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 18:56:15 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <OpcaLSkrmBePTd7K5Sg4w7AVrxMAvRGQ4QAiXxmBeLI=.6d6d93eb-afdc-4967-86a5-23252cf0791c@github.com>

On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT ScrollPane related tests.

> I thought the preferred layout for tests is to use a flat layout without creating _additional folder_ for each test.
> 
> So, `test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java` should be under `ScrollPane`: `test/jdk/java/awt/ScrollPane/ComponentScrollTest.java`.
> 
> Similarly, `test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java` goes to `test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java`.
> 
> The test `test/jdk/java/awt/ScrollPane/RemoveChild` consists of two .java source files. Can the Semaphore class be moved into `ScrollPaneRemoveAdd.java` as a static nested class?

Yes, remove these redundant components where the test consists of just one file.

jtreg creates a separate WD anyway and the longer the path length the more likely we'll run into problems on windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13621#issuecomment-1520664771


From prr at openjdk.org  Mon Apr 24 18:56:16 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 18:56:16 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <9dkW-9Lw2wrtIU7T6CuJ8moJXYDhhiJM5xO8aIpEBK8=.c3e857fa-9598-4493-835f-a6e6563ef959@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>
 <9W_vad0YRz-C8xT3Lxa42JnTfxcpxVJxQk_DN9OU4zE=.da0d10bc-c9ac-4565-8787-9e1979db050c@github.com>
 <9dkW-9Lw2wrtIU7T6CuJ8moJXYDhhiJM5xO8aIpEBK8=.c3e857fa-9598-4493-835f-a6e6563ef959@github.com>
Message-ID: <V5rzeNcHinAKfTBAS14ndRnG_iav5NE778uiP3Ds4Bs=.7f0f18bc-c5a4-4e02-b992-6ae160fa0beb@github.com>

On Mon, 24 Apr 2023 18:43:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I preferred asynchronous EDT would be better since its finally block. Is there any particular reason that we should use `invokeAndWait` than `invokeLater`?
>
>> I preferred asynchronous EDT would be better since its finally block. Is there any particular reason that we should use `invokeAndWait` than `invokeLater`?
> 
> You want to **wait** until the frame is disposed of before exiting the main thread otherwise it doesn't make sense.

yes, I just noticed this in a different proposed change and I agree wait makes more sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175668212


From acobbs at openjdk.org  Mon Apr 24 19:25:59 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Apr 2023 19:25:59 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v7]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Jam lines into 80 columns.
 - Add more scenarios to the regression test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/8c129960..e6a2ecba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=05-06

  Stats: 140 lines in 1 file changed: 118 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544

PR: https://git.openjdk.org/jdk/pull/13544


From acobbs at openjdk.org  Mon Apr 24 19:26:03 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Apr 2023 19:26:03 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v6]
In-Reply-To: <L6EcLKxoTp9Tgk--44Wqirxa9XashROXSA3ARmx67Ik=.089e165f-ca6e-49a0-80f5-618d4518d60d@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <yTdf43aquLcoGy1vjTgPZrCBMtKMsAgjwr-dqqeCjtc=.38735894-3601-4abf-bc26-c0d35de43078@github.com>
 <L6EcLKxoTp9Tgk--44Wqirxa9XashROXSA3ARmx67Ik=.089e165f-ca6e-49a0-80f5-618d4518d60d@github.com>
Message-ID: <n8zNu-PkO38jIHjIiNWJWdPj205UIWi8BvgEt7SeLR8=.02560720-c4b9-410c-b195-fd1689e38231@github.com>

On Mon, 24 Apr 2023 18:14:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add braces around if clause.
>
> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 34:
> 
>> 32: import java.util.HashSet;
>> 33: 
>> 34: public class DefaultMethodBeanPropertyTest {
> 
> Can we please add two additional tests to verify the "diamond" case:
>  - getFoo is in the top interfaceA, two empty subinterfaces B anc C , and one class D of B and C, will the D have one correct prop Foo?
> - getFoo is in the top interfaceA, two non-empty subinterfaces B and C and each override getFoo by the different return types, and then one class D of B and C which override getFoo again by compatible type from B and C, will the D have one correct prop Foo?
> 
> We also can test the case if the D from the cases above is interface and implemented by the class E.

Sure thing... see 6b43627f5f0.

> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 78:
> 
>> 76: 
>> 77:         // Expected properties
>> 78:         final HashSet<PropertyDescriptor> expected = new HashSet<>();
> 
> please split the long lines to use 80 chars per line.

Fixed in e6a2ecba589.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175690195
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1175693481


From aivanov at openjdk.org  Mon Apr 24 19:28:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Apr 2023 19:28:10 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>

On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT ScrollPane related tests.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 84:

> 82:                     pane.remove(0);
> 83:                     pane.add(button);
> 84:             });

Indentation is incorrect: the body of lambda expression should be indented by four spaces less.

test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 88:

> 86:             Point buttonLoc = button.getLocationOnScreen();
> 87:             Dimension buttonSize = button.getSize();
> 88:             robot.mouseMove(buttonLoc.x + buttonSize.width / 2, buttonLoc.y + buttonSize.height / 2);

Suggestion:

            robot.mouseMove(buttonLoc.x + buttonSize.width / 2,
                            buttonLoc.y + buttonSize.height / 2);

Without wrapping, the line seems too long. I haven't checked how long it is.

test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 94:

> 92:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 93: 
> 94:             Toolkit.getDefaultToolkit().sync();

Shouldn't `sync` be replaced with `Robot.waitForIdle`?

test/jdk/java/awt/ScrollPane/RemoveChild/Semaphore.java line 1:

> 1: public class Semaphore {

If it's left as an external file, it requires its own copyright header. I suggest moving it into `ScrollPaneRemoveAdd.java` as static nested class and then drop `RemoveChild` directory.

Please add a blank line between methods.

test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 27:

> 25:   @test
> 26:   @bug 4152524
> 27:   @summary Test that scroll pane doesn't have scroll bars visible when it is shown for the first time with SCROLLBARS_AS_NEEDED style

Wrap long lines so that they fit into 80-column limit or, at the very least, into 100-column limit.

test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 42:

> 40: 
> 41: public class ScrollPaneExtraScrollBar
> 42: {

Suggestion:

public class ScrollPaneExtraScrollBar {

The opening brace should be on the previous line.

test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 54:

> 52:     public void init() throws Exception {
> 53: 
> 54:        robot = new Robot();

Suggestion:

    }

   public void init() throws Exception {
        robot = new Robot();

A blank line between methods is missing.  
The method starts with an unnecessary blank line.  
The first statement is not indented by four spaces (but only by three).

test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 64:

> 62:                 f.setLocationRelativeTo(null);
> 63:                 f.setVisible(true);
> 64:         });

The lambda expression should be indented by four spaces less.

test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 69:

> 67:     public void start() throws Exception {
> 68:         try {
> 69:             if (System.getProperty("os.name").startsWith("Windows")) {

Should we use [`OSInfo` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/OSInfo.java)?

It's used in [`bug4847375.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/4847375 /bug4847375.java), [`bug6550546.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/6550546/bug6550546.java) and others.

The `@requires` tag should be added to the test tags so that it's not selected for other platforms.

To avoid extensive indentation, reverse the condition in the `if` statement and return early.

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 83:

> 81:                     (os.indexOf("98") == -1) &&
> 82:                     (os.startsWith("Win") || os.startsWith("win") ||
> 83:                             os.startsWith("WIN"))) {

Should use `OSInfo`?

`@requires` tag should be added to the test so that it's not selected for other platforms.

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 113:

> 111:                     } catch (InterruptedException e) {
> 112:                         throw new RuntimeException("test was interrupted");
> 113:                     }

Suggestion:

                    robot.delay(1000);

Much cleaner, isn't it?

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 169:

> 167:     }
> 168: 
> 169:     class MyPanel extends Component {

Can be made `static`.
Suggestion:

    private static class MyPanel extends Component {

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest/ScrollPaneWindowsTest.java line 91:

> 89:             System.out.println("This test is for Windows 2000/2003/XP only.");
> 90:             return;
> 91:         }

Again, use `OSInfo` or better `@requires` tag.

test/jdk/java/awt/ScrollPane/ScrollPositionIntact/ScrollPositionIntact.java line 77:

> 75:                 } catch (Exception ex) {
> 76:                     throw new RuntimeException("Test failure: interruption?\n\n");
> 77:                 }

It doesn't make sense: you're blocking EDT. It's probably meant to be run on main thread to allow EDT to process events and display the frame.

test/jdk/java/awt/ScrollPane/ScrollPositionIntact/ScrollPositionIntact.java line 97:

> 95:                     }
> 96:                 }
> 97:             });

Why is it `invokeLater`? After you submitted a code to be run on EDT, you exit the test.

In other places in this test, you use lambda expressions instead of anonymous classes, why not here? I think it's better to be consistent and use either lambda or anonymous classes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1398620929
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175673089
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175673980
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175674660
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175675939
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175690233
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175677434
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175680065
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175680662
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175685964
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175687475
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175692384
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175693400
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175694722
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175696461
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175671146


From serb at openjdk.org  Mon Apr 24 21:00:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 21:00:14 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v7]
In-Reply-To: <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>
Message-ID: <MP-TpCCDhPOY0ZkLv8lFCcfhBxHuo2mbIW_oKGkwiog=.8a305220-d5f9-41f8-81c7-5b538c49395c@github.com>

On Mon, 24 Apr 2023 19:25:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Jam lines into 80 columns.
>  - Add more scenarios to the regression test.

Looks fine.

-------------

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1398781100


From serb at openjdk.org  Mon Apr 24 21:31:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Apr 2023 21:31:11 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v5]
In-Reply-To: <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
Message-ID: <A7LfEzl0bJILIypub4HiULjM77uZ-UuhFkHm7nIPaMY=.bbff4602-45ad-4bfa-b907-5d73201de1ad@github.com>

On Mon, 24 Apr 2023 16:40:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> This open source AWT Mouse Info related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Looks fine, please confirm that mach5 is green.

-------------

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13573#pullrequestreview-1398832587


From prr at openjdk.org  Mon Apr 24 21:48:04 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 21:48:04 GMT
Subject: RFR: 8306765: Some client related jtreg problem list entries are
 malformed
Message-ID: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>

There were missing platforms in a couple of problem list entries.
I verified the intended platforms are still needed and the other platforms pass.

-------------

Commit messages:
 - 8306765

Changes: https://git.openjdk.org/jdk/pull/13626/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306765
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13626/head:pull/13626

PR: https://git.openjdk.org/jdk/pull/13626


From prr at openjdk.org  Mon Apr 24 22:03:07 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Apr 2023 22:03:07 GMT
Subject: RFR: 8306714: Open source few Swing event and AbstractAction tests
In-Reply-To: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
References: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
Message-ID: <uMB5Ft0AxxwkN1LptIvYYZ89ObK1nRrCN3eXriSA_nc=.21468c43-2170-46aa-a8ba-c5b5035b119a@github.com>

On Mon, 24 Apr 2023 09:51:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few Swing event and AbstractAction tests

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13608#pullrequestreview-1398862928


From iris at openjdk.org  Tue Apr 25 01:54:09 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 25 Apr 2023 01:54:09 GMT
Subject: RFR: 8306765: Some client related jtreg problem list entries are
 malformed
In-Reply-To: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
References: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
Message-ID: <ZYxwfKPTl6FhTVtP_pSoEyxPLGV_hT9PW_3lUJDMAYE=.452afe69-b5fa-4414-9a5b-7a5e2efe6412@github.com>

On Mon, 24 Apr 2023 19:20:54 GMT, Phil Race <prr at openjdk.org> wrote:

> There were missing platforms in a couple of problem list entries.
> I verified the intended platforms are still needed and the other platforms pass.

Marked as reviewed by iris (Reviewer).

test/jdk/ProblemList.txt line 444:

> 442: java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java 8238720 windows-all
> 443: java/awt/GridLayout/ChangeGridSize/ChangeGridSize.java   8238720 windows-all
> 444: java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.java windows-all

bugid?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13626#pullrequestreview-1399011728
PR Review Comment: https://git.openjdk.org/jdk/pull/13626#discussion_r1175934467


From prr at openjdk.org  Tue Apr 25 02:48:22 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 02:48:22 GMT
Subject: Integrated: 8306484: Open source several AWT Choice jtreg tests
In-Reply-To: <pUW4t0HRVjP-408o8mNllpKH_RjKy_QGHdTMooXpyBg=.0bb4dbd1-dc5f-477b-b013-2e32f9284c49@github.com>
References: <pUW4t0HRVjP-408o8mNllpKH_RjKy_QGHdTMooXpyBg=.0bb4dbd1-dc5f-477b-b013-2e32f9284c49@github.com>
Message-ID: <SB_jrO5FtdG5xyo-YSCVxAWB5Kfp2iedEKrXATTasis=.ebb1beb5-54ae-4605-b078-66e4e51eeb2a@github.com>

On Mon, 24 Apr 2023 17:25:31 GMT, Phil Race <prr at openjdk.org> wrote:

> Open sourcing several AWT Choice regression tests

This pull request has now been integrated.

Changeset: b5362dad
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5362dadc59570d1f7fd7899be5ec11187168a16
Stats:     1048 lines in 6 files changed: 1048 ins; 0 del; 0 mod

8306484: Open source several AWT Choice jtreg tests

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13620


From prr at openjdk.org  Tue Apr 25 02:49:21 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 02:49:21 GMT
Subject: Integrated: 8306682: Open source a few more AWT Choice tests
In-Reply-To: <kSR6kiYMZC38OaksCPwdRYXAlQUBRjemHgY1cAmvagg=.c874970f-4fb9-4169-baeb-050fdff3b244@github.com>
References: <kSR6kiYMZC38OaksCPwdRYXAlQUBRjemHgY1cAmvagg=.c874970f-4fb9-4169-baeb-050fdff3b244@github.com>
Message-ID: <Og5JAovaTctzGO9AE9e0rPCHCIWRmr1a5IF_GY5QSzw=.97094541-8b67-4ae8-97cc-a6ef2d9605fa@github.com>

On Mon, 24 Apr 2023 17:39:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source a few more AWT Choice tests

This pull request has now been integrated.

Changeset: f39641cc
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f39641ccbd670853b3c021dd4e490151cbc77ed6
Stats:     535 lines in 4 files changed: 535 ins; 0 del; 0 mod

8306682: Open source a few more AWT Choice tests

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13622


From prr at openjdk.org  Tue Apr 25 02:50:11 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 02:50:11 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
Message-ID: <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>

On Mon, 24 Apr 2023 19:22:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest/ScrollPaneWindowsTest.java line 91:
> 
>> 89:             System.out.println("This test is for Windows 2000/2003/XP only.");
>> 90:             return;
>> 91:         }
> 
> Again, use `OSInfo` or better `@requires` tag.

The whole comment needs reworking and thinking about.
Is it trying to say this test is obsolete after XP ?
In which case since even the successors of Visa, WIndows 7, 8 and 8.1 are all dead
the comment is really really unwelcome in 2023. And perhaps the test is too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1175958311


From tr at openjdk.org  Tue Apr 25 04:59:08 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 04:59:08 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <V5rzeNcHinAKfTBAS14ndRnG_iav5NE778uiP3Ds4Bs=.7f0f18bc-c5a4-4e02-b992-6ae160fa0beb@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <aQ90QIjThLLlUl3dqjqZCsB1kH7fuWl9KE9E6aAS2j0=.cc4ceafd-2a82-42e9-aad2-67881a4e3a82@github.com>
 <9W_vad0YRz-C8xT3Lxa42JnTfxcpxVJxQk_DN9OU4zE=.da0d10bc-c9ac-4565-8787-9e1979db050c@github.com>
 <9dkW-9Lw2wrtIU7T6CuJ8moJXYDhhiJM5xO8aIpEBK8=.c3e857fa-9598-4493-835f-a6e6563ef959@github.com>
 <V5rzeNcHinAKfTBAS14ndRnG_iav5NE778uiP3Ds4Bs=.7f0f18bc-c5a4-4e02-b992-6ae160fa0beb@github.com>
Message-ID: <jTWArnvVqaDAdJIwK-0hL0GSqzD2hWRkrfkNPdbWeMs=.94633baa-076b-49c1-bfcd-0cc7df449507@github.com>

On Mon, 24 Apr 2023 18:52:17 GMT, Phil Race <prr at openjdk.org> wrote:

>>> I preferred asynchronous EDT would be better since its finally block. Is there any particular reason that we should use `invokeAndWait` than `invokeLater`?
>> 
>> You want to **wait** until the frame is disposed of before exiting the main thread otherwise it doesn't make sense.
>
> yes, I just noticed this in a different proposed change and I agree wait makes more sense.

Ok, didn't think in that sense, I'll better use invokeAndWait.....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176005897


From psadhukhan at openjdk.org  Tue Apr 25 05:00:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 05:00:24 GMT
Subject: Integrated: 8306714: Open source few Swing event and AbstractAction
 tests
In-Reply-To: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
References: <9C7JgG_Hj_U4QNIT9vlfnDSyIRmW68mriVl-Ol5Np44=.43f1ce0b-2808-45f8-96c5-e4eefc5c1873@github.com>
Message-ID: <5LjzBaId3aTDUpr_PTOeTlr8N3DbAPToHilKVVnyLdE=.b817355b-c78d-4a0a-8e0c-b4caaad5c647@github.com>

On Mon, 24 Apr 2023 09:51:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few Swing event and AbstractAction tests

This pull request has now been integrated.

Changeset: 31a73b0d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31a73b0d7088d10a5ffb5541d66806a92b681ef9
Stats:     329 lines in 6 files changed: 329 ins; 0 del; 0 mod

8306714: Open source few Swing event and AbstractAction tests

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13608


From psadhukhan at openjdk.org  Tue Apr 25 05:13:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 05:13:19 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests [v2]
In-Reply-To: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
Message-ID: <qHcneKdVpkfw6ecyPAmMOXXDYqvedL_Nu_XIxLg75Oo=.f891ae72-cdc0-40f1-b0a7-259d01c3bd08@github.com>

> This opensources few AWT Graphics & GridBagLayout tests

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  GetGraphics fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13570/files
  - new: https://git.openjdk.org/jdk/pull/13570/files/7480e3df..a54c1db9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13570&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13570&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13570/head:pull/13570

PR: https://git.openjdk.org/jdk/pull/13570


From tr at openjdk.org  Tue Apr 25 05:24:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 05:24:17 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
Message-ID: <xzr_Kf8RSrqQfU-NpeFKRfsV0SrDZDWcGd_EzsXHvms=.aa7b0233-b2c4-4679-b220-5d771dfe3ac3@github.com>

On Mon, 24 Apr 2023 18:59:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 94:
> 
>> 92:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 93: 
>> 94:             Toolkit.getDefaultToolkit().sync();
> 
> Shouldn't `sync` be replaced with `Robot.waitForIdle`?

Not sure y both has been used here, will remove sync and test in CI, if its fine there then can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176017290


From psadhukhan at openjdk.org  Tue Apr 25 05:27:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 05:27:07 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests [v2]
In-Reply-To: <AOJA8Q9EsYlyULPRLUl3NeoY4Gqy16bpTX2D4QX-r2M=.3671762d-7b4c-4a5b-9151-5a5f3a012613@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
 <-jTc5CWi68FEjwEwPtulQm_8ukF7lE-vPk8L5cl3SYo=.0bb45c43-2b37-4e77-aead-2538eb9c7a14@github.com>
 <0hRcDArZsGBa1jU9tvkvnV9oOVwy20c_L2MBQgyEfcg=.432bc089-5383-4890-ac7a-11cc7b060707@github.com>
 <AOJA8Q9EsYlyULPRLUl3NeoY4Gqy16bpTX2D4QX-r2M=.3671762d-7b4c-4a5b-9151-5a5f3a012613@github.com>
Message-ID: <rqdVRQksSeYlzU79swSaN-neRJMPIxS5Ptcc5yAN0b0=.c809dc25-7c0f-4342-9522-f624aa2b0499@github.com>

On Mon, 24 Apr 2023 18:43:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As the test summary mentioned, it supposed to "Check getGraphics doesn't throw NullPointerExcepton for invalid colors and font"...the closed test was also like it...was applet based which is just converted to use BufferedImage.getGraphics to be a headless test..
>> Seems [4746122](https://bugs.openjdk.org/browse/JDK-4746122):Failed to load applet fix is about applet,
>> Once comment in the bug says 
>> 
>> The problem is applet overrides Component.getBackground()/getForeground() to
>> return null. So SunGraphics2D is created with null params
>> 
>> 
>>  so I guess this test is redundant now and we can remove..please suggest..
>
> Probably we may try to extend the Frame by the GetGraphicsTest, and then get a graphics from it?

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13570#discussion_r1176018786


From psadhukhan at openjdk.org  Tue Apr 25 05:36:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 05:36:12 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests [v3]
In-Reply-To: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
Message-ID: <bJxsKRxqEsI8ClDPZ6I9i43CKqzqxyRU8nlrPEwFdb8=.daaecd83-74b8-4707-83f5-3aec11dba03e@github.com>

> This opensources few AWT Graphics & GridBagLayout tests

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  space fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13570/files
  - new: https://git.openjdk.org/jdk/pull/13570/files/a54c1db9..8c4a1828

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13570&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13570&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13570/head:pull/13570

PR: https://git.openjdk.org/jdk/pull/13570


From tr at openjdk.org  Tue Apr 25 05:51:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 05:51:17 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
Message-ID: <C9b2c1iSl77mAXtloX22e4aW0y1xLN-6Qqn5ZhKZWY8=.a2493847-9191-4b7d-95ac-3e50dc2fd7f8@github.com>

On Mon, 24 Apr 2023 18:57:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 84:
> 
>> 82:                     pane.remove(0);
>> 83:                     pane.add(button);
>> 84:             });
> 
> Indentation is incorrect: the body of lambda expression should be indented by four spaces less.

Updated.

> test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 88:
> 
>> 86:             Point buttonLoc = button.getLocationOnScreen();
>> 87:             Dimension buttonSize = button.getSize();
>> 88:             robot.mouseMove(buttonLoc.x + buttonSize.width / 2, buttonLoc.y + buttonSize.height / 2);
> 
> Suggestion:
> 
>             robot.mouseMove(buttonLoc.x + buttonSize.width / 2,
>                             buttonLoc.y + buttonSize.height / 2);
> 
> Without wrapping, the line seems too long. I haven't checked how long it is.

Updated.

> test/jdk/java/awt/ScrollPane/RemoveChild/Semaphore.java line 1:
> 
>> 1: public class Semaphore {
> 
> If it's left as an external file, it requires its own copyright header. I suggest moving it into `ScrollPaneRemoveAdd.java` as static nested class and then drop `RemoveChild` directory.
> 
> Please add a blank line between methods.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 42:
> 
>> 40: 
>> 41: public class ScrollPaneExtraScrollBar
>> 42: {
> 
> Suggestion:
> 
> public class ScrollPaneExtraScrollBar {
> 
> The opening brace should be on the previous line.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 54:
> 
>> 52:     public void init() throws Exception {
>> 53: 
>> 54:        robot = new Robot();
> 
> Suggestion:
> 
>     }
> 
>    public void init() throws Exception {
>         robot = new Robot();
> 
> A blank line between methods is missing.  
> The method starts with an unnecessary blank line.  
> The first statement is not indented by four spaces (but only by three).

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 64:
> 
>> 62:                 f.setLocationRelativeTo(null);
>> 63:                 f.setVisible(true);
>> 64:         });
> 
> The lambda expression should be indented by four spaces less.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java line 69:
> 
>> 67:     public void start() throws Exception {
>> 68:         try {
>> 69:             if (System.getProperty("os.name").startsWith("Windows")) {
> 
> Should we use [`OSInfo` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/OSInfo.java)?
> 
> It's used in [`bug4847375.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/4847375 /bug4847375.java), [`bug6550546.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/6550546/bug6550546.java) and others.
> 
> The `@requires` tag should be added to the test tags so that it's not selected for other platforms.
> 
> To avoid extensive indentation, reverse the condition in the `if` statement and return early.

Updated to @requires.

> test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 83:
> 
>> 81:                     (os.indexOf("98") == -1) &&
>> 82:                     (os.startsWith("Win") || os.startsWith("win") ||
>> 83:                             os.startsWith("WIN"))) {
> 
> Should use `OSInfo`?
> 
> `@requires` tag should be added to the test so that it's not selected for other platforms.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 113:
> 
>> 111:                     } catch (InterruptedException e) {
>> 112:                         throw new RuntimeException("test was interrupted");
>> 113:                     }
> 
> Suggestion:
> 
>                     robot.delay(1000);
> 
> Much cleaner, isn't it?

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneLimitation/ScrollPaneLimitation.java line 169:
> 
>> 167:     }
>> 168: 
>> 169:     class MyPanel extends Component {
> 
> Can be made `static`.
> Suggestion:
> 
>     private static class MyPanel extends Component {

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPositionIntact/ScrollPositionIntact.java line 77:
> 
>> 75:                 } catch (Exception ex) {
>> 76:                     throw new RuntimeException("Test failure: interruption?\n\n");
>> 77:                 }
> 
> It doesn't make sense: you're blocking EDT. It's probably meant to be run on main thread to allow EDT to process events and display the frame.

Yeah, I've added robot delay in-between EDT.

> test/jdk/java/awt/ScrollPane/ScrollPositionIntact/ScrollPositionIntact.java line 97:
> 
>> 95:                     }
>> 96:                 }
>> 97:             });
> 
> Why is it `invokeLater`? After you submitted a code to be run on EDT, you exit the test.
> 
> In other places in this test, you use lambda expressions instead of anonymous classes, why not here? I think it's better to be consistent and use either lambda or anonymous classes.

Updated to `invokeAndWait`() with lambda expressions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031414
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031323
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031181
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031107
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031069
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031009
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176029967
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176029791
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176029424
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176029342
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176028312
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176031802


From tr at openjdk.org  Tue Apr 25 05:51:20 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 05:51:20 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <xzr_Kf8RSrqQfU-NpeFKRfsV0SrDZDWcGd_EzsXHvms=.aa7b0233-b2c4-4679-b220-5d771dfe3ac3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <xzr_Kf8RSrqQfU-NpeFKRfsV0SrDZDWcGd_EzsXHvms=.aa7b0233-b2c4-4679-b220-5d771dfe3ac3@github.com>
Message-ID: <lEkcHCqeXPnSlU4LPG75UlQpDQ1nejWIfDqFi7zg4Xc=.dfb32f0c-7621-49a8-bf5c-ef53a76c8e01@github.com>

On Tue, 25 Apr 2023 05:21:26 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/ScrollPane/RemoveChild/ScrollPaneRemoveAdd.java line 94:
>> 
>>> 92:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>>> 93: 
>>> 94:             Toolkit.getDefaultToolkit().sync();
>> 
>> Shouldn't `sync` be replaced with `Robot.waitForIdle`?
>
> Not sure y both has been used here, will remove sync and test in CI, if its fine there then can be removed.

> > I thought the preferred layout for tests is to use a flat layout without creating _additional folder_ for each test.
> > So, `test/jdk/java/awt/ScrollPane/ComponentScrollTest/ComponentScrollTest.java` should be under `ScrollPane`: `test/jdk/java/awt/ScrollPane/ComponentScrollTest.java`.
> > Similarly, `test/jdk/java/awt/ScrollPane/ScrollPaneInsets/ScrollPaneExtraScrollBar.java` goes to `test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java`.
> > The test `test/jdk/java/awt/ScrollPane/RemoveChild` consists of two .java source files. Can the Semaphore class be moved into `ScrollPaneRemoveAdd.java` as a static nested class?
> 
> Yes, remove these redundant components where the test consists of just one file.
> 
> jtreg creates a separate WD anyway and the longer the path length the more likely we'll run into problems on windows.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176032017


From tr at openjdk.org  Tue Apr 25 05:51:21 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 05:51:21 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
Message-ID: <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>

On Tue, 25 Apr 2023 02:47:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest/ScrollPaneWindowsTest.java line 91:
>> 
>>> 89:             System.out.println("This test is for Windows 2000/2003/XP only.");
>>> 90:             return;
>>> 91:         }
>> 
>> Again, use `OSInfo` or better `@requires` tag.
>
> The whole comment needs reworking and thinking about.
> Is it trying to say this test is obsolete after XP ?
> In which case since even the successors of Visa, WIndows 7, 8 and 8.1 are all dead
> the comment is really really unwelcome in 2023. And perhaps the test is too.

Ok, then I will not move the test, should it be left as applet or it should be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176029217


From abhiscxk at openjdk.org  Tue Apr 25 06:29:46 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 06:29:46 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v2]
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <wcKiK7VpfNTu5jMl0D_ydXjEjpkhI_b_0n6xRNDwN9s=.a6f0bd30-dad7-4680-9aa0-46e9ab07a772@github.com>

> This PR is to open source MenuItem AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13589/files
  - new: https://git.openjdk.org/jdk/pull/13589/files/798212cc..39381161

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13589/head:pull/13589

PR: https://git.openjdk.org/jdk/pull/13589


From abhiscxk at openjdk.org  Tue Apr 25 06:29:46 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 06:29:46 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v2]
In-Reply-To: <-ax6p6tWRHpenDT9y-502GDFh0M-FdK8lhHZwwf45BE=.fd778c64-aa01-4e1f-9d67-3df727283e16@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <-ax6p6tWRHpenDT9y-502GDFh0M-FdK8lhHZwwf45BE=.fd778c64-aa01-4e1f-9d67-3df727283e16@github.com>
Message-ID: <oHMM3Y-zAWrzKz5dV2Z15l1eg4MglpLYQZ7Yl3IkpFY=.c8905ff9-6258-41c1-9adc-c7d6909d3aba@github.com>

On Fri, 21 Apr 2023 21:08:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 29:
> 
>> 27:   @summary Menu display problem when changing the text of the menu(window 98)
>> 28:   @key headful
>> 29:   @run main/timeout=600 MenuSetLabelTest
> 
> Why the timeout is so big?

I have kept it as it was in the test before conversion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176053747


From dcherepanov at openjdk.org  Tue Apr 25 06:57:18 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 25 Apr 2023 06:57:18 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
Message-ID: <AMFK_uZYCd13AbbBHcsQPC69AfjiiGJchyMs3-7Krxc=.39fbaab8-498e-4632-ace3-34a94d75a729@github.com>

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1521244605


From dcherepanov at openjdk.org  Tue Apr 25 07:00:25 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 25 Apr 2023 07:00:25 GMT
Subject: Integrated: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
References: <etMYx04QrV9xU-XLWCu40GsvSapd7EXO_f2I0My1LY8=.61e4c891-efe7-4b7e-8644-edcf76151427@github.com>
Message-ID: <gLCYD1pQy0E-W-810cbqFr3XJYmpiSLp_i29b3aObGg=.7c4a9835-8107-4b70-83d2-7010e6abdb86@github.com>

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

This pull request has now been integrated.

Changeset: f968da97
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f968da97a5a5c68c28ad29d13fdfbe3a4adf5ef7
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8305352: updateIconImages may lead to deadlock after JDK-8276849

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13263


From abhiscxk at openjdk.org  Tue Apr 25 07:16:37 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 07:16:37 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests
Message-ID: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>

This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.

-------------

Commit messages:
 - Open source KFM, LWC and few other AWT tests

Changes: https://git.openjdk.org/jdk/pull/13633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306409
  Stats: 611 lines in 6 files changed: 611 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13633/head:pull/13633

PR: https://git.openjdk.org/jdk/pull/13633


From serb at openjdk.org  Tue Apr 25 08:30:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 08:30:10 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests
In-Reply-To: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
Message-ID: <mOX2NM8TUzdgWEcDVLS6yab7gvf5vqTKnLzRU3gb1Wc=.f293e98f-48b6-48ba-a1e1-4eb6d47b31bd@github.com>

On Tue, 25 Apr 2023 07:07:41 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.

test/jdk/java/awt/Layout/InsetsTest.java line 43:

> 41: 
> 42: public class InsetsTest {
> 43:         private int leftInsetValue;

This test uses some strange formatting.

test/jdk/java/awt/LightweightComponent/LightweightDragTest.java line 52:

> 50:     int y = 0;
> 51:     int x2 = 0;
> 52:     int y2 = 0;

Do we need to mark all this as volatile?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1176178973
PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1176181456


From serb at openjdk.org  Tue Apr 25 08:34:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 08:34:10 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
 <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>
Message-ID: <OoILiqqyrrZxpmAUXtxXc4TDjYl5N9rooW9-66ag6VI=.fbb60db9-152d-46a1-80ad-09e7dd597246@github.com>

On Tue, 25 Apr 2023 05:43:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The whole comment needs reworking and thinking about.
>> Is it trying to say this test is obsolete after XP ?
>> In which case since even the successors of Visa, WIndows 7, 8 and 8.1 are all dead
>> the comment is really really unwelcome in 2023. And perhaps the test is too.
>
> Ok, then I will not move the test, should it be left as applet or it should be removed?

probably the idea was to exclude "win 98/etc"? please check for what bug this test was created and if is it applicable for win10 or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176186063


From serb at openjdk.org  Tue Apr 25 08:39:13 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 08:39:13 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v2]
In-Reply-To: <oHMM3Y-zAWrzKz5dV2Z15l1eg4MglpLYQZ7Yl3IkpFY=.c8905ff9-6258-41c1-9adc-c7d6909d3aba@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <-ax6p6tWRHpenDT9y-502GDFh0M-FdK8lhHZwwf45BE=.fd778c64-aa01-4e1f-9d67-3df727283e16@github.com>
 <oHMM3Y-zAWrzKz5dV2Z15l1eg4MglpLYQZ7Yl3IkpFY=.c8905ff9-6258-41c1-9adc-c7d6909d3aba@github.com>
Message-ID: <fPCjlQQFx0VZGZM-sPLhInzPeo0ZgghWkw48zwgK4lA=.79f1c671-761e-48fa-95ce-c43e5ce844b8@github.com>

On Tue, 25 Apr 2023 06:21:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 29:
>> 
>>> 27:   @summary Menu display problem when changing the text of the menu(window 98)
>>> 28:   @key headful
>>> 29:   @run main/timeout=600 MenuSetLabelTest
>> 
>> Why the timeout is so big?
>
> I have kept it as it was in the test before conversion.

Default timeout should work fine here, otherwise, we have a bug somewhere in this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176192277


From serb at openjdk.org  Tue Apr 25 08:41:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 08:41:12 GMT
Subject: RFR: 8306067: Open source AWT Graphics,
 GridBagLayout related tests [v3]
In-Reply-To: <bJxsKRxqEsI8ClDPZ6I9i43CKqzqxyRU8nlrPEwFdb8=.daaecd83-74b8-4707-83f5-3aec11dba03e@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
 <bJxsKRxqEsI8ClDPZ6I9i43CKqzqxyRU8nlrPEwFdb8=.daaecd83-74b8-4707-83f5-3aec11dba03e@github.com>
Message-ID: <VMqVsJeIeqelFjevQqna91XXeRPP9Vl3P4_N7Q-p084=.3131cea7-7674-40bd-8501-24f9e46d9405@github.com>

On Tue, 25 Apr 2023 05:36:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This opensources few AWT Graphics & GridBagLayout tests
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space fix

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13570#pullrequestreview-1399416562


From psadhukhan at openjdk.org  Tue Apr 25 08:58:25 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 08:58:25 GMT
Subject: Integrated: 8306067: Open source AWT Graphics,GridBagLayout related
 tests
In-Reply-To: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
References: <P9FjN0bZYyUJyknmQJp_gCJFKy-vODvHpjpVv2NSOe4=.ef0733b1-de34-43e0-93b9-31a88ff4b120@github.com>
Message-ID: <Vza4roQOQ8KNYE-9YreLyQLEe59kfsHZiZc4Xyi2PHk=.a0e70095-f444-478e-9ac3-9b38ec07f772@github.com>

On Fri, 21 Apr 2023 04:00:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few AWT Graphics & GridBagLayout tests

This pull request has now been integrated.

Changeset: d53a5eed
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d53a5eed0f64d97e1f688ed4cde006ae2a676231
Stats:     299 lines in 4 files changed: 299 ins; 0 del; 0 mod

8306067: Open source AWT Graphics,GridBagLayout related tests

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13570


From abhiscxk at openjdk.org  Tue Apr 25 09:16:20 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 09:16:20 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v3]
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <wDfkMBRCT8cm0y7CgDaDRFwew9JDv3XJja1GsRCLIN8=.0820404e-4753-443f-abba-9fd2a69a219e@github.com>

> This PR is to open source MenuItem AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Timeout removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13589/files
  - new: https://git.openjdk.org/jdk/pull/13589/files/39381161..7b89b4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13589/head:pull/13589

PR: https://git.openjdk.org/jdk/pull/13589


From abhiscxk at openjdk.org  Tue Apr 25 09:16:21 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 09:16:21 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v3]
In-Reply-To: <fPCjlQQFx0VZGZM-sPLhInzPeo0ZgghWkw48zwgK4lA=.79f1c671-761e-48fa-95ce-c43e5ce844b8@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <-ax6p6tWRHpenDT9y-502GDFh0M-FdK8lhHZwwf45BE=.fd778c64-aa01-4e1f-9d67-3df727283e16@github.com>
 <oHMM3Y-zAWrzKz5dV2Z15l1eg4MglpLYQZ7Yl3IkpFY=.c8905ff9-6258-41c1-9adc-c7d6909d3aba@github.com>
 <fPCjlQQFx0VZGZM-sPLhInzPeo0ZgghWkw48zwgK4lA=.79f1c671-761e-48fa-95ce-c43e5ce844b8@github.com>
Message-ID: <O6k1JAyl86PpHbWPjr9NbweWpLmxKIuPWGv-LC9Gkkk=.23f5db5c-cbec-4627-a6a3-c432e1709cfb@github.com>

On Tue, 25 Apr 2023 08:36:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I have kept it as it was in the test before conversion.
>
> Default timeout should work fine here, otherwise, we have a bug somewhere in this code.

Ok. Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176234453


From abhiscxk at openjdk.org  Tue Apr 25 09:35:27 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 09:35:27 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
Message-ID: <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>

> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13633/files
  - new: https://git.openjdk.org/jdk/pull/13633/files/6296f044..eebe20a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13633&range=00-01

  Stats: 47 lines in 2 files changed: 0 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/13633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13633/head:pull/13633

PR: https://git.openjdk.org/jdk/pull/13633


From abhiscxk at openjdk.org  Tue Apr 25 09:35:28 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 09:35:28 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <mOX2NM8TUzdgWEcDVLS6yab7gvf5vqTKnLzRU3gb1Wc=.f293e98f-48b6-48ba-a1e1-4eb6d47b31bd@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <mOX2NM8TUzdgWEcDVLS6yab7gvf5vqTKnLzRU3gb1Wc=.f293e98f-48b6-48ba-a1e1-4eb6d47b31bd@github.com>
Message-ID: <h3xDOVCaElKy-lt4BtLLOiBL2BH5AAyPJcJB5B6Uvok=.2737d4fc-1863-4cfb-828f-9b129f96f13d@github.com>

On Tue, 25 Apr 2023 08:25:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/java/awt/Layout/InsetsTest.java line 43:
> 
>> 41: 
>> 42: public class InsetsTest {
>> 43:         private int leftInsetValue;
> 
> This test uses some strange formatting.

Fixed.

> test/jdk/java/awt/LightweightComponent/LightweightDragTest.java line 52:
> 
>> 50:     int y = 0;
>> 51:     int x2 = 0;
>> 52:     int y2 = 0;
> 
> Do we need to mark all this as volatile?

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1176256102
PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1176256208


From kizune at openjdk.org  Tue Apr 25 10:45:27 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 25 Apr 2023 10:45:27 GMT
Subject: RFR: 8306718: Optimize and opensource some old AWT tests
Message-ID: <XQ-zbdcfrs9fYI7RbR5wYlStdtsZOky175YtHN28QLk=.7e7205db-4022-42ac-b146-b024ada43001@github.com>

Four tests are cleaned and optimized, ready to open source.

-------------

Commit messages:
 - 8306718: Optimize and opensource some old AWT tests

Changes: https://git.openjdk.org/jdk/pull/13637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306718
  Stats: 410 lines in 4 files changed: 410 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13637/head:pull/13637

PR: https://git.openjdk.org/jdk/pull/13637


From tr at openjdk.org  Tue Apr 25 10:54:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 10:54:10 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
In-Reply-To: <OoILiqqyrrZxpmAUXtxXc4TDjYl5N9rooW9-66ag6VI=.fbb60db9-152d-46a1-80ad-09e7dd597246@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
 <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>
 <OoILiqqyrrZxpmAUXtxXc4TDjYl5N9rooW9-66ag6VI=.fbb60db9-152d-46a1-80ad-09e7dd597246@github.com>
Message-ID: <XihneKHzAQKF5V-GJU6e8eXwIl-jiRBVoLzNk686Ds0=.c28430ea-11fe-49c4-9415-e03cd3f3e89d@github.com>

On Tue, 25 Apr 2023 08:31:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ok, then I will not move the test, should it be left as applet or it should be removed?
>
> probably the idea was to exclude "win 98/etc"? please check for what bug this test was created and if is it applicable for win10 or not.

The bug was raised specifically for Win2000, also states that it is not reproducible for Windows NT 4.0 and Windows 98. I don't think that this test is specific to Win2000, in JBS they mention about a feature being added from Win2000, hence the fix wasn't applicable to previous versions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176343965


From psadhukhan at openjdk.org  Tue Apr 25 12:51:08 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 12:51:08 GMT
Subject: RFR: 8306838: GetGraphicsTest needs to be headful
Message-ID: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>

Newly added GetGraphicsTest should be headful as it uses a Frame


java.awt.HeadlessException:
No X11 DISPLAY variable was set,
or no headful library support was found,
but this program performed an operation which requires it,

at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:166)
at java.desktop/java.awt.Window.<init>(Window.java:553)
at java.desktop/java.awt.Frame.<init>(Frame.java:428)
at java.desktop/java.awt.Frame.<init>(Frame.java:393)
at GetGraphicsTest.<init>(GetGraphicsTest.java:35)
at GetGraphicsTest.main(GetGraphicsTest.java:47)

-------------

Commit messages:
 - 8306838: GetGraphicsTest needs to be headful

Changes: https://git.openjdk.org/jdk/pull/13639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306838
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13639/head:pull/13639

PR: https://git.openjdk.org/jdk/pull/13639


From jiefu at openjdk.org  Tue Apr 25 13:24:14 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 25 Apr 2023 13:24:14 GMT
Subject: RFR: 8306849: Missing headful in
 java/awt/Graphics/GetGraphicsTest.java
Message-ID: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>

Add `@key headful` in the test.

-------------

Commit messages:
 - 8306849: Missing headful in java/awt/Graphics/GetGraphicsTest.java

Changes: https://git.openjdk.org/jdk/pull/13640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306849
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13640/head:pull/13640

PR: https://git.openjdk.org/jdk/pull/13640


From psadhukhan at openjdk.org  Tue Apr 25 13:36:08 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 13:36:08 GMT
Subject: RFR: 8306849: Missing headful in
 java/awt/Graphics/GetGraphicsTest.java
In-Reply-To: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>
References: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>
Message-ID: <wx_FwXQLy6jrl2bf0YmSCF4VEtXnz1RO40q2uKrTQnc=.299db52d-0713-4f05-8732-61c42af90a13@github.com>

On Tue, 25 Apr 2023 13:16:33 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Add `@key headful` in the test.

My PR is already out for this https://git.openjdk.org/jdk/pull/13639 before yours...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13640#issuecomment-1521799105


From jdv at openjdk.org  Tue Apr 25 13:55:38 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 25 Apr 2023 13:55:38 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and
 Toolkit
Message-ID: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>

This PR open sources some tests related to AWT datatransfer and Toolkit.

-------------

Commit messages:
 - 8306638: Open source some AWT tests related to datatransfer and Toolkit

Changes: https://git.openjdk.org/jdk/pull/13642/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306638
  Stats: 855 lines in 5 files changed: 855 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13642/head:pull/13642

PR: https://git.openjdk.org/jdk/pull/13642


From jiefu at openjdk.org  Tue Apr 25 14:00:21 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 25 Apr 2023 14:00:21 GMT
Subject: RFR: 8306849: Missing headful in
 java/awt/Graphics/GetGraphicsTest.java
In-Reply-To: <wx_FwXQLy6jrl2bf0YmSCF4VEtXnz1RO40q2uKrTQnc=.299db52d-0713-4f05-8732-61c42af90a13@github.com>
References: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>
 <wx_FwXQLy6jrl2bf0YmSCF4VEtXnz1RO40q2uKrTQnc=.299db52d-0713-4f05-8732-61c42af90a13@github.com>
Message-ID: <cy9q2f2yJzzmK3YzN4R69mRnn4glx22L7ulWCmir1NQ=.1bca9d44-0a7d-40f1-a3a4-eeded9f9f010@github.com>

On Tue, 25 Apr 2023 13:33:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> My PR is already out for this https://git.openjdk.org/jdk/pull/13639 before yours...

OK.
So just close this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13640#issuecomment-1521836192


From jiefu at openjdk.org  Tue Apr 25 14:00:23 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 25 Apr 2023 14:00:23 GMT
Subject: Withdrawn: 8306849: Missing headful in
 java/awt/Graphics/GetGraphicsTest.java
In-Reply-To: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>
References: <TCWPoimsz03a3KByV_1ca4CXc7CHMiYj6mlf9JPlo7A=.0321ace6-3ae2-40dd-a0e9-c53b68f6b7cd@github.com>
Message-ID: <9d-8C-Nq3EhAPcGzTCVGocH1CWse006hqc4Ss2Qhx-A=.41045324-a0ed-4440-985f-9b59ccf21d94@github.com>

On Tue, 25 Apr 2023 13:16:33 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Add `@key headful` in the test.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13640


From jiefu at openjdk.org  Tue Apr 25 14:00:13 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 25 Apr 2023 14:00:13 GMT
Subject: RFR: 8306838: GetGraphicsTest needs to be headful
In-Reply-To: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
References: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
Message-ID: <wot7DqhQ0i7H7cv1dBwEHfCL__sawxmgRKLR9X6ouMA=.cc64d509-5ad0-431c-b930-1573ab477889@github.com>

On Tue, 25 Apr 2023 12:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Newly added GetGraphicsTest should be headful as it uses a Frame
> 
> 
> java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
> at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:166)
> at java.desktop/java.awt.Window.<init>(Window.java:553)
> at java.desktop/java.awt.Frame.<init>(Frame.java:428)
> at java.desktop/java.awt.Frame.<init>(Frame.java:393)
> at GetGraphicsTest.<init>(GetGraphicsTest.java:35)
> at GetGraphicsTest.main(GetGraphicsTest.java:47)

LGTM

-------------

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13639#pullrequestreview-1399987464


From dcubed at openjdk.org  Tue Apr 25 14:20:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 25 Apr 2023 14:20:11 GMT
Subject: RFR: 8306838: GetGraphicsTest needs to be headful
In-Reply-To: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
References: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
Message-ID: <75o5_9tONYdioQzTas5MPej0_B6ziU97A3Jt5TTYRts=.8b7f833a-ad4e-4400-ad7e-af7c5288165d@github.com>

On Tue, 25 Apr 2023 12:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Newly added GetGraphicsTest should be headful as it uses a Frame
> 
> 
> java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
> at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:166)
> at java.desktop/java.awt.Window.<init>(Window.java:553)
> at java.desktop/java.awt.Frame.<init>(Frame.java:428)
> at java.desktop/java.awt.Frame.<init>(Frame.java:393)
> at GetGraphicsTest.<init>(GetGraphicsTest.java:35)
> at GetGraphicsTest.main(GetGraphicsTest.java:47)

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13639#pullrequestreview-1400031340


From psadhukhan at openjdk.org  Tue Apr 25 15:33:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 15:33:20 GMT
Subject: Integrated: 8306838: GetGraphicsTest needs to be headful
In-Reply-To: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
References: <t5r02lcYXZsBJHah9KmElwM_NSdH3j5waK3ou_gH-b0=.0d1bbed9-e541-4479-b5f7-c0367140ba2b@github.com>
Message-ID: <6F9bSlpOZkhFchrLjm0EoAJyq-E6pU3jFlQtXqIIeDc=.473ff2b8-4e73-4b08-a1a6-3a0efb681528@github.com>

On Tue, 25 Apr 2023 12:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Newly added GetGraphicsTest should be headful as it uses a Frame
> 
> 
> java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
> at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:166)
> at java.desktop/java.awt.Window.<init>(Window.java:553)
> at java.desktop/java.awt.Frame.<init>(Frame.java:428)
> at java.desktop/java.awt.Frame.<init>(Frame.java:393)
> at GetGraphicsTest.<init>(GetGraphicsTest.java:35)
> at GetGraphicsTest.main(GetGraphicsTest.java:47)

This pull request has now been integrated.

Changeset: 07ea445b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07ea445b43e0df682f305c8709495094e807b1f8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8306838: GetGraphicsTest needs to be headful

Reviewed-by: jiefu, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/13639


From tr at openjdk.org  Tue Apr 25 15:39:34 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 15:39:34 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v5]
In-Reply-To: <A7LfEzl0bJILIypub4HiULjM77uZ-UuhFkHm7nIPaMY=.bbff4602-45ad-4bfa-b907-5d73201de1ad@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
 <A7LfEzl0bJILIypub4HiULjM77uZ-UuhFkHm7nIPaMY=.bbff4602-45ad-4bfa-b907-5d73201de1ad@github.com>
Message-ID: <tsJNdjyQ-TdBGC8ebTRirDqAXC5mY15XQQiHB35sJ3k=.ff0a9013-fa1a-47b6-8a5e-ecc54c422ad2@github.com>

On Mon, 24 Apr 2023 21:28:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, please confirm that mach5 is green.

Yes, I retested with mach5 and its fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13573#issuecomment-1522013122


From tr at openjdk.org  Tue Apr 25 15:43:18 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 25 Apr 2023 15:43:18 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v2]
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <FKGzT-ruG-F-1yCwdN_Oifn9prPcNTp1mwTED5MKbxk=.5ece554a-14f0-44ab-a919-886573a5f754@github.com>

> Open source few AWT ScrollPane related tests.

Tejesh R has updated the pull request incrementally with two additional commits since the last revision:

 - Updated based on Review Comments
 - Updated based on Review Comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13621/files
  - new: https://git.openjdk.org/jdk/pull/13621/files/e932bed3..ffad753e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=00-01

  Stats: 757 lines in 10 files changed: 369 ins; 377 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621

PR: https://git.openjdk.org/jdk/pull/13621


From serb at openjdk.org  Tue Apr 25 16:18:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 16:18:11 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer
 and Toolkit
In-Reply-To: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
References: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
Message-ID: <CqNqk1-1NkblJKuoRP2pjAFZ3v1alnrk2oevQJMumLQ=.ea18915a-3844-4a9a-887d-49ec36b46fc8@github.com>

On Tue, 25 Apr 2023 13:48:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources some tests related to AWT datatransfer and Toolkit.

test/jdk/java/awt/Toolkit/ToolkitListenerTest/ToolkitListenerTest.java line 100:

> 98: 
> 99:     public void eventDispatched(AWTEvent e) {
> 100:         System.err.println(e);

On what thread this will be executed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1176748847


From dnguyen at openjdk.org  Tue Apr 25 16:26:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 16:26:25 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests [v2]
In-Reply-To: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
Message-ID: <OXgpaLIM_G4FAgilZyKEVFGAGo2c5hE3is3LzGYtH2M=.3fd10749-d2bd-4cde-b529-f22319515e8b@github.com>

> This PR open sources few AWT DnD related tests

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove endline. Add frame titles. Dispose in EDT.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13591/files
  - new: https://git.openjdk.org/jdk/pull/13591/files/90e7447d..c9194563

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13591&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13591&range=00-01

  Stats: 47 lines in 5 files changed: 2 ins; 5 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/13591.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13591/head:pull/13591

PR: https://git.openjdk.org/jdk/pull/13591


From dnguyen at openjdk.org  Tue Apr 25 16:26:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 16:26:25 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
Message-ID: <ugIpFw8W9oEQ7gbYw8vD7SrcylLBZ4tfNVZDZgr7FKI=.86de836e-27cb-42ab-ab4d-75012248c440@github.com>

On Fri, 21 Apr 2023 21:07:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources few AWT DnD related tests

Updated the tests with a frame to have a title rather than nothing or a meaningless title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13591#issuecomment-1522075066


From dnguyen at openjdk.org  Tue Apr 25 16:26:28 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 16:26:28 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests [v2]
In-Reply-To: <9SkAJmCXwSILkucD99-PGTVz3sJ7aqnBZWpY5dALmGQ=.d258efcf-9f1f-40ec-9578-1edcb52c2bca@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
 <_2bJwut7-7QWhcIqIgi2Mju_e4fsHPTsj2WTsfHEFmY=.8d1d492c-a5d2-4284-95ce-3e2a2d76ae1b@github.com>
 <9SkAJmCXwSILkucD99-PGTVz3sJ7aqnBZWpY5dALmGQ=.d258efcf-9f1f-40ec-9578-1edcb52c2bca@github.com>
Message-ID: <W9f8vMNZ2y1hZDWJCcrvgIzLfm5k1roZa_pK7yc92VI=.c23deb57-986e-4bba-b4b9-a203f715f603@github.com>

On Fri, 21 Apr 2023 23:09:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There's no harm in doing that but I'm not sure its necessary for the dispose().
>
> it is fine to call dispose here on the main, but the frame possibly can be null here.

I have updated the tests to all dispose on the EDT just in case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1176755562


From dnguyen at openjdk.org  Tue Apr 25 16:26:31 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 16:26:31 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests [v2]
In-Reply-To: <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
Message-ID: <ea6zj4PuIOKRMZkclFsiwIYDTXmH37kraRSaT1y3i9k=.f493575a-66d5-4ae4-8d7f-262478ff8db0@github.com>

On Fri, 21 Apr 2023 21:35:07 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove endline. Add frame titles. Dispose in EDT.
>
> test/jdk/java/awt/dnd/NoTargetNoDragExitTest/NoTargetNoDragExitTest.java line 136:
> 
>> 134:             }
>> 135:         }
>> 136: 
> 
> You can remove extra lines

I removed the extra endline on all tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1176755830


From prr at openjdk.org  Tue Apr 25 16:49:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 16:49:12 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer
 and Toolkit
In-Reply-To: <CqNqk1-1NkblJKuoRP2pjAFZ3v1alnrk2oevQJMumLQ=.ea18915a-3844-4a9a-887d-49ec36b46fc8@github.com>
References: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
 <CqNqk1-1NkblJKuoRP2pjAFZ3v1alnrk2oevQJMumLQ=.ea18915a-3844-4a9a-887d-49ec36b46fc8@github.com>
Message-ID: <g1r7fE9UhnrD4ID7pJXySZYyTCZSLIsRg47tl14P8aE=.02d4ab2e-a408-4270-be01-1e396a08bf4e@github.com>

On Tue, 25 Apr 2023 16:14:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This PR open sources some tests related to AWT datatransfer and Toolkit.
>
> test/jdk/java/awt/Toolkit/ToolkitListenerTest/ToolkitListenerTest.java line 100:
> 
>> 98: 
>> 99:     public void eventDispatched(AWTEvent e) {
>> 100:         System.err.println(e);
> 
> On what thread this will be executed?

Surely it will be the EDT ? Why do you ask ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1176784317


From serb at openjdk.org  Tue Apr 25 16:52:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Apr 2023 16:52:12 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
Message-ID: <nmm2C1g-XFqxc0R8iUX1r9xHRKOW3pwrj1GjbM0z05c=.ebde057a-a49b-42e9-9ea7-ca0134b1b1d6@github.com>

On Tue, 25 Apr 2023 09:35:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

test/jdk/java/awt/LightweightComponent/LightweightDragTest.java line 113:

> 111:        }
> 112:        rb.mouseRelease(InputEvent.BUTTON1_MASK);
> 113:        if (c.isInside || !c2.isInside) {

Do we set these props on EDT in the processEvent below and read here w/o synchronization?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1176787266


From prr at openjdk.org  Tue Apr 25 16:56:09 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 16:56:09 GMT
Subject: RFR: 8306718: Optimize and opensource some old AWT tests
In-Reply-To: <XQ-zbdcfrs9fYI7RbR5wYlStdtsZOky175YtHN28QLk=.7e7205db-4022-42ac-b146-b024ada43001@github.com>
References: <XQ-zbdcfrs9fYI7RbR5wYlStdtsZOky175YtHN28QLk=.7e7205db-4022-42ac-b146-b024ada43001@github.com>
Message-ID: <JSNR15-To158KDoTTp_PBKSJW-A7Rx13iprDkzoGeqU=.3181f23b-4321-4f07-957d-9e6fefb71583@github.com>

On Tue, 25 Apr 2023 10:37:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Four tests are cleaned and optimized, ready to open source.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13637#pullrequestreview-1400346836


From prr at openjdk.org  Tue Apr 25 17:01:11 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:01:11 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v3]
In-Reply-To: <wDfkMBRCT8cm0y7CgDaDRFwew9JDv3XJja1GsRCLIN8=.0820404e-4753-443f-abba-9fd2a69a219e@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <wDfkMBRCT8cm0y7CgDaDRFwew9JDv3XJja1GsRCLIN8=.0820404e-4753-443f-abba-9fd2a69a219e@github.com>
Message-ID: <UktRAWb701Ds5et2GFYVeEGr66TY6SUa9nSzGVwEuzc=.62bf1f69-a087-40a0-84f1-e2bd931464b4@github.com>

On Tue, 25 Apr 2023 09:16:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source MenuItem AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Timeout removed

Changes requested by prr (Reviewer).

test/jdk/java/awt/MenuItem/EnableTest.java line 51:

> 49:         try {
> 50:             EventQueue.invokeAndWait(() -> {
> 51:                 frame = new Frame();

Can we please have a meaningful Frame title here ? "EnableTest" perhaps ?

test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 51:

> 49:         try {
> 50:             EventQueue.invokeAndWait(() -> {
> 51:                 f = new Menu1();

Menu1("MenuSetLabelTest")

test/jdk/java/awt/MenuItem/SetStateTest.java line 49:

> 47:         try {
> 48:             EventQueue.invokeAndWait(() -> {
> 49:                 frame = new Frame();

Frame("SetStateTest")

-------------

PR Review: https://git.openjdk.org/jdk/pull/13589#pullrequestreview-1400353605
PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176796235
PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176796687
PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1176797090


From prr at openjdk.org  Tue Apr 25 17:02:10 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:02:10 GMT
Subject: RFR: 8306765: Some client related jtreg problem list entries are
 malformed [v2]
In-Reply-To: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
References: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
Message-ID: <n2DcNbjTfN6V70gar0zvNsunN3CVAwrDqeKe1Lc9kyc=.4a856fff-34cf-4bd7-91c1-86c5a46adb18@github.com>

> There were missing platforms in a couple of problem list entries.
> I verified the intended platforms are still needed and the other platforms pass.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8306765

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13626/files
  - new: https://git.openjdk.org/jdk/pull/13626/files/21d29768..908e234a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13626&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13626&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13626/head:pull/13626

PR: https://git.openjdk.org/jdk/pull/13626


From prr at openjdk.org  Tue Apr 25 17:02:13 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:02:13 GMT
Subject: RFR: 8306765: Some client related jtreg problem list entries are
 malformed [v2]
In-Reply-To: <ZYxwfKPTl6FhTVtP_pSoEyxPLGV_hT9PW_3lUJDMAYE=.452afe69-b5fa-4414-9a5b-7a5e2efe6412@github.com>
References: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
 <ZYxwfKPTl6FhTVtP_pSoEyxPLGV_hT9PW_3lUJDMAYE=.452afe69-b5fa-4414-9a5b-7a5e2efe6412@github.com>
Message-ID: <qZ35v6GUf6ZnTHswIQstwBWky8c5G8rHXet9DX3Eno0=.4e085ee4-57b1-4447-9ef1-96a778520d12@github.com>

On Tue, 25 Apr 2023 01:51:38 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306765
>
> test/jdk/ProblemList.txt line 444:
> 
>> 442: java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java 8238720 windows-all
>> 443: java/awt/GridLayout/ChangeGridSize/ChangeGridSize.java   8238720 windows-all
>> 444: java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.java windows-all
> 
> bugid?

well oops. I knew which bug I wanted to add but somehow .. anyway fixed now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13626#discussion_r1176794265


From azvegint at openjdk.org  Tue Apr 25 17:02:42 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 17:02:42 GMT
Subject: RFR: 8306683: Open source several clipboard and color AWT tests
Message-ID: <ln88AgY4ZwG1taRQW8er28Mtye6kcoLE-PdRcIpPkUc=.eb401df6-af36-4ab5-a22a-79246499f46a@github.com>

Open source several clipboard and color AWT tests.

testing looks good.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/13647/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306683
  Stats: 570 lines in 4 files changed: 570 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13647/head:pull/13647

PR: https://git.openjdk.org/jdk/pull/13647


From prr at openjdk.org  Tue Apr 25 17:11:10 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:11:10 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v2]
In-Reply-To: <XihneKHzAQKF5V-GJU6e8eXwIl-jiRBVoLzNk686Ds0=.c28430ea-11fe-49c4-9415-e03cd3f3e89d@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
 <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>
 <OoILiqqyrrZxpmAUXtxXc4TDjYl5N9rooW9-66ag6VI=.fbb60db9-152d-46a1-80ad-09e7dd597246@github.com>
 <XihneKHzAQKF5V-GJU6e8eXwIl-jiRBVoLzNk686Ds0=.c28430ea-11fe-49c4-9415-e03cd3f3e89d@github.com>
Message-ID: <NbSOrdMpvzUw82stSqMzAoFw2suqQT9eHFmK-dZuMls=.82b335fe-b7a8-4635-956a-16e12ca694ca@github.com>

On Tue, 25 Apr 2023 10:51:09 GMT, Tejesh R <tr at openjdk.org> wrote:

>> probably the idea was to exclude "win 98/etc"? please check for what bug this test was created and if is it applicable for win10 or not.
>
> The bug was raised specifically for Win2000, also states that it is not reproducible for Windows NT 4.0 and Windows 98. I don't think that this test is specific to Win2000, in JBS they mention about a feature being added from Win2000, hence the fix wasn't applicable to previous versions.

If you ask me for my guess, this check was saying "something new was introduced in Windows 2000" (note that NT 4 and Windows 98 PRE-DATE Windows 2000). And all the other OSes they are looking for come AFTER Windows 2000.
So they wanted to test on Windows 2000 and LATER.
However this exact match requirement means that this test has surely been skipped for the last ~ 10 years .. whenever we stopped testing on XP .. 
And until you remove the check I suspect you have no idea if this test passes today on Windows 10, or is relevant.
You will need to remove the check, run the test locally and observe, and then run on the CI test system.
Probably its still valid but you need to be sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1176807062


From azvegint at openjdk.org  Tue Apr 25 17:11:21 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 17:11:21 GMT
Subject: RFR: 8306753: Open source several container AWT tests
Message-ID: <R6dvVBIviaWjJJp_CJtUfUjcuIT6Crsb_SbE9e_-h-o=.e3c340e9-869c-4d00-83c3-af20e2b8ca6a@github.com>

Open source several container AWT tests

testing looks good.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/13648/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13648&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306753
  Stats: 814 lines in 4 files changed: 814 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13648.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13648/head:pull/13648

PR: https://git.openjdk.org/jdk/pull/13648


From azvegint at openjdk.org  Tue Apr 25 17:13:27 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 17:13:27 GMT
Subject: RFR: 8306752: Open source several container and component AWT tests
Message-ID: <xBPn2j9BStKbe9PlSc9raBeipaSYhU273ZcP0_NLCh4=.ccbba04c-4712-4335-80ac-932269ef4833@github.com>

Open source several container and component AWT tests.

testing looks good.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/13649/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306752
  Stats: 664 lines in 4 files changed: 664 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13649/head:pull/13649

PR: https://git.openjdk.org/jdk/pull/13649


From prr at openjdk.org  Tue Apr 25 17:15:09 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:15:09 GMT
Subject: RFR: 8306753: Open source several container AWT tests
In-Reply-To: <R6dvVBIviaWjJJp_CJtUfUjcuIT6Crsb_SbE9e_-h-o=.e3c340e9-869c-4d00-83c3-af20e2b8ca6a@github.com>
References: <R6dvVBIviaWjJJp_CJtUfUjcuIT6Crsb_SbE9e_-h-o=.e3c340e9-869c-4d00-83c3-af20e2b8ca6a@github.com>
Message-ID: <ixvef1Y3RAX_NjHkl8mWExh7PQtOnirottjlf5VQT2c=.c9c89664-e4c6-49d0-b202-b1d547f1b759@github.com>

On Tue, 25 Apr 2023 17:02:42 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several container AWT tests
> 
> testing looks good.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13648#pullrequestreview-1400376287


From prr at openjdk.org  Tue Apr 25 17:19:09 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:19:09 GMT
Subject: RFR: 8306683: Open source several clipboard and color AWT tests
In-Reply-To: <ln88AgY4ZwG1taRQW8er28Mtye6kcoLE-PdRcIpPkUc=.eb401df6-af36-4ab5-a22a-79246499f46a@github.com>
References: <ln88AgY4ZwG1taRQW8er28Mtye6kcoLE-PdRcIpPkUc=.eb401df6-af36-4ab5-a22a-79246499f46a@github.com>
Message-ID: <F2ryNITxtc34r6Mb0gyYaWsYwKq5kq3f-0WaDJrP7oI=.3e8996af-bf70-4212-9c96-db6ba3aff546@github.com>

On Tue, 25 Apr 2023 16:54:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several clipboard and color AWT tests.
> 
> testing looks good.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13647#pullrequestreview-1400381453


From prr at openjdk.org  Tue Apr 25 17:20:07 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:20:07 GMT
Subject: RFR: 8306752: Open source several container and component AWT
 tests
In-Reply-To: <xBPn2j9BStKbe9PlSc9raBeipaSYhU273ZcP0_NLCh4=.ccbba04c-4712-4335-80ac-932269ef4833@github.com>
References: <xBPn2j9BStKbe9PlSc9raBeipaSYhU273ZcP0_NLCh4=.ccbba04c-4712-4335-80ac-932269ef4833@github.com>
Message-ID: <b9gi58co1w5Op5AkSeZp97-1Eq-4RnCWCpn-hm5xd9Q=.a9eebc80-c8ce-4fb6-b62e-196b28244759@github.com>

On Tue, 25 Apr 2023 17:05:02 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several container and component AWT tests.
> 
> testing looks good.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13649#pullrequestreview-1400383802


From prr at openjdk.org  Tue Apr 25 17:30:09 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 17:30:09 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer
 and Toolkit
In-Reply-To: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
References: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
Message-ID: <_Ft_WnzmZKHxYe5yZqynQAQAAuGnCZ6G_mc82p_0VuY=.58ed0074-5c88-43fc-91ac-ad2693e43f47@github.com>

On Tue, 25 Apr 2023 13:48:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources some tests related to AWT datatransfer and Toolkit.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13642#pullrequestreview-1400397778


From psadhukhan at openjdk.org  Tue Apr 25 17:45:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Apr 2023 17:45:20 GMT
Subject: RFR: 8306755: Open source few Swing JComponent and AbstractButton
 tests
Message-ID: <_drOTCJAcbqZa33sckkLYhZp3-l-kD4Kt6NskTozXsM=.66793e8a-91a4-4d5f-8e68-a4b8069aee7b@github.com>

This opensources few swing JComponent and AbstractButton tests

-------------

Commit messages:
 - 8306755: Open source few Swing JComponent and AbstractButton tests

Changes: https://git.openjdk.org/jdk/pull/13651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306755
  Stats: 576 lines in 5 files changed: 576 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13651/head:pull/13651

PR: https://git.openjdk.org/jdk/pull/13651


From iris at openjdk.org  Tue Apr 25 17:58:14 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 25 Apr 2023 17:58:14 GMT
Subject: RFR: 8306765: Some client related jtreg problem list entries are
 malformed [v2]
In-Reply-To: <n2DcNbjTfN6V70gar0zvNsunN3CVAwrDqeKe1Lc9kyc=.4a856fff-34cf-4bd7-91c1-86c5a46adb18@github.com>
References: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
 <n2DcNbjTfN6V70gar0zvNsunN3CVAwrDqeKe1Lc9kyc=.4a856fff-34cf-4bd7-91c1-86c5a46adb18@github.com>
Message-ID: <fc8AEGxs3X8PI2kyQKdvDN7RAottf8Qg2S0fQVH7Jns=.0ca2bbf0-164c-4f5a-ad3d-60b7767e885d@github.com>

On Tue, 25 Apr 2023 17:02:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> There were missing platforms in a couple of problem list entries.
>> I verified the intended platforms are still needed and the other platforms pass.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306765

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13626#pullrequestreview-1400437638


From abhiscxk at openjdk.org  Tue Apr 25 18:05:22 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 18:05:22 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v4]
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <vNo7ph0LyfWcApS3EnhChgaXEt6ExGPmfPVWa_bNWP0=.0f44ccfe-c32b-43bd-a58e-bb381e17b420@github.com>

> This PR is to open source MenuItem AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Frame title set

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13589/files
  - new: https://git.openjdk.org/jdk/pull/13589/files/7b89b4ea..3d07d952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=02-03

  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13589/head:pull/13589

PR: https://git.openjdk.org/jdk/pull/13589


From abhiscxk at openjdk.org  Tue Apr 25 18:05:25 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 25 Apr 2023 18:05:25 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v3]
In-Reply-To: <UktRAWb701Ds5et2GFYVeEGr66TY6SUa9nSzGVwEuzc=.62bf1f69-a087-40a0-84f1-e2bd931464b4@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <wDfkMBRCT8cm0y7CgDaDRFwew9JDv3XJja1GsRCLIN8=.0820404e-4753-443f-abba-9fd2a69a219e@github.com>
 <UktRAWb701Ds5et2GFYVeEGr66TY6SUa9nSzGVwEuzc=.62bf1f69-a087-40a0-84f1-e2bd931464b4@github.com>
Message-ID: <epLI7XCRfWVfIcgW0B7nR9tLXZGfWiDpfMWbQwWb8Yg=.95553e55-fb4a-4947-a2c0-d94776c7326b@github.com>

On Tue, 25 Apr 2023 16:58:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Timeout removed
>
> Changes requested by prr (Reviewer).

@prrace Frame title updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13589#issuecomment-1522195508


From prr at openjdk.org  Tue Apr 25 18:13:09 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 18:13:09 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v4]
In-Reply-To: <vNo7ph0LyfWcApS3EnhChgaXEt6ExGPmfPVWa_bNWP0=.0f44ccfe-c32b-43bd-a58e-bb381e17b420@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <vNo7ph0LyfWcApS3EnhChgaXEt6ExGPmfPVWa_bNWP0=.0f44ccfe-c32b-43bd-a58e-bb381e17b420@github.com>
Message-ID: <SYPr7izqovIcRWRPw5dCogczRNCSjTLi_DHqZhYw_8Y=.dedaf795-92ca-4ba4-a6e1-93c550cf5e75@github.com>

On Tue, 25 Apr 2023 18:05:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source MenuItem AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Frame title set

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13589#pullrequestreview-1400459341


From prr at openjdk.org  Tue Apr 25 18:14:29 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 18:14:29 GMT
Subject: Integrated: 8306765: Some client related jtreg problem list entries
 are malformed
In-Reply-To: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
References: <94uD5f7e296jMSCyRqVVLSmipEWFvX--4-hL5mepwbI=.d064dc2e-8c8b-41a9-aee0-306c9a82e1d8@github.com>
Message-ID: <LZyVv1IMayW_BtH_-hqEdjXgFZD2jcYhGmPs4ZYvBB4=.2f62b1a5-d0c8-4c9c-b559-788d57169533@github.com>

On Mon, 24 Apr 2023 19:20:54 GMT, Phil Race <prr at openjdk.org> wrote:

> There were missing platforms in a couple of problem list entries.
> I verified the intended platforms are still needed and the other platforms pass.

This pull request has now been integrated.

Changeset: 36d61c31
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36d61c3106c69c019f2d4ded7dedd1649c1226b3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8306765: Some client related jtreg problem list entries are malformed

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/13626


From dnguyen at openjdk.org  Tue Apr 25 18:17:37 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 18:17:37 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests
Message-ID: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>

This PR open sources a few more AWT DnD related tests

-------------

Commit messages:
 - Add dnd tests

Changes: https://git.openjdk.org/jdk/pull/13653/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306466
  Stats: 838 lines in 8 files changed: 838 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13653/head:pull/13653

PR: https://git.openjdk.org/jdk/pull/13653


From kizune at openjdk.org  Tue Apr 25 18:35:23 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 25 Apr 2023 18:35:23 GMT
Subject: Integrated: 8306718: Optimize and opensource some old AWT tests
In-Reply-To: <XQ-zbdcfrs9fYI7RbR5wYlStdtsZOky175YtHN28QLk=.7e7205db-4022-42ac-b146-b024ada43001@github.com>
References: <XQ-zbdcfrs9fYI7RbR5wYlStdtsZOky175YtHN28QLk=.7e7205db-4022-42ac-b146-b024ada43001@github.com>
Message-ID: <DPu1qlMZTURNe66lsTwqjSXU-YxDrPXh8vcKcQSLK3s=.85834002-bb3f-4553-a0d3-3dc7d0508441@github.com>

On Tue, 25 Apr 2023 10:37:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Four tests are cleaned and optimized, ready to open source.

This pull request has now been integrated.

Changeset: 9beae218
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9beae21864d18054ca3762ec989d51ff0660db84
Stats:     410 lines in 4 files changed: 410 ins; 0 del; 0 mod

8306718: Optimize and opensource some old AWT tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13637


From aivanov at openjdk.org  Tue Apr 25 18:38:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Apr 2023 18:38:14 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v7]
In-Reply-To: <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>
Message-ID: <_zR0eX4eYt99OkRXKRaBkcwglfnCAIffO-w84EZXyqQ=.48e3b2ec-d734-466b-a39d-e090bc8e25cb@github.com>

On Mon, 24 Apr 2023 19:25:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Jam lines into 80 columns.
>  - Add more scenarios to the regression test.

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 184:

> 182:           .ifPresent(name -> {
> 183:             throw new Error("property \"" + name + "\" not found in " + type);
> 184:           });

Suggestion:

        expected.stream()
                .map(PropertyDescriptor::getName)
                .filter(name -> BeanUtils.getPropertyDescriptor(type, name) == null)
                .findFirst()
                .ifPresent(name -> {
                    throw new Error("property "" + name + "" not found in " + type);
                });

I don't know if there's a common style that's followed in OpenJDK, however, aligning wrapped method calls in streams on the dot is the most common way. I prefer this style.

Indenting wrapped lines by two spaces doesn't look standard to me, the most common indentation for wrapped lines seems to be 8 spaces.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 188:

> 186:         // Gather actual properties
> 187:         final Set<PropertyDescriptor> actual = Set.of(
> 188:             BeanUtils.getPropertyDescriptors(type));

Suggestion:

        final Set<PropertyDescriptor> actual =
                Set.of(BeanUtils.getPropertyDescriptors(type));

May be easier to read? I mean wrapping the entire expression instead of breaking the expression.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 200:

> 198:               + expected.stream()
> 199:                 .map(Object::toString)
> 200:                 .collect(Collectors.joining("\n  ")));

Suggestion:

              + actual.stream()
                      .map(Object::toString)
                      .collect(Collectors.joining("\n  "))
              + "\nEXPECTED:\n  "
              + expected.stream()
                        .map(Object::toString)
                        .collect(Collectors.joining("\n  ")));

-------------

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1400494157
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176886529
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176890225
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176888835


From acobbs at openjdk.org  Tue Apr 25 18:52:16 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Apr 2023 18:52:16 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v8]
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

Archie Cobbs 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 13 additional commits since the last revision:

 - Whitespace cleanups suggested by review.
 - Merge branch 'master' into JDK-8071693
 - Jam lines into 80 columns.
 - Add more scenarios to the regression test.
 - Add braces around if clause.
 - Add comment describing what IGNORABLE_INTERFACES is for.
 - Put braces around single-line "if" statement clauses in test.
 - Merge branch 'master' into JDK-8071693
 - Verify static method is not mistakenly identified as property getter.
 - Use Modifier.isAbstract() convenience method instead of bit masking test.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/20209749...b92726a9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13544/files
  - new: https://git.openjdk.org/jdk/pull/13544/files/e6a2ecba..b92726a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13544&range=06-07

  Stats: 13212 lines in 273 files changed: 8442 ins; 3664 del; 1106 mod
  Patch: https://git.openjdk.org/jdk/pull/13544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544

PR: https://git.openjdk.org/jdk/pull/13544


From acobbs at openjdk.org  Tue Apr 25 18:52:20 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Apr 2023 18:52:20 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v7]
In-Reply-To: <_zR0eX4eYt99OkRXKRaBkcwglfnCAIffO-w84EZXyqQ=.48e3b2ec-d734-466b-a39d-e090bc8e25cb@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <DTv28EGOWxPm4pIsQonQap4S8hxBRXVqkma76Cnctis=.7ed717d6-624b-41a3-8f93-d30fbee1bf8f@github.com>
 <_zR0eX4eYt99OkRXKRaBkcwglfnCAIffO-w84EZXyqQ=.48e3b2ec-d734-466b-a39d-e090bc8e25cb@github.com>
Message-ID: <J1bh33a3l_4mdSdxXjVAPopMlqGJs6NkKmBnrXjxs3I=.d0d5c37f-51c9-4193-b3e6-a0959cb22754@github.com>

On Tue, 25 Apr 2023 18:31:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Jam lines into 80 columns.
>>  - Add more scenarios to the regression test.
>
> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 184:
> 
>> 182:           .ifPresent(name -> {
>> 183:             throw new Error("property \"" + name + "\" not found in " + type);
>> 184:           });
> 
> Suggestion:
> 
>         expected.stream()
>                 .map(PropertyDescriptor::getName)
>                 .filter(name -> BeanUtils.getPropertyDescriptor(type, name) == null)
>                 .findFirst()
>                 .ifPresent(name -> {
>                     throw new Error("property "" + name + "" not found in " + type);
>                 });
> 
> I don't know if there's a common style that's followed in OpenJDK, however, aligning wrapped method calls in streams on the dot is the most common way. I prefer this style.
> 
> Indenting wrapped lines by two spaces doesn't look standard to me, the most common indentation for wrapped lines seems to be 8 spaces.

Thanks - fixed in b92726a923b.

> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 188:
> 
>> 186:         // Gather actual properties
>> 187:         final Set<PropertyDescriptor> actual = Set.of(
>> 188:             BeanUtils.getPropertyDescriptors(type));
> 
> Suggestion:
> 
>         final Set<PropertyDescriptor> actual =
>                 Set.of(BeanUtils.getPropertyDescriptors(type));
> 
> May be easier to read? I mean wrapping the entire expression instead of breaking the expression.

Thanks - fixed in b92726a923b.

> test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 200:
> 
>> 198:               + expected.stream()
>> 199:                 .map(Object::toString)
>> 200:                 .collect(Collectors.joining("\n  ")));
> 
> Suggestion:
> 
>               + actual.stream()
>                       .map(Object::toString)
>                       .collect(Collectors.joining("\n  "))
>               + "\nEXPECTED:\n  "
>               + expected.stream()
>                         .map(Object::toString)
>                         .collect(Collectors.joining("\n  ")));

Thanks - fixed in b92726a923b.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176901780
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176901938
PR Review Comment: https://git.openjdk.org/jdk/pull/13544#discussion_r1176901865


From aivanov at openjdk.org  Tue Apr 25 18:54:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Apr 2023 18:54:13 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v8]
In-Reply-To: <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
Message-ID: <Bdn1IGxjfbOl32c7FHOQC6L_0il4Os2Kxdyy2il805I=.e531a087-ac6a-4867-9a4a-944a1a81aef4@github.com>

On Tue, 25 Apr 2023 18:52:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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 13 additional commits since the last revision:
> 
>  - Whitespace cleanups suggested by review.
>  - Merge branch 'master' into JDK-8071693
>  - Jam lines into 80 columns.
>  - Add more scenarios to the regression test.
>  - Add braces around if clause.
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/dbafbae5...b92726a9

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13544#pullrequestreview-1400539491


From azvegint at openjdk.org  Tue Apr 25 20:28:31 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 20:28:31 GMT
Subject: Integrated: 8306753: Open source several container AWT tests
In-Reply-To: <R6dvVBIviaWjJJp_CJtUfUjcuIT6Crsb_SbE9e_-h-o=.e3c340e9-869c-4d00-83c3-af20e2b8ca6a@github.com>
References: <R6dvVBIviaWjJJp_CJtUfUjcuIT6Crsb_SbE9e_-h-o=.e3c340e9-869c-4d00-83c3-af20e2b8ca6a@github.com>
Message-ID: <pONC6zBsmQRkQcAvCrL9DjgwAfVdsrUBrf31lNSV81s=.2fbaf820-381f-42f9-9a73-a91dc11b0dd6@github.com>

On Tue, 25 Apr 2023 17:02:42 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several container AWT tests
> 
> testing looks good.

This pull request has now been integrated.

Changeset: b372f28a
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b372f28ad4b7c1f46e0070a930911542d4d1a032
Stats:     814 lines in 4 files changed: 814 ins; 0 del; 0 mod

8306753: Open source several container AWT tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13648


From azvegint at openjdk.org  Tue Apr 25 20:30:27 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 20:30:27 GMT
Subject: Integrated: 8306683: Open source several clipboard and color AWT tests
In-Reply-To: <ln88AgY4ZwG1taRQW8er28Mtye6kcoLE-PdRcIpPkUc=.eb401df6-af36-4ab5-a22a-79246499f46a@github.com>
References: <ln88AgY4ZwG1taRQW8er28Mtye6kcoLE-PdRcIpPkUc=.eb401df6-af36-4ab5-a22a-79246499f46a@github.com>
Message-ID: <VOkWxy815PbDCRrwAe_Ay3HooZC9hNFMinCCtDxYZes=.97f7d95d-9dc1-4935-977f-9c00c500f81c@github.com>

On Tue, 25 Apr 2023 16:54:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several clipboard and color AWT tests.
> 
> testing looks good.

This pull request has now been integrated.

Changeset: 1c2dadc3
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c2dadc31e8b732d43df5494437720bfbc3f5c8b
Stats:     570 lines in 4 files changed: 570 ins; 0 del; 0 mod

8306683: Open source several clipboard and color AWT tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13647


From azvegint at openjdk.org  Tue Apr 25 20:31:20 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Apr 2023 20:31:20 GMT
Subject: Integrated: 8306752: Open source several container and component AWT
 tests
In-Reply-To: <xBPn2j9BStKbe9PlSc9raBeipaSYhU273ZcP0_NLCh4=.ccbba04c-4712-4335-80ac-932269ef4833@github.com>
References: <xBPn2j9BStKbe9PlSc9raBeipaSYhU273ZcP0_NLCh4=.ccbba04c-4712-4335-80ac-932269ef4833@github.com>
Message-ID: <py9pwn_fIlQ6atEhshJGvQqzeieRHRsxHrDUSvFInao=.1230906e-e295-4629-b8c3-df8a37bbca68@github.com>

On Tue, 25 Apr 2023 17:05:02 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Open source several container and component AWT tests.
> 
> testing looks good.

This pull request has now been integrated.

Changeset: 88d9ebf8
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88d9ebf8e80eeead3e4a1494ba537530c16b75e1
Stats:     664 lines in 4 files changed: 664 ins; 0 del; 0 mod

8306752: Open source several container and component AWT tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13649


From prr at openjdk.org  Tue Apr 25 21:21:23 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 21:21:23 GMT
Subject: RFR: 8305667: Some fonts installed in user directory are not
 detected on Windows
In-Reply-To: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
References: <KMY7ef1t535I72gXmuCZ1c130qbJ11NgA3xQr0RJlZY=.9c3d9e3d-a6f5-4076-b933-09cdc8314bce@github.com>
Message-ID: <3VhJQbl-oD9hYuyOyhZjaIzShRk7P5YBofaswEIAe-k=.6c95c1e1-24b5-4208-8c58-f316b766e867@github.com>

On Wed, 5 Apr 2023 17:03:45 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so its size is twice smaller than actual path limit, because paths returned by `RegEnumValueW` use wide chars. We need to double this limit.

src/java.desktop/windows/native/libfontmanager/fontpath.c line 522:

> 520: #define MAX_DATA_BUFFER (MAX_PATH*2+2)
> 521:     const wchar_t wname[MAX_NAME_BUFFER];
> 522:     const char data[MAX_DATA_BUFFER];

Looking at this I think we need to do more here and forget using the fixed buffer sizes and use what the query returns.

Let's consider NAME and DATA one at a time.

1) NAME
First note that we call the "W" version of the function so anything that is a string will be measured in wchars, not bytes
NAME is a string so the value we get back is the number of chars in the string.
Since we allocate using wchar_t we are OK there.
But we also need to note that the returned len doesn't include the terminating null.
So it seems to me that we need to adjust the check
dwMaxValueNameLen >= MAX_NAME_BUFFER


However going back to NAME the maximum name len has nothing to do with file paths.
So FILENAME_MAX and MAX_PATH are completely irrelevant and the code shouldn't be using it for NAME.
If there's a TTC with 10 fonts in it the name will look like
"NAME_XXXXXXXXXXXXXX_1 & NAME_XXXXXXXXXXX_2 & ... <elided> ...... & NAME_XXXXXXXXXXXX10 ... (TrueType)"
then we can exceed FILENAME_MAX and MAX_PATH very easily.
[BTW I checked and FILENAME_MAX and MAX_PATH are both 260]

So I think we need to dynamically allocate the buffer based on the returned value of dwMaxValueNameLen
which does NOT include the terminating NULL.

So I'd want code like
wname = (wchar_t*)(calloc(dwMaxValueNameLen+1, sizeof(wchar_t))

and then remember to  add code to free wname (!)

2) DATA
Since FILENAME_MAX and MAX_PATH are both 260, the current proposal doesn't change anything for NAME.
However it doubles the allocation for DATA. I can see why this is needed.
I see that for user installed fonts the registry value is the whole path (folder path + filename) ,
whereas for the installed fonts for which this was "designed" it is just the file name.
But why use the hard coded value when the registry call already told us what we need ?

RegQueryInfoKeyW specifies that it returns the data length in BYTES.
However we know its a unicode string, so depending how we allocate the array
its either len or len/2 - if its wchar_t.

wchar_t *data = (wchar_t*)(calloc(dwMaxValueNameLen, sizeof(char))

- we already cast to LPWSTR so why not make it a wchar_t anyway ?
- I used calloc just to be paranoid to get zeroed out memory
- I tested and can confirm that for DATA the returned len includes the allocation for the terminating null.

- remember to free this too
- With this dynamic allocation we no longer need the checks on lines 544/545

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13359#discussion_r1177067717


From prr at openjdk.org  Tue Apr 25 22:11:08 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 22:11:08 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests
In-Reply-To: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
Message-ID: <FimsrGu4cYDu2iUawXcPNtz0G5a5pdpBKO929EAsyg8=.aad9913c-c7c8-480e-962b-3743b997a721@github.com>

On Tue, 25 Apr 2023 18:08:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources a few more AWT DnD related tests

The 1st 4 of these tests do not need their own directories since they are single file tests. The extra folder can be dropped

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13653#issuecomment-1522483417


From prr at openjdk.org  Tue Apr 25 22:12:06 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 22:12:06 GMT
Subject: RFR: 8306755: Open source few Swing JComponent and AbstractButton
 tests
In-Reply-To: <_drOTCJAcbqZa33sckkLYhZp3-l-kD4Kt6NskTozXsM=.66793e8a-91a4-4d5f-8e68-a4b8069aee7b@github.com>
References: <_drOTCJAcbqZa33sckkLYhZp3-l-kD4Kt6NskTozXsM=.66793e8a-91a4-4d5f-8e68-a4b8069aee7b@github.com>
Message-ID: <iAYW6nvPGYkfWCYQ4gvi0LoNwhmo8BqVJPMKiqpoLTs=.475b5ade-2bae-4fda-a872-2f425543848d@github.com>

On Tue, 25 Apr 2023 17:37:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few swing JComponent and AbstractButton tests

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13651#pullrequestreview-1400832372


From prr at openjdk.org  Tue Apr 25 22:30:56 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 22:30:56 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>
Message-ID: <gCtfu4IfQNOkrxWBHF_g6hO72Z-udpKnrriu5TulW7Q=.a3956020-8bdf-49a2-9e01-ce03f0c10af0@github.com>

On Thu, 20 Apr 2023 08:48:51 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

>> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
>> 
>> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
>> 
>> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation for adressing comment on pull requests, with two changes to be discussed:
>   
>   - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
>   - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.

I have created the CSR https://bugs.openjdk.org/browse/JDK-8306875 and partially filled it,
but the wording of the spec changes need to be settled here before adding them there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13506#issuecomment-1522499583


From prr at openjdk.org  Tue Apr 25 22:50:18 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 22:50:18 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>
Message-ID: <SlVPgj_Jsy4A62ZFLTS7zJKRkhzoHesUe1QTkaEMbrc=.1616f0fa-06ee-4af5-91c7-22b0023afcc1@github.com>

On Thu, 20 Apr 2023 08:48:51 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

>> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
>> 
>> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
>> 
>> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation for adressing comment on pull requests, with two changes to be discussed:
>   
>   - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
>   - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1569:

> 1567:     /**
> 1568:      * Returns whether or not a tile is currently checked out for writing.
> 1569:      *

I think we need a few words here too -
"The only tile in a {@code BufferedImage} is at (0,0) and it is always writable, so calling this method with (0,0)
will always return {@code true}, and any other coordinate will cause an exception to be thrown".

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1593:

> 1591:      * Since a {@code BufferedImage} consists of a single tile,
> 1592:      * and that tile is always checked out for writing, the
> 1593:      * default implementation returns an array of one point.

I'd be happier with "the default implementation" -> "this method".
I did read your notes on subclasses etc but really these methods should have been final so I'd like to make
the documentation reflect that rather than implying that there's an open door to do something else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1177129499
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1177137083


From prr at openjdk.org  Tue Apr 25 22:50:23 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 25 Apr 2023 22:50:23 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <OCtVGOrNZ3OC_l5VEnLzDDETEj9CYkv5WSiErfumCfQ=.b2ac189b-4add-4d8f-b18d-8fd5e0aa3dfe@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <OCtVGOrNZ3OC_l5VEnLzDDETEj9CYkv5WSiErfumCfQ=.b2ac189b-4add-4d8f-b18d-8fd5e0aa3dfe@github.com>
Message-ID: <vw35QqhUG8TQsXDCvov1_zCsdz2gSWWIaqIoNT2_kyQ=.5bbd4fbf-d8f2-42c0-9ca0-ccf15fd6c32f@github.com>

On Wed, 19 Apr 2023 17:15:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update documentation for adressing comment on pull requests, with two changes to be discussed:
>>   
>>   - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
>>   - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.
>
> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1631:
> 
>> 1629:    * {@linkplain #getRaster() single tile} without checking
>> 1630:    * the passed values. No listeners are notified since the
>> 1631:    * returned tile is always checked out for writing.
> 
> similar to above

"This method" again.

> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1655:
> 
>> 1653:    * without checking the passed values. No listeners are notified
>> 1654:    * since the {@linkplain #getRaster() single tile} is always
>> 1655:    * checked out for writing.
> 
> similar to above

We have not quite word-for-word duplicated text here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1177137191
PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1177130655


From dnguyen at openjdk.org  Tue Apr 25 23:16:33 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 23:16:33 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
Message-ID: <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>

> This PR open sources a few more AWT DnD related tests

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra folders

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13653/files
  - new: https://git.openjdk.org/jdk/pull/13653/files/78b086ac..5435c254

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13653&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13653&range=00-01

  Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13653/head:pull/13653

PR: https://git.openjdk.org/jdk/pull/13653


From dnguyen at openjdk.org  Tue Apr 25 23:16:34 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Apr 2023 23:16:34 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests
In-Reply-To: <FimsrGu4cYDu2iUawXcPNtz0G5a5pdpBKO929EAsyg8=.aad9913c-c7c8-480e-962b-3743b997a721@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <FimsrGu4cYDu2iUawXcPNtz0G5a5pdpBKO929EAsyg8=.aad9913c-c7c8-480e-962b-3743b997a721@github.com>
Message-ID: <b3uuRITvqEPK4fyTb2L3wXeS_8Lg4qh1rhcXZFCmi0Y=.d3946430-b9b6-4805-8a0f-6c60e68a450c@github.com>

On Tue, 25 Apr 2023 22:08:21 GMT, Phil Race <prr at openjdk.org> wrote:

> The 1st 4 of these tests do not need their own directories since they are single file tests. The extra folder can be dropped

Sure, I removed the folders and placed the tests directly into the dnd folder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13653#issuecomment-1522530943


From serb at openjdk.org  Wed Apr 26 03:11:01 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 03:11:01 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer
 and Toolkit
In-Reply-To: <g1r7fE9UhnrD4ID7pJXySZYyTCZSLIsRg47tl14P8aE=.02d4ab2e-a408-4270-be01-1e396a08bf4e@github.com>
References: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
 <CqNqk1-1NkblJKuoRP2pjAFZ3v1alnrk2oevQJMumLQ=.ea18915a-3844-4a9a-887d-49ec36b46fc8@github.com>
 <g1r7fE9UhnrD4ID7pJXySZYyTCZSLIsRg47tl14P8aE=.02d4ab2e-a408-4270-be01-1e396a08bf4e@github.com>
Message-ID: <iLJ1HN5pI1dybrrYbN5p9L83S__YKWFpNpglea-amjA=.d5f29310-4e01-4c29-9199-dcb0dd333a2e@github.com>

On Tue, 25 Apr 2023 16:46:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/Toolkit/ToolkitListenerTest/ToolkitListenerTest.java line 100:
>> 
>>> 98: 
>>> 99:     public void eventDispatched(AWTEvent e) {
>>> 100:         System.err.println(e);
>> 
>> On what thread this will be executed?
>
> Surely it will be the EDT ? Why do you ask ?

it sets a couple of flags that will be used on the main thread, see "start()" above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1177282988


From psadhukhan at openjdk.org  Wed Apr 26 03:25:25 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Apr 2023 03:25:25 GMT
Subject: Integrated: 8306755: Open source few Swing JComponent and
 AbstractButton tests
In-Reply-To: <_drOTCJAcbqZa33sckkLYhZp3-l-kD4Kt6NskTozXsM=.66793e8a-91a4-4d5f-8e68-a4b8069aee7b@github.com>
References: <_drOTCJAcbqZa33sckkLYhZp3-l-kD4Kt6NskTozXsM=.66793e8a-91a4-4d5f-8e68-a4b8069aee7b@github.com>
Message-ID: <AAtLVzKBkefUA8kellgii1fCLSH9xuBetacoA4473Ik=.d0340b99-b8a8-4cfc-8220-e13fcd6b0c54@github.com>

On Tue, 25 Apr 2023 17:37:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This opensources few swing JComponent and AbstractButton tests

This pull request has now been integrated.

Changeset: f3e8bd1d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3e8bd1d1161772539f42405fc4fcb02259f5b66
Stats:     576 lines in 5 files changed: 576 ins; 0 del; 0 mod

8306755: Open source few Swing JComponent and AbstractButton tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13651


From psadhukhan at openjdk.org  Wed Apr 26 03:56:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Apr 2023 03:56:23 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v5]
In-Reply-To: <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
Message-ID: <Wlhu80qzXGqpxb2gNuNaO8Bdwl_yz1ui_iYevmDUOuw=.1922630f-98e4-4a52-b97d-44d98ae9835b@github.com>

On Mon, 24 Apr 2023 16:40:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> This open source AWT Mouse Info related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 39:

> 37: import java.awt.Robot;
> 38: 
> 39: import java.lang.reflect.InvocationTargetException;

guess it's not needed now..

-------------

PR Review: https://git.openjdk.org/jdk/pull/13573#pullrequestreview-1401104238
PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1177301504


From psadhukhan at openjdk.org  Wed Apr 26 03:56:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Apr 2023 03:56:23 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v4]
In-Reply-To: <vNo7ph0LyfWcApS3EnhChgaXEt6ExGPmfPVWa_bNWP0=.0f44ccfe-c32b-43bd-a58e-bb381e17b420@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
 <vNo7ph0LyfWcApS3EnhChgaXEt6ExGPmfPVWa_bNWP0=.0f44ccfe-c32b-43bd-a58e-bb381e17b420@github.com>
Message-ID: <zlQ_zH70Yph_iJkh8lJrjk8Fh8l34rk3U8UmIb2mpxE=.c60f1015-732d-4495-9e74-7b0d70426085@github.com>

On Tue, 25 Apr 2023 18:05:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source MenuItem AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Frame title set

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/java/awt/MenuItem/MenuSetLabelTest.java line 90:

> 88:             m.add(new MenuItem(s3));
> 89:         for (int i=0;i<10;i++)
> 90:             f.add(new MenuItem(s3));

please add a space before and after operator as in i = 0 for all these

-------------

PR Review: https://git.openjdk.org/jdk/pull/13589#pullrequestreview-1401106598
PR Review Comment: https://git.openjdk.org/jdk/pull/13589#discussion_r1177303322


From psadhukhan at openjdk.org  Wed Apr 26 04:09:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Apr 2023 04:09:55 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests [v2]
In-Reply-To: <OXgpaLIM_G4FAgilZyKEVFGAGo2c5hE3is3LzGYtH2M=.3fd10749-d2bd-4cde-b529-f22319515e8b@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <OXgpaLIM_G4FAgilZyKEVFGAGo2c5hE3is3LzGYtH2M=.3fd10749-d2bd-4cde-b529-f22319515e8b@github.com>
Message-ID: <zxDpWLBQQ1qRaleEuv5zMqwTbz2nzHCVe7pOnquBCOI=.4f246a66-c7fc-4e00-8ab4-c2edf6614b2b@github.com>

On Tue, 25 Apr 2023 16:26:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This PR open sources few AWT DnD related tests
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove endline. Add frame titles. Dispose in EDT.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13591#pullrequestreview-1401110574


From psadhukhan at openjdk.org  Wed Apr 26 04:09:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Apr 2023 04:09:56 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
Message-ID: <mk58ND260YEnfyNJvfdvA7WAH79UmvpIwg3SjxGibx0=.7ff771de-315b-42d9-b6c1-f881d8da1a7c@github.com>

On Tue, 25 Apr 2023 09:35:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/java/awt/LightweightComponent/LWClobberDragEvent.java line 60:

> 58:         LWClobberDragEvent test = new LWClobberDragEvent();
> 59:         try {
> 60:                 test.init();

Formatting issue

test/jdk/java/awt/LightweightComponent/LWClobberDragEvent.java line 88:

> 86:             frame.add(lc);
> 87:             frame.pack();
> 88:             frame.setLocationRelativeTo(null);

I amnot sure but pack and setLocationRelativeTo together was causing some issue of frame location getting updated/jumping around
 pointed out during one of my test review last time..please check..

-------------

PR Review: https://git.openjdk.org/jdk/pull/13633#pullrequestreview-1401112208
PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1177307524
PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1177308860


From duke at openjdk.org  Wed Apr 26 04:10:31 2023
From: duke at openjdk.org (duke)
Date: Wed, 26 Apr 2023 04:10:31 GMT
Subject: Withdrawn: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <ryq770i6xR6txJmvLGC2KLtYcKiSCf7zbDTQP0JJqP0=.cff39efb-1f5f-46d4-8a45-7d24ed17939b@github.com>

On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy <duke at openjdk.org> wrote:

> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
> 
> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
> 
> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
> 
> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
> 
> See also #6603, where this issue was discovered.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10565


From abhiscxk at openjdk.org  Wed Apr 26 05:11:23 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 05:11:23 GMT
Subject: RFR: 8306652: Open source AWT MenuItem related tests [v5]
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <g5NMin9Pa3X2l0R-vEi_C1fmPKkTAUP0CGX-OBkmaKI=.c3b7c407-716c-471b-8f02-6fdacbb0a716@github.com>

> This PR is to open source MenuItem AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Space added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13589/files
  - new: https://git.openjdk.org/jdk/pull/13589/files/3d07d952..eeb29f1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13589&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13589/head:pull/13589

PR: https://git.openjdk.org/jdk/pull/13589


From abhiscxk at openjdk.org  Wed Apr 26 05:37:54 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 05:37:54 GMT
Subject: Integrated: 8306652: Open source AWT MenuItem related tests
In-Reply-To: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
References: <HGeSB9a-efPTRMWXXPYaJfzuuS5nzSSHyoQR_mPMPoQ=.989a4497-eef4-4971-86f6-6a87a6fd8247@github.com>
Message-ID: <O87xvYJ9aJ04p49KOTC99hboPaR3GmCvtm8lI9PMc-U=.7ccda588-d9a7-487e-ad34-a23ebe89bb61@github.com>

On Fri, 21 Apr 2023 19:23:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source MenuItem AWT tests.

This pull request has now been integrated.

Changeset: ed1ebd24
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed1ebd242a4bb82a7074564ea96dc3d26b78f9e1
Stats:     326 lines in 4 files changed: 326 ins; 0 del; 0 mod

8306652: Open source AWT MenuItem related tests

Reviewed-by: prr, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/13589


From tr at openjdk.org  Wed Apr 26 06:06:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 06:06:23 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v6]
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <d4I7XqAViwRZVsawWD25lJ_q2N8tSvPTCytpZbSpHZw=.609ee7f6-72b3-4f74-b24e-ec839b0a24c2@github.com>

> This open source AWT Mouse Info related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13573/files
  - new: https://git.openjdk.org/jdk/pull/13573/files/86ba000c..52db1ad1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13573&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13573/head:pull/13573

PR: https://git.openjdk.org/jdk/pull/13573


From tr at openjdk.org  Wed Apr 26 06:09:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 06:09:53 GMT
Subject: RFR: 8306072: Open source several AWT MouseInfo related tests [v5]
In-Reply-To: <Wlhu80qzXGqpxb2gNuNaO8Bdwl_yz1ui_iYevmDUOuw=.1922630f-98e4-4a52-b97d-44d98ae9835b@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
 <MqRNyfaEtqkf-G5UaYOEJZHbbWl1JiZdTJLLy_H3vaI=.3402abb1-a81f-4e62-a3df-abc63007a783@github.com>
 <Wlhu80qzXGqpxb2gNuNaO8Bdwl_yz1ui_iYevmDUOuw=.1922630f-98e4-4a52-b97d-44d98ae9835b@github.com>
Message-ID: <mD3-mh_tS7Z6sd7Ln_osCQM0GvI4LVWBOkNBbiJnycI=.c7ec72f4-4bc5-4520-bef4-025d9e4591a8@github.com>

On Wed, 26 Apr 2023 03:39:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/java/awt/MouseInfo/ContainerMousePositionTest.java line 39:
> 
>> 37: import java.awt.Robot;
>> 38: 
>> 39: import java.lang.reflect.InvocationTargetException;
> 
> guess it's not needed now..

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13573#discussion_r1177364036


From tr at openjdk.org  Wed Apr 26 06:09:55 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 06:09:55 GMT
Subject: Integrated: 8306072: Open source several AWT MouseInfo related tests
In-Reply-To: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
References: <ywgQS5SGMnX0US5_UNAVENYycMETyIEBbQXsHzAie3g=.957142f9-02fb-4304-b737-bb1ada2f1114@github.com>
Message-ID: <ZJuU3DiTZ7k1-fG6SaYqeX0amQ10E2iHd-ck7bBZtrA=.58582973-d4e8-45e3-bdf0-7a3361217f63@github.com>

On Fri, 21 Apr 2023 05:19:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> This open source AWT Mouse Info related tests.

This pull request has now been integrated.

Changeset: 44d9f55d
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44d9f55d0b3c469988be6f1c47f0cfbc433c4490
Stats:     213 lines in 2 files changed: 213 ins; 0 del; 0 mod

8306072: Open source several AWT MouseInfo related tests

Reviewed-by: serb, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/13573


From abhiscxk at openjdk.org  Wed Apr 26 06:27:53 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 06:27:53 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v3]
In-Reply-To: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
Message-ID: <oDCts7pxVIl4D-Nh3OU2xYppwb1CsfOt7mxJObSGsgo=.34ad3c61-949d-428f-883b-20f2de693006@github.com>

> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13633/files
  - new: https://git.openjdk.org/jdk/pull/13633/files/eebe20a6..009b83ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13633&range=01-02

  Stats: 11 lines in 2 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13633/head:pull/13633

PR: https://git.openjdk.org/jdk/pull/13633


From abhiscxk at openjdk.org  Wed Apr 26 06:28:54 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 06:28:54 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <mk58ND260YEnfyNJvfdvA7WAH79UmvpIwg3SjxGibx0=.7ff771de-315b-42d9-b6c1-f881d8da1a7c@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
 <mk58ND260YEnfyNJvfdvA7WAH79UmvpIwg3SjxGibx0=.7ff771de-315b-42d9-b6c1-f881d8da1a7c@github.com>
Message-ID: <Yzvt4sZKQBOUWj08rjD4idkGpi8vlmJPDxToFphehPw=.8a51bb33-25bf-49f5-9179-60efc0592070@github.com>

On Wed, 26 Apr 2023 03:58:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I amnot sure but pack and setLocationRelativeTo together was causing some issue of frame location getting updated/jumping around pointed out during one of my test review last time..please check..

It didn't cause any issues for me as of now. Leaving it as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1177385894


From abhiscxk at openjdk.org  Wed Apr 26 06:29:29 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 06:29:29 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <nmm2C1g-XFqxc0R8iUX1r9xHRKOW3pwrj1GjbM0z05c=.ebde057a-a49b-42e9-9ea7-ca0134b1b1d6@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
 <nmm2C1g-XFqxc0R8iUX1r9xHRKOW3pwrj1GjbM0z05c=.ebde057a-a49b-42e9-9ea7-ca0134b1b1d6@github.com>
Message-ID: <7Z6T-gt0yDXqeW1fEpC6hjqU3QOgniDhJnK9DBWhweY=.a128ee53-f194-484d-b4dc-0b7433e08ebc@github.com>

On Tue, 25 Apr 2023 16:49:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/java/awt/LightweightComponent/LightweightDragTest.java line 113:
> 
>> 111:        }
>> 112:        rb.mouseRelease(InputEvent.BUTTON1_MASK);
>> 113:        if (c.isInside || !c2.isInside) {
> 
> Do we set these props on EDT in the processEvent below and read here w/o synchronization?

Accessing these props on EDT now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1177385374


From mkartashev at openjdk.org  Wed Apr 26 10:29:00 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 26 Apr 2023 10:29:00 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v5]
In-Reply-To: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
Message-ID: <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com>

> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
> 
> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
> 
> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Cache insets in X11GraphicsDevice instead of storing them all in XToolkit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13346/files
  - new: https://git.openjdk.org/jdk/pull/13346/files/02b6ae9d..1db1431c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13346&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13346&range=03-04

  Stats: 40 lines in 2 files changed: 36 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13346/head:pull/13346

PR: https://git.openjdk.org/jdk/pull/13346


From mkartashev at openjdk.org  Wed Apr 26 10:29:01 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 26 Apr 2023 10:29:01 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v5]
In-Reply-To: <KzbEb36-WJD-MCL2IR78rGTanfD5MD9NBpu7gqMTxAY=.e4057fe5-7afb-47f1-9927-fdb2f75459b1@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <FozbUnILg_uNR2ANovFQ_c753jfYsxur43rhU7dVowU=.44a7c00a-9ca7-4bae-8d21-be4b744e85d1@github.com>
 <oNBqb6bgWncXEb507HhGlwiehsDLhulQHF3cjoR7OXo=.366340e8-f8a4-4292-bcd3-80cd287c7a69@github.com>
 <_qGt7-qv-gvD1Th2sviP4baeED68Me4kEitOL97bCXU=.7c040912-362d-4d79-a39b-35af1eaa0221@github.com>
 <h_gVI1QtGlBJLzpHhepiB2Vt6aVQibCQrwFwJkzLLvU=.05538579-8431-4d0b-a0ef-6d33eb00c93f@github.com>
 <ARN9hx1kDtJk01JkFF9OHtJbVNbUXaL52yujttRttBg=.9e53f587-4825-48d0-aebc-c75e91d68c5b@github.com>
 <n1aD0-m9lIT6m4zYLM2bS0X7Z6p4I-oFYuXcYreUL3Q=.73f70fe5-2383-43d4-8c25-b40cb5bc0515@github.com>
 <KzbEb36-WJD-MCL2IR78rGTanfD5MD9NBpu7gqMTxAY=.e4057fe5-7afb-47f1-9927-fdb2f75459b1@github.com>
Message-ID: <vgGlwn3x1SRgypqHghRsK_a5VwzP6MeUS8UtZeLUg0Q=.0ad9a899-9cac-49fa-b7a3-95cd991c322b@github.com>

On Fri, 21 Apr 2023 20:17:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> You do not need to move the code around, just cache it in the GC instead of the hashmap, and then re-cache it by some notification.

I implemented something along these lines, please, have a look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1177657966


From duke at openjdk.org  Wed Apr 26 14:10:54 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 26 Apr 2023 14:10:54 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
Message-ID: <VBsOwSb-EEhqYjah6zp2XWosxz9L1Bv5XdjEi5VnbyU=.0f4869c1-bed6-4852-8ff4-aa42148ef310@github.com>

On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>   
>   Remove space.
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Delay due to the reorganization of my contribution schedule caused by new requests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9825#issuecomment-1523464885


From tr at openjdk.org  Wed Apr 26 14:40:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 14:40:53 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>

> Open source few AWT ScrollPane related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated ScrollPaneWindowsTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13621/files
  - new: https://git.openjdk.org/jdk/pull/13621/files/ffad753e..57f707a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=01-02

  Stats: 56 lines in 1 file changed: 18 ins; 17 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621

PR: https://git.openjdk.org/jdk/pull/13621


From tr at openjdk.org  Wed Apr 26 14:41:24 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 14:41:24 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <NbSOrdMpvzUw82stSqMzAoFw2suqQT9eHFmK-dZuMls=.82b335fe-b7a8-4635-956a-16e12ca694ca@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <m_-9QnYPCsZkyGc0PfhVcdVTzDQK3XnDP2kha8FRP9E=.5387b0cd-52df-4f91-8ff2-8890a5cd8436@github.com>
 <oQGm2svCP6JZC6JspFyvIqJMZqEmlGZ3mcI9_DTqgvI=.ac21179e-df77-4531-8b47-efd297ae5b5d@github.com>
 <mlQX211c9t2Iq4K3OvuWc1x5Sm5r8W9kWVkkMvYJWnE=.a5ea513b-3959-49bc-9a52-dcca7bc8cfc8@github.com>
 <OoILiqqyrrZxpmAUXtxXc4TDjYl5N9rooW9-66ag6VI=.fbb60db9-152d-46a1-80ad-09e7dd597246@github.com>
 <XihneKHzAQKF5V-GJU6e8eXwIl-jiRBVoLzNk686Ds0=.c28430ea-11fe-49c4-9415-e03cd3f3e89d@github.com>
 <NbSOrdMpvzUw82stSqMzAoFw2suqQT9eHFmK-dZuMls=.82b335fe-b7a8-4635-956a-16e12ca694ca@github.com>
Message-ID: <hN4Q5OkUDvVSt-dU1f3FpYZArJcjZmkdeh6nzhdKREo=.6715b043-b556-432a-9250-aab1f683e4a4@github.com>

On Tue, 25 Apr 2023 17:08:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> The bug was raised specifically for Win2000, also states that it is not reproducible for Windows NT 4.0 and Windows 98. I don't think that this test is specific to Win2000, in JBS they mention about a feature being added from Win2000, hence the fix wasn't applicable to previous versions.
>
> If you ask me for my guess, this check was saying "something new was introduced in Windows 2000" (note that NT 4 and Windows 98 PRE-DATE Windows 2000). And all the other OSes they are looking for come AFTER Windows 2000.
> So they wanted to test on Windows 2000 and LATER.
> However this exact match requirement means that this test has surely been skipped for the last ~ 10 years .. whenever we stopped testing on XP .. 
> And until you remove the check I suspect you have no idea if this test passes today on Windows 10, or is relevant.
> You will need to remove the check, run the test locally and observe, and then run on the CI test system.
> Probably its still valid but you need to be sure.

I tested locally as well as in CI system, all the run's were green.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177956601


From tr at openjdk.org  Wed Apr 26 14:43:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 14:43:53 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v3]
In-Reply-To: <oDCts7pxVIl4D-Nh3OU2xYppwb1CsfOt7mxJObSGsgo=.34ad3c61-949d-428f-883b-20f2de693006@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <oDCts7pxVIl4D-Nh3OU2xYppwb1CsfOt7mxJObSGsgo=.34ad3c61-949d-428f-883b-20f2de693006@github.com>
Message-ID: <g7nLT09SjXV1BHaznHoNOegPfZuVXsat6zT0k99AXHM=.fd583d77-dbee-4a2d-9c14-792c12707fb6@github.com>

On Wed, 26 Apr 2023 06:27:53 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

It looks good to me.

test/jdk/java/awt/Layout/InsetsTest.java line 91:

> 89: 
> 90:     public int returnLeftInset() {
> 91:         // Getting the left inset value

Can remove this comment as method name is self explanatory.

-------------

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13633#pullrequestreview-1402133392
PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1177966255


From tr at openjdk.org  Wed Apr 26 14:46:27 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 14:46:27 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
Message-ID: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>

Open source few AWT TextArea related tests.

-------------

Commit messages:
 - Open sourced TextArea tests

Changes: https://git.openjdk.org/jdk/pull/13670/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13670&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306640
  Stats: 437 lines in 4 files changed: 437 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13670.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13670/head:pull/13670

PR: https://git.openjdk.org/jdk/pull/13670


From aivanov at openjdk.org  Wed Apr 26 14:46:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 26 Apr 2023 14:46:58 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>
Message-ID: <RE-YW9XpHS8MExRz5tA_AXt0v8lwg4M69lfVs5acQPk=.b3f52aa7-e84a-406c-add5-8e85c2c02c28@github.com>

On Wed, 26 Apr 2023 14:40:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated ScrollPaneWindowsTest.java

test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 80:

> 78:                     Thread.sleep(5000);
> 79:                 } catch (InterruptedException ie) {
> 80:                 }

This `sleep` blocks EDT. Is it intended?

test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 87:

> 85: 
> 86:             Point buttonLoc = button.getLocationOnScreen();
> 87:             Dimension buttonSize = button.getSize();

Both `getLocationOnScreen` and `getSize` should also be called on EDT?

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 53:

> 51:     Frame frame;
> 52:     Insets paneInsets;
> 53:     public static Object LOCK = new Object();

The lock object should be `final`.

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 62:

> 60:             System.out.println("This test is for Windows 2000 and above.");
> 61:             return;
> 62:         }

Shall this be dropped too? Java won't start on Windows versions before Vista (6.0), so does it serve a purpose other than a historical reasons?

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 70:

> 68:     public void init() throws Exception {
> 69:         EventQueue.invokeAndWait(() -> {
> 70:             frame = new Frame();

Suggestion:

            frame = new Frame("ScrollPaneWindowsTest");

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 81:

> 79:         hScroll = (ScrollPaneAdjustable) sp.getHAdjustable();
> 80:         vScroll.addAdjustmentListener(this);
> 81:         hScroll.addAdjustmentListener(this);

ScrollPane should be created inside `invokeAndWait` block, listeners should be added on EDT too.

test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 31:

> 29: */
> 30: 
> 31: import java.awt.*;

Avoid wildcard imports.

test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 61:

> 59:                 pa.add("East", new Label("East", Label.RIGHT));
> 60:                 sp.add(pa);
> 61:                 frame = new Frame();

Suggestion:

                frame = new Frame("ScrollPositionIntact");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177963376
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177969918
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177971770
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177974445
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177977077
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177976182
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177979671
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177980405


From aivanov at openjdk.org  Wed Apr 26 14:46:26 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 26 Apr 2023 14:46:26 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v2]
In-Reply-To: <FKGzT-ruG-F-1yCwdN_Oifn9prPcNTp1mwTED5MKbxk=.5ece554a-14f0-44ab-a919-886573a5f754@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <FKGzT-ruG-F-1yCwdN_Oifn9prPcNTp1mwTED5MKbxk=.5ece554a-14f0-44ab-a919-886573a5f754@github.com>
Message-ID: <PlYjmZGkMZ4hOT9fhKYSRgb46p8YIbk9RhIfO9n6z3M=.281891d0-d0a3-4b34-adbe-9f4723f37ecd@github.com>

On Tue, 25 Apr 2023 15:43:18 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated based on Review Comments
>  - Updated based on Review Comments

test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 48:

> 46:     public Frame frame;
> 47:     public int count = 0;
> 48:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {

Suggestion:

    public int count = 0;

    public static void main(String[] args)
            throws InterruptedException, InvocationTargetException {

Add a blank line between fields and method, wrap `throws` clause to fit into 80-column limit.

test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 68:

> 66:                 frame.add(scrollpane);
> 67:         });
> 68:         scrollpane.getVAdjustable().addAdjustmentListener(this);

The lambda expression has incorrect indentation.

You should add the listener on EDT too.

test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 31:

> 29:   shown for the first time with SCROLLBARS_AS_NEEDED style
> 30:   @key headful
> 31: */

In majority of cases, the tags have a leading asterisk.

test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 57:

> 55:         robot = new Robot();
> 56:         EventQueue.invokeAndWait(() -> {
> 57:             f = new Frame();

Suggestion:

            f = new Frame("ScrollPaneExtraScrollBar");

As suggested in other reviews, let's add a title to the frame with the name of the test.

test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 71:

> 69:             robot.delay(100);
> 70:             robot.waitForIdle();
> 71:             Rectangle r = f.getBounds();

You may want to call `getBounds()` on EDT.

test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 77:

> 75:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 76: 
> 77:             Thread.sleep(1000);

What you want here is
Suggestion:

            Robot.waitForIdle();

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 80:

> 78:             Properties prop = System.getProperties();
> 79:             String os = prop.getProperty("os.name", "");
> 80:             if (os != null && (os.indexOf("98") == -1)) {

Shall we drop the filter for Windows 98? Java cannot be run on Windows 9x for quite a long time, so it doesn't make sense to preserve this condition.

test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 95:

> 93:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 94: 
> 95:    //         Toolkit.getDefaultToolkit().sync();

Instead of commenting out the line, remove it.

test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 120:

> 118:     private static class Semaphore {
> 119:         volatile boolean state = false;
> 120:         Object lock = new Object();

Since it's a lock object, it should be `final`.

test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 121:

> 119:         volatile boolean state = false;
> 120:         Object lock = new Object();
> 121:         volatile int waiting = 0;

Why are both `state` and `waiting` marked as volatile? Either is accessed from synchronized blocks protected by `lock` except for `getState` which should also use the `lock` object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177959567
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177961343
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177957536
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177921389
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177922967
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177924261
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177938458
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177939984
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177944902
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1177950769


From tr at openjdk.org  Wed Apr 26 16:58:22 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 16:58:22 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <RE-YW9XpHS8MExRz5tA_AXt0v8lwg4M69lfVs5acQPk=.b3f52aa7-e84a-406c-add5-8e85c2c02c28@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>
 <RE-YW9XpHS8MExRz5tA_AXt0v8lwg4M69lfVs5acQPk=.b3f52aa7-e84a-406c-add5-8e85c2c02c28@github.com>
Message-ID: <rGaha8Uq29wpOrXavNC4a1muYqVg9mbNDSVUP7Z_LTA=.1712713c-5516-4815-b38f-d30ac2d887e0@github.com>

On Wed, 26 Apr 2023 14:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated ScrollPaneWindowsTest.java
>
> test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 80:
> 
>> 78:                     Thread.sleep(5000);
>> 79:                 } catch (InterruptedException ie) {
>> 80:                 }
> 
> This `sleep` blocks EDT. Is it intended?

Yeah, I guess 5000 might not be required 1000 might be fine, but either delay or sleep is required I feel.

> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 87:
> 
>> 85: 
>> 86:             Point buttonLoc = button.getLocationOnScreen();
>> 87:             Dimension buttonSize = button.getSize();
> 
> Both `getLocationOnScreen` and `getSize` should also be called on EDT?

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 53:
> 
>> 51:     Frame frame;
>> 52:     Insets paneInsets;
>> 53:     public static Object LOCK = new Object();
> 
> The lock object should be `final`.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 62:
> 
>> 60:             System.out.println("This test is for Windows 2000 and above.");
>> 61:             return;
>> 62:         }
> 
> Shall this be dropped too? Java won't start on Windows versions before Vista (6.0), so does it serve a purpose other than a historical reasons?

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 70:
> 
>> 68:     public void init() throws Exception {
>> 69:         EventQueue.invokeAndWait(() -> {
>> 70:             frame = new Frame();
> 
> Suggestion:
> 
>             frame = new Frame("ScrollPaneWindowsTest");

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 81:
> 
>> 79:         hScroll = (ScrollPaneAdjustable) sp.getHAdjustable();
>> 80:         vScroll.addAdjustmentListener(this);
>> 81:         hScroll.addAdjustmentListener(this);
> 
> ScrollPane should be created inside `invokeAndWait` block, listeners should be added on EDT too.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 31:
> 
>> 29: */
>> 30: 
>> 31: import java.awt.*;
> 
> Avoid wildcard imports.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 61:
> 
>> 59:                 pa.add("East", new Label("East", Label.RIGHT));
>> 60:                 sp.add(pa);
>> 61:                 frame = new Frame();
> 
> Suggestion:
> 
>                 frame = new Frame("ScrollPositionIntact");

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178149780
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178149893
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178149988
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178150098
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178150275
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178150178
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178150376
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178150724


From tr at openjdk.org  Wed Apr 26 16:57:29 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Apr 2023 16:57:29 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v2]
In-Reply-To: <PlYjmZGkMZ4hOT9fhKYSRgb46p8YIbk9RhIfO9n6z3M=.281891d0-d0a3-4b34-adbe-9f4723f37ecd@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <FKGzT-ruG-F-1yCwdN_Oifn9prPcNTp1mwTED5MKbxk=.5ece554a-14f0-44ab-a919-886573a5f754@github.com>
 <PlYjmZGkMZ4hOT9fhKYSRgb46p8YIbk9RhIfO9n6z3M=.281891d0-d0a3-4b34-adbe-9f4723f37ecd@github.com>
Message-ID: <9e2yWcb08BuPSJ6zuFk4hpIK8aeWho1jWScSjEIT_eI=.02b7de4d-a9ca-4a9e-8784-460725890688@github.com>

On Wed, 26 Apr 2023 14:22:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated based on Review Comments
>>  - Updated based on Review Comments
>
> test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 48:
> 
>> 46:     public Frame frame;
>> 47:     public int count = 0;
>> 48:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
> 
> Suggestion:
> 
>     public int count = 0;
> 
>     public static void main(String[] args)
>             throws InterruptedException, InvocationTargetException {
> 
> Add a blank line between fields and method, wrap `throws` clause to fit into 80-column limit.

Updated.

> test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 68:
> 
>> 66:                 frame.add(scrollpane);
>> 67:         });
>> 68:         scrollpane.getVAdjustable().addAdjustmentListener(this);
> 
> The lambda expression has incorrect indentation.
> 
> You should add the listener on EDT too.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 31:
> 
>> 29:   shown for the first time with SCROLLBARS_AS_NEEDED style
>> 30:   @key headful
>> 31: */
> 
> In majority of cases, the tags have a leading asterisk.

But I have been doing without leading asterisk for all the open sourcing, let me keep it this way.

> test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 57:
> 
>> 55:         robot = new Robot();
>> 56:         EventQueue.invokeAndWait(() -> {
>> 57:             f = new Frame();
> 
> Suggestion:
> 
>             f = new Frame("ScrollPaneExtraScrollBar");
> 
> As suggested in other reviews, let's add a title to the frame with the name of the test.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 71:
> 
>> 69:             robot.delay(100);
>> 70:             robot.waitForIdle();
>> 71:             Rectangle r = f.getBounds();
> 
> You may want to call `getBounds()` on EDT.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 77:
> 
>> 75:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 76: 
>> 77:             Thread.sleep(1000);
> 
> What you want here is
> Suggestion:
> 
>             Robot.waitForIdle();

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 80:
> 
>> 78:             Properties prop = System.getProperties();
>> 79:             String os = prop.getProperty("os.name", "");
>> 80:             if (os != null && (os.indexOf("98") == -1)) {
> 
> Shall we drop the filter for Windows 98? Java cannot be run on Windows 9x for quite a long time, so it doesn't make sense to preserve this condition.

Yeah, we can drop it if its not supported.

> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 95:
> 
>> 93:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 94: 
>> 95:    //         Toolkit.getDefaultToolkit().sync();
> 
> Instead of commenting out the line, remove it.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 120:
> 
>> 118:     private static class Semaphore {
>> 119:         volatile boolean state = false;
>> 120:         Object lock = new Object();
> 
> Since it's a lock object, it should be `final`.

Updated.

> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 121:
> 
>> 119:         volatile boolean state = false;
>> 120:         Object lock = new Object();
>> 121:         volatile int waiting = 0;
> 
> Why are both `state` and `waiting` marked as volatile? Either is accessed from synchronized blocks protected by `lock` except for `getState` which should also use the `lock` object.

I don't think its required to be volatile, not sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178146823
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178147063
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178146679
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178140844
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178141008
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178141210
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178141876
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178142070
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178142245
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178145730


From serb at openjdk.org  Wed Apr 26 17:51:27 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 17:51:27 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
Message-ID: <zggaADImNXxfePbdzjP4MYr_WDKkJSHFwCX5JmJRWkc=.a5f9d859-3060-4fc4-8ffe-f3bea980de23@github.com>

On Tue, 25 Apr 2023 23:16:33 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This PR open sources a few more AWT DnD related tests
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra folders

test/jdk/java/awt/dnd/RejectDragDropActionTest.java line 114:

> 112:         }
> 113: 
> 114:         if (incorrectActionDetected) {

incorrectActionDetected is set on one thread an used on another, same for "frame" in other tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178202698


From serb at openjdk.org  Wed Apr 26 17:52:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 17:52:22 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
Message-ID: <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>

On Wed, 26 Apr 2023 14:23:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT TextArea related tests.

test/jdk/java/awt/TextArea/ReplaceRangeTest.java line 26:

> 24:   @test
> 25:   @bug 5025532
> 26:   @requires (os.family == "windows")

Is this test can pass on windows only or we can run it on all platform?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13670#discussion_r1178199731


From serb at openjdk.org  Wed Apr 26 18:03:24 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 18:03:24 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v3]
In-Reply-To: <oDCts7pxVIl4D-Nh3OU2xYppwb1CsfOt7mxJObSGsgo=.34ad3c61-949d-428f-883b-20f2de693006@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <oDCts7pxVIl4D-Nh3OU2xYppwb1CsfOt7mxJObSGsgo=.34ad3c61-949d-428f-883b-20f2de693006@github.com>
Message-ID: <w86DPzPUijZZSpDZ_iQQr-fXJJa0NKriv2vkhapcKjw=.e9c0fabf-513e-441a-9332-e109f8ef0f83@github.com>

On Wed, 26 Apr 2023 06:27:53 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13633#pullrequestreview-1402509142


From prr at openjdk.org  Wed Apr 26 18:05:23 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Apr 2023 18:05:23 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <rGaha8Uq29wpOrXavNC4a1muYqVg9mbNDSVUP7Z_LTA=.1712713c-5516-4815-b38f-d30ac2d887e0@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>
 <RE-YW9XpHS8MExRz5tA_AXt0v8lwg4M69lfVs5acQPk=.b3f52aa7-e84a-406c-add5-8e85c2c02c28@github.com>
 <rGaha8Uq29wpOrXavNC4a1muYqVg9mbNDSVUP7Z_LTA=.1712713c-5516-4815-b38f-d30ac2d887e0@github.com>
Message-ID: <4EvaVkV6tssgpo45Oyzz6gqY46MrG6BLdupwixdVfyA=.6e10be9a-7fa1-4312-a4c6-5cb50a38d5de@github.com>

On Wed, 26 Apr 2023 16:49:56 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 80:
>> 
>>> 78:                     Thread.sleep(5000);
>>> 79:                 } catch (InterruptedException ie) {
>>> 80:                 }
>> 
>> This `sleep` blocks EDT. Is it intended?
>
> Yeah, I guess 5000 might not be required 1000 might be fine, but either delay or sleep is required I feel.

It seems just wrong to me. This sleep should be on the main thread after returning from invokeAndWait

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178213360


From serb at openjdk.org  Wed Apr 26 18:04:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 18:04:53 GMT
Subject: RFR: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests [v2]
In-Reply-To: <Yzvt4sZKQBOUWj08rjD4idkGpi8vlmJPDxToFphehPw=.8a51bb33-25bf-49f5-9179-60efc0592070@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
 <57i7pjqYGM9IZqM7_XHXlqzbqqZLBXhtG9dKnSgX7E4=.321cb97d-5762-4612-bd87-6820599e3058@github.com>
 <mk58ND260YEnfyNJvfdvA7WAH79UmvpIwg3SjxGibx0=.7ff771de-315b-42d9-b6c1-f881d8da1a7c@github.com>
 <Yzvt4sZKQBOUWj08rjD4idkGpi8vlmJPDxToFphehPw=.8a51bb33-25bf-49f5-9179-60efc0592070@github.com>
Message-ID: <pqBDK7aXRAub0iT58h_Tlz2BF0UOu1vHziol9im9v6k=.bca41b6b-98db-4e7b-b283-ca3c367af56a@github.com>

On Wed, 26 Apr 2023 06:07:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/java/awt/LightweightComponent/LWClobberDragEvent.java line 88:
>> 
>>> 86:             frame.add(lc);
>>> 87:             frame.pack();
>>> 88:             frame.setLocationRelativeTo(null);
>> 
>> I amnot sure but pack and setLocationRelativeTo together was causing some issue of frame location getting updated/jumping around
>>  pointed out during one of my test review last time..please check..
>
>> I amnot sure but pack and setLocationRelativeTo together was causing some issue of frame location getting updated/jumping around pointed out during one of my test review last time..please check..
> 
> It didn't cause any issues for me as of now. Leaving it as it is.

it could cause a problem if called in a different order, setLocationRelativeTo then pack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13633#discussion_r1178208629


From prr at openjdk.org  Wed Apr 26 18:16:23 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Apr 2023 18:16:23 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <zggaADImNXxfePbdzjP4MYr_WDKkJSHFwCX5JmJRWkc=.a5f9d859-3060-4fc4-8ffe-f3bea980de23@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
 <zggaADImNXxfePbdzjP4MYr_WDKkJSHFwCX5JmJRWkc=.a5f9d859-3060-4fc4-8ffe-f3bea980de23@github.com>
Message-ID: <grnv86W8h6axj20dwer6WIOpalOPiClaJFbOkJXgdnI=.3ac177a0-cc25-4bc5-a70b-701a60631f29@github.com>

On Wed, 26 Apr 2023 17:37:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra folders
>
> test/jdk/java/awt/dnd/RejectDragDropActionTest.java line 114:
> 
>> 112:         }
>> 113: 
>> 114:         if (incorrectActionDetected) {
> 
> incorrectActionDetected is set on one thread an used on another, same for "frame" in other tests.

meaning you are suggesting they need to be volatile ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178221519


From dnguyen at openjdk.org  Wed Apr 26 18:18:58 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 26 Apr 2023 18:18:58 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests
Message-ID: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>

This PR open sources more AWT DnD related tests

-------------

Commit messages:
 - Initial test move

Changes: https://git.openjdk.org/jdk/pull/13674/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13674&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306681
  Stats: 545 lines in 7 files changed: 545 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13674/head:pull/13674

PR: https://git.openjdk.org/jdk/pull/13674


From abhiscxk at openjdk.org  Wed Apr 26 19:25:55 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 19:25:55 GMT
Subject: Integrated: 8306409: Open source AWT KeyBoardFocusManger,
 LightWeightComponent related tests
In-Reply-To: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
References: <QpL85dw0J6BrC0Fd95AgXJSzOseUqORrzuDoGaM8qgY=.b6b2ff79-ce40-4791-8400-62901f75d153@github.com>
Message-ID: <YWjrhZ-OQdfBulaG4lPWBB9Kwg2iCYPr354RbVAkn-E=.7e12cae8-d9d8-4498-8a32-8e83bb0e75b6@github.com>

On Tue, 25 Apr 2023 07:07:41 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source Keyboard Focus Manager, Light Weight Component and few other AWT tests.

This pull request has now been integrated.

Changeset: 732179ca
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/732179ca84ee1dab6530255c33de7f35cab649c2
Stats:     615 lines in 6 files changed: 615 ins; 0 del; 0 mod

8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests

Reviewed-by: psadhukhan, tr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13633


From duke at openjdk.org  Wed Apr 26 19:58:23 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 26 Apr 2023 19:58:23 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
Message-ID: <XWv9GS6rj86MpmLPYEDmyVQRAxw1vxHhOhMgg2UlToY=.3c5e95cc-b321-4177-8ab8-106287b9d663@github.com>

On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.

Delay due to the reorganization of my contribution schedule caused by new requests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10317#issuecomment-1523951974


From prr at openjdk.org  Wed Apr 26 20:09:22 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Apr 2023 20:09:22 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests
In-Reply-To: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
Message-ID: <OiJkb9mx9aW2LXmESbiJrxK3Xc9S924YPPA_jDz1vXg=.49e98ea2-219b-42b1-aed9-25634f39536f@github.com>

On Wed, 26 Apr 2023 18:00:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources more AWT DnD related tests

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13674#pullrequestreview-1402709469


From abhiscxk at openjdk.org  Wed Apr 26 20:11:58 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Apr 2023 20:11:58 GMT
Subject: RFR: 8306850: Open source AWT Model related tests
Message-ID: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>

This PR is to open source Modal related AWT tests.

-------------

Commit messages:
 - Open source Modal AWT tests

Changes: https://git.openjdk.org/jdk/pull/13676/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13676&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306850
  Stats: 1053 lines in 6 files changed: 1053 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13676/head:pull/13676

PR: https://git.openjdk.org/jdk/pull/13676


From serb at openjdk.org  Wed Apr 26 22:20:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 22:20:54 GMT
Subject: RFR: 8306850: Open source AWT Model related tests
In-Reply-To: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
References: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
Message-ID: <sMYrQ9W7bLS9iZdeBo8VYKFUqeLbuLbj0-myLFEmN7w=.98106a05-8516-4a9d-b4b3-87c300b19fa0@github.com>

On Wed, 26 Apr 2023 19:48:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source Modal related AWT tests.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13676#pullrequestreview-1402893878


From serb at openjdk.org  Wed Apr 26 22:22:23 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 22:22:23 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v5]
In-Reply-To: <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com>
Message-ID: <z1PP0KuBicaX-6AIr8zLr-dLemV34v9_AbOG0wMbh48=.55ad4ae4-3ab6-4d6f-80a3-e209810736e9@github.com>

On Wed, 26 Apr 2023 10:29:00 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish.
>> 
>> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration.
>> 
>> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cache insets in X11GraphicsDevice instead of storing them all in XToolkit

src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 894:

> 892:             Insets insets = device.getInsets();
> 893:             if (insets == null) {
> 894:                 insets = getScreenInsetsImpl(gc);

Is it possible to set insets in the device constructor and update it on a callback? In this case, this method will be just an accessor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1178444863


From serb at openjdk.org  Wed Apr 26 22:21:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Apr 2023 22:21:53 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests
In-Reply-To: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
Message-ID: <xHFPWxbJMWKT-Afyq9CX55CDt5CRsYN28Uh1iFK8kTI=.a896fa5f-4a3e-46fc-bae0-fac6ff28f9aa@github.com>

On Wed, 26 Apr 2023 18:00:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources more AWT DnD related tests

test/jdk/java/awt/dnd/ZeroFormatTransferableTest.java line 82:

> 80:         throw new UnsupportedFlavorException(df);
> 81:     }
> 82: }

There is no new line at the end of each file?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13674#discussion_r1178446243


From dnguyen at openjdk.org  Wed Apr 26 22:48:30 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 26 Apr 2023 22:48:30 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests [v2]
In-Reply-To: <xHFPWxbJMWKT-Afyq9CX55CDt5CRsYN28Uh1iFK8kTI=.a896fa5f-4a3e-46fc-bae0-fac6ff28f9aa@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
 <xHFPWxbJMWKT-Afyq9CX55CDt5CRsYN28Uh1iFK8kTI=.a896fa5f-4a3e-46fc-bae0-fac6ff28f9aa@github.com>
Message-ID: <-tnHRdaiPMBsjF0F381Asp_b4ZYjFxRmpKw8EtVzyac=.33aaa5d3-8bf7-43f8-b9e5-0c0be74eedbc@github.com>

On Wed, 26 Apr 2023 22:11:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add endline
>
> test/jdk/java/awt/dnd/ZeroFormatTransferableTest.java line 82:
> 
>> 80:         throw new UnsupportedFlavorException(df);
>> 81:     }
>> 82: }
> 
> There is no new line at the end of each file?

I had confused a previous PR review comment about extra lines. I re-added the newline at the end of all files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13674#discussion_r1178458771


From dnguyen at openjdk.org  Wed Apr 26 22:48:24 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 26 Apr 2023 22:48:24 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests [v2]
In-Reply-To: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
Message-ID: <UTvXqdBIEXnpCnthLKr_KmeL14pUcKW042Np4GbF0Ug=.0c87339c-7bb3-4e67-b286-8e7be2350c13@github.com>

> This PR open sources more AWT DnD related tests

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add endline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13674/files
  - new: https://git.openjdk.org/jdk/pull/13674/files/d0ff637f..c750dde5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13674&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13674&range=00-01

  Stats: 7 lines in 6 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13674/head:pull/13674

PR: https://git.openjdk.org/jdk/pull/13674


From acobbs at openjdk.org  Wed Apr 26 22:51:58 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 26 Apr 2023 22:51:58 GMT
Subject: Integrated: 8071693: Introspector ignores default interface methods
In-Reply-To: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
Message-ID: <CHDCp6K6uYPVcbSdLQWVeA_b-1x36WK2vB659VLegFw=.014593de-9a0d-4de8-9f4d-40400a3551b0@github.com>

On Wed, 19 Apr 2023 21:29:05 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
> 
> This patch attempts to fix that omission.

This pull request has now been integrated.

Changeset: 1e4eafb4
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e4eafb4fe70832294a12938d93e7860073cf4cf
Stats:     247 lines in 2 files changed: 243 ins; 0 del; 4 mod

8071693: Introspector ignores default interface methods

Reviewed-by: prr, aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13544


From darcy at openjdk.org  Wed Apr 26 23:14:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 26 Apr 2023 23:14:25 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v8]
In-Reply-To: <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
Message-ID: <s5MlcpU47CpuGrmN6OQAInxA7IvpvBoKRJKZj1V1bE4=.dda3a491-a9b5-44f0-8d3b-eba084746868@github.com>

On Tue, 25 Apr 2023 18:52:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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 13 additional commits since the last revision:
> 
>  - Whitespace cleanups suggested by review.
>  - Merge branch 'master' into JDK-8071693
>  - Jam lines into 80 columns.
>  - Add more scenarios to the regression test.
>  - Add braces around if clause.
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/a3bbc5eb...b92726a9

> 

As a retroactive post-integration comment, there is judgement required when gauging whether or not the behavioral changes associated with a PR merit a CSR, as discussed in the CSR FAQ:

"Q: Under what conditions does a CSR need to be filed for a purely behavioral change?
A: Using qualitative terms, a CSR for a behavioral change should be filed if it is estimated enough developers or users would be sufficiently impacted by the change that it should get additional consideration or documentation. A judgment call is involved. If assistance is needed in determining whether or not a CSR needs to be filed, ask the CSR representative for that area or the CSR chair."
https://wiki.openjdk.org/display/csr/CSR+FAQs

Given my general understanding of the nature of the change, based on nature of the change, my answer to the question of whether or not this should have a CSR would be "yes", but I'm happy to defer to @prrace 's subject matter expertise here that the answer should be "no."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1524142980


From acobbs at openjdk.org  Wed Apr 26 23:14:25 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 26 Apr 2023 23:14:25 GMT
Subject: RFR: 8071693: Introspector ignores default interface methods [v8]
In-Reply-To: <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com>
 <ugGBSEMHjnHtDQ5KZ5DxLt4f-RE9_EpfFa56SLbFOJ0=.b97acb07-a008-4e1a-8014-9ace59994e33@github.com>
Message-ID: <NOMwmSHWUyMLb-HdJz6g3I6mkijMWF_8vIb56BEEPQM=.b7c74304-dfc0-4117-8bcd-3801e9fe4a48@github.com>

On Tue, 25 Apr 2023 18:52:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Introspector` class was never updated to include `default` methods inherited from interfaces.
>> 
>> This patch attempts to fix that omission.
>
> Archie Cobbs 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 13 additional commits since the last revision:
> 
>  - Whitespace cleanups suggested by review.
>  - Merge branch 'master' into JDK-8071693
>  - Jam lines into 80 columns.
>  - Add more scenarios to the regression test.
>  - Add braces around if clause.
>  - Add comment describing what IGNORABLE_INTERFACES is for.
>  - Put braces around single-line "if" statement clauses in test.
>  - Merge branch 'master' into JDK-8071693
>  - Verify static method is not mistakenly identified as property getter.
>  - Use Modifier.isAbstract() convenience method instead of bit masking test.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/a3bbc5eb...b92726a9

Maybe we should add a release note as a sort of consolation prize...?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1524147122


From jiangli at openjdk.org  Thu Apr 27 00:30:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 00:30:27 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition issues
 when statically linking JDK/VM natives with standard launcher
Message-ID: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>

Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):

- Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
- Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
- Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
- Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

-------------

Commit messages:
 - Update copyright headers.
 - 8306949: Resolve miscellaneous multiple symbol definition issues when statically linking JDK/VM natives with standard launcher

Changes: https://git.openjdk.org/jdk/pull/13682/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306949
  Stats: 28 lines in 11 files changed: 0 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13682/head:pull/13682

PR: https://git.openjdk.org/jdk/pull/13682


From serb at openjdk.org  Thu Apr 27 02:10:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 02:10:53 GMT
Subject: RFR: 8306681: Open source more AWT DnD related tests [v2]
In-Reply-To: <UTvXqdBIEXnpCnthLKr_KmeL14pUcKW042Np4GbF0Ug=.0c87339c-7bb3-4e67-b286-8e7be2350c13@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
 <UTvXqdBIEXnpCnthLKr_KmeL14pUcKW042Np4GbF0Ug=.0c87339c-7bb3-4e67-b286-8e7be2350c13@github.com>
Message-ID: <AwMl9eFxeAlOgXSty_w6jni0NF0lZC7OG1n955TIDI0=.0a533b44-52c5-432c-a9d6-c1c9a99eca34@github.com>

On Wed, 26 Apr 2023 22:48:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This PR open sources more AWT DnD related tests
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add endline

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13674#pullrequestreview-1403059300


From tr at openjdk.org  Thu Apr 27 06:28:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 06:28:23 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v4]
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <FaLbwa01ZV2oHgGPLpCMt3NYIvF1aRlQQAVV0GoyVEU=.24986305-4f2b-4227-be78-fc547906ad4a@github.com>

> Open source few AWT ScrollPane related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13621/files
  - new: https://git.openjdk.org/jdk/pull/13621/files/57f707a1..99fb2c73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=02-03

  Stats: 175 lines in 6 files changed: 55 ins; 58 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/13621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621

PR: https://git.openjdk.org/jdk/pull/13621


From tr at openjdk.org  Thu Apr 27 06:29:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 06:29:23 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
 <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>
Message-ID: <7OW9-mxrGsgHiBBjiGIla2ORCsYFzfkl6wrKY30jB50=.ad76e4eb-2016-4095-95e2-1aadea937205@github.com>

On Wed, 26 Apr 2023 17:34:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Open source few AWT TextArea related tests.
>
> test/jdk/java/awt/TextArea/ReplaceRangeTest.java line 26:
> 
>> 24:   @test
>> 25:   @bug 5025532
>> 26:   @requires (os.family == "windows")
> 
> Is this test can pass on windows only or we can run it on all platform?

The bug was raised for windows alone, I think the test can be run on all platforms, haven't checked though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13670#discussion_r1178670899


From tr at openjdk.org  Thu Apr 27 06:29:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 06:29:23 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v3]
In-Reply-To: <4EvaVkV6tssgpo45Oyzz6gqY46MrG6BLdupwixdVfyA=.6e10be9a-7fa1-4312-a4c6-5cb50a38d5de@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <jg96mMdZpvbj4-MPbONNkq1rf9E73AgPKH-wwXZNG2o=.aa7bb7d5-6517-443a-8d18-5e1853755a46@github.com>
 <RE-YW9XpHS8MExRz5tA_AXt0v8lwg4M69lfVs5acQPk=.b3f52aa7-e84a-406c-add5-8e85c2c02c28@github.com>
 <rGaha8Uq29wpOrXavNC4a1muYqVg9mbNDSVUP7Z_LTA=.1712713c-5516-4815-b38f-d30ac2d887e0@github.com>
 <4EvaVkV6tssgpo45Oyzz6gqY46MrG6BLdupwixdVfyA=.6e10be9a-7fa1-4312-a4c6-5cb50a38d5de@github.com>
Message-ID: <IEui3lRRzca_YUW1szEY-Nn5yiNuWRdJVkpBkkJm6Zo=.a8f3118a-fe73-4a94-8d18-3816f5064e05@github.com>

On Wed, 26 Apr 2023 17:49:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> Yeah, I guess 5000 might not be required 1000 might be fine, but either delay or sleep is required I feel.
>
> It seems just wrong to me. This sleep should be on the main thread after returning from invokeAndWait

Ok, moved it outside invokeAndWait, works fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178667403


From dcherepanov at openjdk.org  Thu Apr 27 07:14:53 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Thu, 27 Apr 2023 07:14:53 GMT
Subject: RFR: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr [v4]
In-Reply-To: <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
 <Zbh4JZ6_iCychqAXoE35sPXJhef2dwOZOsvwzJnCXiY=.94a8b607-7742-40f5-8da1-0f678c4becf9@github.com>
Message-ID: <QiKe4DStrOSqzQm_OLivVpnoaYwF6HgbsA0HCDX1dQg=.17633fa1-164d-4984-a201-234c06ed3f7c@github.com>

On Mon, 17 Apr 2023 08:14:13 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
>> 
>> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.
>
> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed long lines

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13459#issuecomment-1524921057


From serb at openjdk.org  Thu Apr 27 07:25:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 07:25:30 GMT
Subject: RFR: 8306133: Open source few AWT Drag & Drop related tests [v2]
In-Reply-To: <W9f8vMNZ2y1hZDWJCcrvgIzLfm5k1roZa_pK7yc92VI=.c23deb57-986e-4bba-b4b9-a203f715f603@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
 <kDPtlAx-2-N6RagF1ilqIS6uvoJxA5heB-mqEeCDlvc=.eba364ed-3b8b-4a9f-b725-e73e4eaf56f5@github.com>
 <_2bJwut7-7QWhcIqIgi2Mju_e4fsHPTsj2WTsfHEFmY=.8d1d492c-a5d2-4284-95ce-3e2a2d76ae1b@github.com>
 <9SkAJmCXwSILkucD99-PGTVz3sJ7aqnBZWpY5dALmGQ=.d258efcf-9f1f-40ec-9578-1edcb52c2bca@github.com>
 <W9f8vMNZ2y1hZDWJCcrvgIzLfm5k1roZa_pK7yc92VI=.c23deb57-986e-4bba-b4b9-a203f715f603@github.com>
Message-ID: <Z9RBUaVQn7z0OJt51o1Kvp2NoflcWSb6qzYH6chSaSs=.b8c93dc7-0756-4b72-8243-d6643b842e88@github.com>

On Tue, 25 Apr 2023 16:19:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> it is fine to call dispose here on the main, but the frame possibly can be null here.
>
> I have updated the tests to all dispose on the EDT just in case.

The problem is not in the "dispose" but in the next check "frame != null" the frame variable can be null here even if frame is shown on the screen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13591#discussion_r1178722196


From dcherepanov at openjdk.org  Thu Apr 27 07:28:58 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Thu, 27 Apr 2023 07:28:58 GMT
Subject: Integrated: 6995195: Static initialization deadlock in
 sun.java2d.loops.Blit and GraphicsPrimitiveMgr
In-Reply-To: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
References: <2OhzMdeb3s8PbnjJ89Rh1firpyZSyMpUB0v4OJaSBV8=.b70b8b84-1503-4a35-9e25-215bb6aeefd0@github.com>
Message-ID: <IEC_Bj54tZhSQFRkK92bcpnGeYMVsI_-sBSMLCda5q8=.8c6b0104-f5ec-4f18-b1e2-aa94722a2e0f@github.com>

On Thu, 13 Apr 2023 13:03:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR suggests to move generalPrimitives array to a new static nested GeneralPrimitives class to eliminate the possible deadlock. The Blit class (and other classes that register as general primitives) calls to GeneralPrimitives.register from the static initializer block without acquiring lock on the GraphicsPrimitiveMgr class.
> 
> This PR also includes a jtreg regression test which reproduces this issue without the patch and passes with the patch. Running tests from test/jdk/sun/java2d didn't reveal any issues with this patch.

This pull request has now been integrated.

Changeset: de0c05da
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de0c05da07859ee4552b73a39a35cc8cd37b78b0
Stats:     160 lines in 10 files changed: 118 ins; 33 del; 9 mod

6995195: Static initialization deadlock in sun.java2d.loops.Blit and GraphicsPrimitiveMgr

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/13459


From serb at openjdk.org  Thu Apr 27 07:37:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 07:37:22 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <guPNDUfPDIzsTKAgeu5xml7U33e85wsKiOwQxYJ1DLc=.019b0582-5698-471e-a162-195b676ce42d@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

The changes for jvm_xawt looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13682#issuecomment-1524973461


From serb at openjdk.org  Thu Apr 27 07:38:25 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 07:38:25 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <grnv86W8h6axj20dwer6WIOpalOPiClaJFbOkJXgdnI=.3ac177a0-cc25-4bc5-a70b-701a60631f29@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
 <zggaADImNXxfePbdzjP4MYr_WDKkJSHFwCX5JmJRWkc=.a5f9d859-3060-4fc4-8ffe-f3bea980de23@github.com>
 <grnv86W8h6axj20dwer6WIOpalOPiClaJFbOkJXgdnI=.3ac177a0-cc25-4bc5-a70b-701a60631f29@github.com>
Message-ID: <2KY0-PsL5w8dkO-wqgbLmsgeUoIXNVcl5c74X1cyE6o=.fe04f009-81bc-45ed-951a-1cd11a50d0b2@github.com>

On Wed, 26 Apr 2023 17:57:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/dnd/RejectDragDropActionTest.java line 114:
>> 
>>> 112:         }
>>> 113: 
>>> 114:         if (incorrectActionDetected) {
>> 
>> incorrectActionDetected is set on one thread an used on another, same for "frame" in other tests.
>
> meaning you are suggesting they need to be volatile ?

or changed to be used on the same thread, in this case EDT. It seems different tests use different approaches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178725097


From serb at openjdk.org  Thu Apr 27 07:38:25 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 07:38:25 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <7OW9-mxrGsgHiBBjiGIla2ORCsYFzfkl6wrKY30jB50=.ad76e4eb-2016-4095-95e2-1aadea937205@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
 <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>
 <7OW9-mxrGsgHiBBjiGIla2ORCsYFzfkl6wrKY30jB50=.ad76e4eb-2016-4095-95e2-1aadea937205@github.com>
Message-ID: <ZF-yOA9_fCao0-rTLn3RoiIrvJjFwjT8pS_MZA2CMsg=.e8e4f420-8e20-45be-b4c9-4111f4a3d40e@github.com>

On Thu, 27 Apr 2023 06:15:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/TextArea/ReplaceRangeTest.java line 26:
>> 
>>> 24:   @test
>>> 25:   @bug 5025532
>>> 26:   @requires (os.family == "windows")
>> 
>> Is this test can pass on windows only or we can run it on all platform?
>
> The bug was raised for windows alone, I think the test can be run on all platforms, haven't checked though.

I suggest checking and deleting this if the tests will work fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13670#discussion_r1178726354


From tr at openjdk.org  Thu Apr 27 07:38:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 07:38:53 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <ZF-yOA9_fCao0-rTLn3RoiIrvJjFwjT8pS_MZA2CMsg=.e8e4f420-8e20-45be-b4c9-4111f4a3d40e@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
 <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>
 <7OW9-mxrGsgHiBBjiGIla2ORCsYFzfkl6wrKY30jB50=.ad76e4eb-2016-4095-95e2-1aadea937205@github.com>
 <ZF-yOA9_fCao0-rTLn3RoiIrvJjFwjT8pS_MZA2CMsg=.e8e4f420-8e20-45be-b4c9-4111f4a3d40e@github.com>
Message-ID: <ZEmiJl1kmw1e8LkIX2p4KMzzo_ueSCKYaKsNjxFc2WU=.fe19e977-b961-4cb7-9a21-c7ae48684c8b@github.com>

On Thu, 27 Apr 2023 07:20:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The bug was raised for windows alone, I think the test can be run on all platforms, haven't checked though.
>
> I suggest checking and deleting this if the tests will work fine.

Ok, will check that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13670#discussion_r1178735579


From mkartashev at openjdk.org  Thu Apr 27 09:36:00 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 27 Apr 2023 09:36:00 GMT
Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11
 sessions [v5]
In-Reply-To: <z1PP0KuBicaX-6AIr8zLr-dLemV34v9_AbOG0wMbh48=.55ad4ae4-3ab6-4d6f-80a3-e209810736e9@github.com>
References: <JGYlLHtDj-hUgAqhy-_I6_pSt0dRGCsXmPSDoZ8MXVU=.74a7c2c3-49c1-4186-a39c-998de1b1f76f@github.com>
 <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com>
 <z1PP0KuBicaX-6AIr8zLr-dLemV34v9_AbOG0wMbh48=.55ad4ae4-3ab6-4d6f-80a3-e209810736e9@github.com>
Message-ID: <YFh2lxRAbZAWqyefdpDaeCRl6y0W-m4BHNZ9vHUiXHU=.18d36ea4-c7a0-4ecf-a700-eabbc4d7d0a0@github.com>

On Wed, 26 Apr 2023 22:09:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to set insets in the device constructor 

I would very much like to delay getting the insets until they are actually needed. The device construction is already happening at the time when lots of info is being fetched from the X server; however, insets are needed relatively rarely, the major use case being pull-down menus.

In Ubuntu, for instance, you can change your Dock size gradually with a slider and each time insets get updated. But unless you open a menu while dragging that slider (which is virtually impossible), the Java program doesn't need to know about new insets, all it needs is to know that the current insets are outdated. Once Dock has been resized *and* the focus has shifted to the Java application *and* menu is about to be opened, then we *must* call `getScreenInsetsImpl()` to fetch the new insets. In this scenario we do this only once instead of each time the slider in the Dock configuration dialog changes its state.

> Is it possible [...] update it on a callback? In this case, this method will be just an accessor.

I'm afraid I don't fully understand what you meant. Can you give an example in pseudo-code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1178857998


From tr at openjdk.org  Thu Apr 27 10:00:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 10:00:23 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <ZEmiJl1kmw1e8LkIX2p4KMzzo_ueSCKYaKsNjxFc2WU=.fe19e977-b961-4cb7-9a21-c7ae48684c8b@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
 <OQb1ZKF2dATxbM1yQdn2aZ2Im3dFpntEDom0RrsZaP8=.9d321ff4-8019-4f81-8613-acc45e3b8963@github.com>
 <7OW9-mxrGsgHiBBjiGIla2ORCsYFzfkl6wrKY30jB50=.ad76e4eb-2016-4095-95e2-1aadea937205@github.com>
 <ZF-yOA9_fCao0-rTLn3RoiIrvJjFwjT8pS_MZA2CMsg=.e8e4f420-8e20-45be-b4c9-4111f4a3d40e@github.com>
 <ZEmiJl1kmw1e8LkIX2p4KMzzo_ueSCKYaKsNjxFc2WU=.fe19e977-b961-4cb7-9a21-c7ae48684c8b@github.com>
Message-ID: <JekxMtnqJ8SJBN0YA3t3hW8LkAPSBREdVC6vKEY6e6s=.2aed3922-7267-4280-9fd0-9f8dfa1201f0@github.com>

On Thu, 27 Apr 2023 07:28:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I suggest checking and deleting this if the tests will work fine.
>
> Ok, will check that.

The is is failing for both linux and macos. Maybe because of `\r\n` direct check, so better to leave the test for windows alone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13670#discussion_r1178910409


From aturbanov at openjdk.org  Thu Apr 27 10:57:24 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 10:57:24 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
Message-ID: <SoKoGsJ3pyNAGrSGLhPcmGyddWExV6HHuhE3HplpClA=.64d19946-e1f8-4f0f-8bbb-e4378fec2a4b@github.com>

On Tue, 25 Apr 2023 23:16:33 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This PR open sources a few more AWT DnD related tests
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra folders

test/jdk/java/awt/dnd/SkipDropCompleteTest/SkipDropCompleteTest.java line 56:

> 54:     public void init() {
> 55:         sourceFrame = new SourceFrame();
> 56:         targetFrame  = new TargetFrame();

Suggestion:

        targetFrame = new TargetFrame();

test/jdk/java/awt/dnd/SkipDropCompleteTest/SourceFrame.java line 82:

> 80:     public void dragDropEnd(DragSourceDropEvent dsde) { }
> 81: 
> 82:     public void dragGestureRecognized(DragGestureEvent dge)  {

Suggestion:

    public void dragGestureRecognized(DragGestureEvent dge) {

test/jdk/java/awt/dnd/SkipDropCompleteTest/TransferableObject.java line 52:

> 50:         super();
> 51:         Vector v = new Vector();
> 52:             if(data instanceof String) {

Strange indentation
Suggestion:

        if (data instanceof String) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178971470
PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178971719
PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1178972048


From aturbanov at openjdk.org  Thu Apr 27 10:57:53 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 10:57:53 GMT
Subject: RFR: 8306638: Open source some AWT tests related to datatransfer
 and Toolkit
In-Reply-To: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
References: <VONYuQvYafSYFT3kPEt8pc-yKXfr0pcHMH8mKnlpqoQ=.1c14b3e3-a695-4e34-bf1d-c4e913d7f8da@github.com>
Message-ID: <KMOnI6T8zzaCqTB9r1rsGKMYXGvEzNaWPo55XrsW_x8=.0cebda89-001b-4364-b4be-b9cb42650300@github.com>

On Tue, 25 Apr 2023 13:48:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR open sources some tests related to AWT datatransfer and Toolkit.

test/jdk/java/awt/datatransfer/CRLFTest/CRLFTest.java line 192:

> 190:                     // the variable finished is set to true.
> 191:                     pres.exitValue = p.exitValue();
> 192:                     finished  = true;

Suggestion:

                    finished = true;

test/jdk/java/awt/datatransfer/DataConversionDeadlockTest/DataConversionDeadlockTest.java line 187:

> 185:                     // the variable finished is set to true.
> 186:                     pres.exitValue = p.exitValue();
> 187:                     finished  = true;

Suggestion:

                    finished = true;

test/jdk/java/awt/datatransfer/DataFlavor/BestTextFlavorTest/BestTextFlavorTest.java line 83:

> 81: 
> 82:         //Checking whether the selected flavors in both the arrays are same.
> 83:         if(bestFlavor2.match(bestFlavor1)) {

Suggestion:

        if (bestFlavor2.match(bestFlavor1)) {

test/jdk/java/awt/datatransfer/DataFlavor/BestTextFlavorTest/BestTextFlavorTest.java line 100:

> 98:         DataFlavor[] tempFlavor = new DataFlavor[dataflavor.length];
> 99:         int j = 0;
> 100:         for(int i = dataflavor.length - 1  ; i >= 0; i--) {

Suggestion:

        for (int i = dataflavor.length - 1; i >= 0; i--) {

test/jdk/java/awt/datatransfer/FileTransferAWTLockTest/FileTransferAWTLockTest.java line 202:

> 200:                     // the variable finished is set to true.
> 201:                     pres.exitValue = p.exitValue();
> 202:                     finished  = true;

Suggestion:

                    finished = true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1178974127
PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1178973796
PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1178973091
PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1178973333
PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1178973598


From aturbanov at openjdk.org  Thu Apr 27 11:09:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Apr 2023 11:09:54 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v4]
In-Reply-To: <FaLbwa01ZV2oHgGPLpCMt3NYIvF1aRlQQAVV0GoyVEU=.24986305-4f2b-4227-be78-fc547906ad4a@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <FaLbwa01ZV2oHgGPLpCMt3NYIvF1aRlQQAVV0GoyVEU=.24986305-4f2b-4227-be78-fc547906ad4a@github.com>
Message-ID: <QJoapeh6PubHPpxz9zRll56Eq-gWqtXZ9e3rVNe73e8=.88b11193-fbcc-498f-adc7-9dd2f810b12d@github.com>

On Thu, 27 Apr 2023 06:28:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 106:

> 104:                     sp.getLocationOnScreen().y + sp.getHeight() - paneInsets.bottom / 2);
> 105:             testOneScrollbar(hScroll);
> 106:         } finally{

Suggestion:

        } finally {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1178976572


From aivanov at openjdk.org  Thu Apr 27 12:52:23 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 27 Apr 2023 12:52:23 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v4]
In-Reply-To: <FaLbwa01ZV2oHgGPLpCMt3NYIvF1aRlQQAVV0GoyVEU=.24986305-4f2b-4227-be78-fc547906ad4a@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <FaLbwa01ZV2oHgGPLpCMt3NYIvF1aRlQQAVV0GoyVEU=.24986305-4f2b-4227-be78-fc547906ad4a@github.com>
Message-ID: <cWvFMteg5BADXJoqZnGmvDjvRCpcXe2ZOyORDYvh2_Y=.b524cba9-f2cf-4a2a-a956-f5319182ff64@github.com>

On Thu, 27 Apr 2023 06:28:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Open source few AWT ScrollPane related tests.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 47:

> 45:     public ScrollPane scrollpane;
> 46:     public Frame frame;
> 47:     public int count = 0;

Suggestion:

    public volatile int count = 0;

`count` is accessed from two threads, it should be `volatile` or you should use `AtomicInteger` instead.

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 53:

> 51:     public static boolean mouseWasPressed = false;
> 52:     public static Component child = null;
> 53:     private Object lock = new Object();

Suggestion:

    private final Object lock = new Object();

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 83:

> 81:                         if (e.getID() == MouseEvent.MOUSE_PRESSED) {
> 82:                             if (e.getSource() == ScrollPaneLimitation.child
> 83:                                     && e.getY() > SCROLL_POS) {

The two `if` blocks could be merged together into one.

test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 145:

> 143:                     throw new RuntimeException("test was interrupted");
> 144:                 }
> 145:             }

A `CountDownLatch` would be better rather than plain `lock`.

test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 138:

> 136:                 waiting--;
> 137:             }
> 138:         }

This method is never used, it can safely be dropped.

test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 77:

> 75:         hScroll = (ScrollPaneAdjustable) sp.getHAdjustable();
> 76:         vScroll.addAdjustmentListener(this);
> 77:         hScroll.addAdjustmentListener(this);

`vScroll` and `hScroll` should also go into `invokeAndWait` above.

test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 85:

> 83: 
> 84:                 int i;
> 85:                 i = (int) (sp.getScrollPosition().getX());

Suggestion:

                int i = (int) (sp.getScrollPosition().getX());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179060375
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179087661
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179062469
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179065937
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179096166
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179076672
PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179084512


From aivanov at openjdk.org  Thu Apr 27 12:52:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 27 Apr 2023 12:52:53 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v2]
In-Reply-To: <9e2yWcb08BuPSJ6zuFk4hpIK8aeWho1jWScSjEIT_eI=.02b7de4d-a9ca-4a9e-8784-460725890688@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
 <FKGzT-ruG-F-1yCwdN_Oifn9prPcNTp1mwTED5MKbxk=.5ece554a-14f0-44ab-a919-886573a5f754@github.com>
 <PlYjmZGkMZ4hOT9fhKYSRgb46p8YIbk9RhIfO9n6z3M=.281891d0-d0a3-4b34-adbe-9f4723f37ecd@github.com>
 <9e2yWcb08BuPSJ6zuFk4hpIK8aeWho1jWScSjEIT_eI=.02b7de4d-a9ca-4a9e-8784-460725890688@github.com>
Message-ID: <9RBFWWsTf9hA7ID7gx6lvv2uL9qZCg4pZl0AzEnacIc=.dbdc57c2-4295-4ca0-8e68-35adf3c5ec38@github.com>

On Wed, 26 Apr 2023 16:45:57 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 121:
>> 
>>> 119:         volatile boolean state = false;
>>> 120:         Object lock = new Object();
>>> 121:         volatile int waiting = 0;
>> 
>> Why are both `state` and `waiting` marked as volatile? Either is accessed from synchronized blocks protected by `lock` except for `getState` which should also use the `lock` object.
>
> I don't think its required to be volatile, not sure.

They shouldn't be volatile, a proper synchronisation is used. But `getState` should use `lock` lock to return the state because access to `state` is synchronised using `lock`, not `this`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1179096063


From duke at openjdk.org  Thu Apr 27 13:18:24 2023
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 27 Apr 2023 13:18:24 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v3]
In-Reply-To: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
Message-ID: <5p7taTw6HgWDfW_fIHQ8X3uR-pfv9GZTysBBAO1Qsvg=.3d96d1dc-0338-4e8c-945c-29567bca4d72@github.com>

> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
> 
> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
> 
> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.

Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:

  Replace "The default implementation" text by "This method".
  Other edits as commented on GitHub issue.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13506/files
  - new: https://git.openjdk.org/jdk/pull/13506/files/0f339543..217c6c0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13506&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13506&range=01-02

  Stats: 14 lines in 1 file changed: 4 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13506/head:pull/13506

PR: https://git.openjdk.org/jdk/pull/13506


From duke at openjdk.org  Thu Apr 27 13:18:25 2023
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 27 Apr 2023 13:18:25 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v2]
In-Reply-To: <SlVPgj_Jsy4A62ZFLTS7zJKRkhzoHesUe1QTkaEMbrc=.1616f0fa-06ee-4af5-91c7-22b0023afcc1@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <UhFdqYWYEe7jsF5ANYVSDuIwbVqJm4Ewqb_yyYx8Jzc=.374daf88-09bb-45f3-ab12-ba05d67c20ef@github.com>
 <SlVPgj_Jsy4A62ZFLTS7zJKRkhzoHesUe1QTkaEMbrc=.1616f0fa-06ee-4af5-91c7-22b0023afcc1@github.com>
Message-ID: <daxoOkCtaODKq6Hh_7PLrDLB4DK62BiGetVfo9uqMR4=.9dc8be8d-af07-4d87-b7f0-5ee1b0576b2d@github.com>

On Tue, 25 Apr 2023 22:46:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update documentation for adressing comment on pull requests, with two changes to be discussed:
>>   
>>   - The "The default implementation" sentence has not yet been removed, for reason discussed on the pull request.
>>   - The discussion about (0,0) tile indices mentions the relationship with `getTileMinX()` and `getTileMinY()`.
>
> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1593:
> 
>> 1591:      * Since a {@code BufferedImage} consists of a single tile,
>> 1592:      * and that tile is always checked out for writing, the
>> 1593:      * default implementation returns an array of one point.
> 
> I'd be happier with "the default implementation" -> "this method".
> I did read your notes on subclasses etc but really these methods should have been final so I'd like to make
> the documentation reflect that rather than implying that there's an open door to do something else.

Replaced all "The default implementation" texts by "This method". But if the intend was to disallow alternative behaviour, maybe instead of making those method final, `BufferedImage` should have simply not implemented `WritableRenderedImage` and implement `RenderedImage` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13506#discussion_r1179121544


From azvegint at openjdk.org  Thu Apr 27 13:36:55 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 27 Apr 2023 13:36:55 GMT
Subject: RFR: 8306850: Open source AWT Model related tests
In-Reply-To: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
References: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
Message-ID: <ebiQq3LJhDglusJ77IL0tem1urLMvJJs6iqNu2WDZCs=.7117de8d-2fbd-43b1-8609-7aab619a0242@github.com>

On Wed, 26 Apr 2023 19:48:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source Modal related AWT tests.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13676#pullrequestreview-1404036518


From alanb at openjdk.org  Thu Apr 27 14:00:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Apr 2023 14:00:25 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <lTnWw8tIWfWu-mvLSGjO0a33PBWreWquVzSuaVN10pA=.2c17937d-2044-4463-933d-c994951b2665@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

Marked as reviewed by alanb (Reviewer).

Looks okay.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13682#pullrequestreview-1404102039
Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13682#pullrequestreview-1404103532


From jiangli at openjdk.org  Thu Apr 27 15:08:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 15:08:54 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <HIkIovQEj3ZKo4QAeaWGAorjbh_bWL6mJJkYPrFvZUc=.d8dc4b68-730d-4fb9-8309-4250c7d2ea04@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13682#issuecomment-1525845560


From jiangli at openjdk.org  Thu Apr 27 16:11:55 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 16:11:55 GMT
Subject: Integrated: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <AWDpUaSa56ZgYKpo9xdTGylOcHJw6dNdyIW1evrJ7Cs=.25bb6d74-6709-45b7-8237-cf956c0b5060@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

This pull request has now been integrated.

Changeset: fed262a9
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fed262a9cf324ce7f2c61f4471c88bc84af8e3d0
Stats:     28 lines in 11 files changed: 0 ins; 1 del; 27 mod

8306949: Resolve miscellaneous multiple symbol definition issues when statically linking JDK/VM natives with standard launcher

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13682


From abhiscxk at openjdk.org  Thu Apr 27 16:23:53 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Apr 2023 16:23:53 GMT
Subject: Integrated: 8306850: Open source AWT Model related tests
In-Reply-To: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
References: <cLg-Gd3gPymaNmvqJj7hi55ocbqydI7utlEEKSJ9WlE=.bb1294b1-1dce-4460-9091-54c1abc575dc@github.com>
Message-ID: <V7sOXpVRkUuQZMynv_8vvSP8_j4wIje5_le00WBEmaA=.d603074d-726a-423c-a258-8c828402707f@github.com>

On Wed, 26 Apr 2023 19:48:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This PR is to open source Modal related AWT tests.

This pull request has now been integrated.

Changeset: 41ba05e4
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41ba05e450ed4467535bcee81946099e38665c3f
Stats:     1053 lines in 6 files changed: 1053 ins; 0 del; 0 mod

8306850: Open source AWT Model related tests

Reviewed-by: serb, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/13676


From tr at openjdk.org  Thu Apr 27 17:09:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Apr 2023 17:09:56 GMT
Subject: RFR: 8306432: Open source several AWT Text Component related tests
Message-ID: <7GvB3Su_njyW24WYBbYZXlx9jtO98uTxNrRkLTX4DEQ=.518bbfca-17bd-4bef-bbc1-e01f6026c951@github.com>

Open source few AWT Text Component related tests.

-------------

Commit messages:
 - Updated
 - Updated
 - Open sourced TextComponent tests

Changes: https://git.openjdk.org/jdk/pull/13695/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306432
  Stats: 394 lines in 5 files changed: 394 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13695/head:pull/13695

PR: https://git.openjdk.org/jdk/pull/13695


From prr at openjdk.org  Thu Apr 27 19:17:28 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Apr 2023 19:17:28 GMT
Subject: RFR: 8306320: BufferedImage spec needs clarification w.r.t its
 implementation of the WritableRenderedImage interface [v3]
In-Reply-To: <5p7taTw6HgWDfW_fIHQ8X3uR-pfv9GZTysBBAO1Qsvg=.3d96d1dc-0338-4e8c-945c-29567bca4d72@github.com>
References: <RQLcpKPs7ERW6ts2MYlKOkCRcUv2dTz4bGMADMgdzQ4=.1a06f880-98e0-4643-9d88-9c2e95861395@github.com>
 <5p7taTw6HgWDfW_fIHQ8X3uR-pfv9GZTysBBAO1Qsvg=.3d96d1dc-0338-4e8c-945c-29567bca4d72@github.com>
Message-ID: <m0DL99EDqZ8vqixJUpNztwhrBA_yghKLud4jbRob_dQ=.a0adfb87-0bd2-4477-822e-5d645145150c@github.com>

On Thu, 27 Apr 2023 13:18:24 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

>> `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour.
>> 
>> This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected.
>> 
>> This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes.
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace "The default implementation" text by "This method".
>   Other edits as commented on GitHub issue.

I'll update the CSR.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13506#pullrequestreview-1404717870


From rmahajan at openjdk.org  Thu Apr 27 19:44:28 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 27 Apr 2023 19:44:28 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues
 on Windows in High DPI env
Message-ID: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>

Problem:

Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:

- Scrawly ticks in checkboxes;
- Wrong circle relations in selected radio buttons.

Root-cause:
We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
Due to this when the app window goes to Secondary Screen with different DPI UI buttons
appear incorrectly rendered. 
Following is a list proposed changes to fix this issue.


Proposed Fix with Summary of changes:

1. Open a new Theme Handle per the DPI of the Screen where the App window is.
--> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
window is.

2. GetPartSize() of icons returns size based on standard size = 96 DPI.
--> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.

3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
-->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
 
4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
--> This helps make sure that for .25s scaling we get better rendering. 
This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.

As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.


Testing:

Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.

___________________________________
 Monitor 1                |    Monitor 2
(Primary) 		         |
				 |
        125%		 |    175%
	150%		 |    175%
	150%		 |    225%
	175%		 |    175%
	175%	         |    150%
	175%	         |    225%
_____________________ |_____________	

Also tested on setup with scaling values of  up-to 350%.

-------------

Commit messages:
 - code clean up
 - fix for JDK-8294427

Changes: https://git.openjdk.org/jdk/pull/13701/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294427
  Stats: 132 lines in 4 files changed: 59 ins; 26 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/13701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701

PR: https://git.openjdk.org/jdk/pull/13701


From prr at openjdk.org  Thu Apr 27 21:58:23 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Apr 2023 21:58:23 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
Message-ID: <WLS-xD5B5_W673htYpEuhZABLr7Wa2WR0K75r8RRQeA=.51ab49a6-fea3-4733-9e40-764055d63315@github.com>

On Wed, 26 Apr 2023 14:23:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT TextArea related tests.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13670#pullrequestreview-1404948060


From prr at openjdk.org  Thu Apr 27 22:08:52 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Apr 2023 22:08:52 GMT
Subject: RFR: 8306432: Open source several AWT Text Component related tests
In-Reply-To: <7GvB3Su_njyW24WYBbYZXlx9jtO98uTxNrRkLTX4DEQ=.518bbfca-17bd-4bef-bbc1-e01f6026c951@github.com>
References: <7GvB3Su_njyW24WYBbYZXlx9jtO98uTxNrRkLTX4DEQ=.518bbfca-17bd-4bef-bbc1-e01f6026c951@github.com>
Message-ID: <jND_9NMAV01KZXpQRUWTAdeIIWjAsDXOpIQ9eQfJBKo=.d942cede-b846-4d9e-9add-2ca95e7d5e39@github.com>

On Thu, 27 Apr 2023 16:50:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT Text Component related tests.

Marked as reviewed by prr (Reviewer).

test/jdk/java/awt/TextComponent/DeselectionDuringDoSelectionNonVisibleTest.java line 30:

> 28:   @key headful
> 29:   @requires (os.family == "mac") | (os.family == "windows")
> 30: */

Seems this requires was added in 2018. I can't track down the exact reason but I think we'll let it stand even though it seems odd.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13695#pullrequestreview-1404968265
PR Review Comment: https://git.openjdk.org/jdk/pull/13695#discussion_r1179720951


From prr at openjdk.org  Thu Apr 27 23:05:54 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Apr 2023 23:05:54 GMT
Subject: RFR: 8307079: Update test java/awt/Choice/DragOffNoSelect.java
Message-ID: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>

Small update to a test

-------------

Commit messages:
 - 8307079

Changes: https://git.openjdk.org/jdk/pull/13705/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307079
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13705/head:pull/13705

PR: https://git.openjdk.org/jdk/pull/13705


From serb at openjdk.org  Thu Apr 27 23:06:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 23:06:29 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v9]
In-Reply-To: <7uLi7MOk-F0PIDz9Viqkakgx1BURLX6ppZtht5-jyTo=.215090dc-e857-4066-9e33-24c307705557@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <7uLi7MOk-F0PIDz9Viqkakgx1BURLX6ppZtht5-jyTo=.215090dc-e857-4066-9e33-24c307705557@github.com>
Message-ID: <pWr4ldzK-zP5rFSIxSq9g0dalH09j90KASTM9yk6bqs=.fa11c468-36f5-4e5a-9eb1-c5f583248ff1@github.com>

On Thu, 23 Mar 2023 19:55:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix check

> It seems the test fails on windows for WIndows L&F..This is what I got
> It seems it does not fail in mach5 maybe because it is not run in hidpi system.

@prsadhuk Did you able to fix it, or report the new JBS bug for that? I have the same issue, the test fails on the HiDPI system.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12390#issuecomment-1526685414


From kizune at openjdk.org  Fri Apr 28 00:03:05 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 00:03:05 GMT
Subject: RFR: 8306954: Open source five Focus related tests
Message-ID: <WU9Saz8NCgA24hCjPOyy-8N_Tr3RwT_HCz950EsfKEU=.cfe407fc-49d8-4fb4-856e-fffe32f5bf86@github.com>

Cleaning up tests:

AsyncUpFocusCycleTest.java
ClearMostRecentFocusOwnerTest.java
ConsumedTabKeyTest.java,
EventRetargetTest.java
ExtraPropChangeNotifVetoingTest.java

-------------

Commit messages:
 - 8306954: Open source five Focus related tests

Changes: https://git.openjdk.org/jdk/pull/13707/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13707&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306954
  Stats: 962 lines in 5 files changed: 962 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13707/head:pull/13707

PR: https://git.openjdk.org/jdk/pull/13707


From azvegint at openjdk.org  Fri Apr 28 00:32:01 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Apr 2023 00:32:01 GMT
Subject: RFR: 8307079: Update test java/awt/Choice/DragOffNoSelect.java
In-Reply-To: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
References: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
Message-ID: <_t4e82-cvmW9vCM2ZXHI2GegJcL84VD9dHgcYRQkv08=.c9e574c2-72e5-4a3e-b3de-611e47371e97@github.com>

On Thu, 27 Apr 2023 22:46:41 GMT, Phil Race <prr at openjdk.org> wrote:

> Small update to a test

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13705#pullrequestreview-1405069181


From jiangli at openjdk.org  Fri Apr 28 01:41:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 01:41:27 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
Message-ID: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>

Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.

In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.

To build the statically linked executable:

1. Configure the JDK build with --with-static-java=yes
2. Build static-java-image, e.g. 'make jdk-image static-java-image'

 The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.

Following is a summary of the changes in this PR:

- Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.

- Changes in make/Main.gmk
? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.

- Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.

- Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.

- Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.

- When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.

- In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.

- In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.

Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

-------------

Commit messages:
 - Update copyright headers.
 - Fix jcheck whitespace error with make/autoconf/lib-bundled.m4.
 - Merge branch 'master' into JDK-8303796
 - - Update make/StaticLink.gmk:
 - Merge branch 'master' into JDK-8303796
 - Add make/StaticLink.gmk and make/autoconf/static-java.m4.
 - 8303796: Optionally build fully statically linked JDK image

Changes: https://git.openjdk.org/jdk/pull/13709/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303796
  Stats: 301 lines in 12 files changed: 258 ins; 34 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13709.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13709/head:pull/13709

PR: https://git.openjdk.org/jdk/pull/13709


From serb at openjdk.org  Fri Apr 28 05:05:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 05:05:54 GMT
Subject: RFR: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
Message-ID: <6Ns8Aqc_TKdD9DE5CnvT-D-TKMk9_qtk-U3IxRra8vs=.a2c26157-5efa-4276-b37d-aacedef957ba@github.com>

On Wed, 26 Apr 2023 14:23:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT TextArea related tests.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13670#pullrequestreview-1405220644


From dholmes at openjdk.org  Fri Apr 28 05:16:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Apr 2023 05:16:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

@jianglizhou  I thought this work was proposed to be done under the Project Leyden umbrella? The other static-build tweaks have been fine but this seems to be part of a bigger, yet unspecified, project that may need to be covered by a JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1526991027


From kizune at openjdk.org  Fri Apr 28 05:34:24 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 05:34:24 GMT
Subject: RFR: 8307078: Opensource and clean up five more AWT Focus related
 tests
Message-ID: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>

Cleaned up and ready to opensource:
java/awt/Focus/FocusForRemovedComponentTest
java/awt/Focus/FocusTraversalPolicyIAE
java/awt/Focus/InitialFocusTest
java/awt/Focus/LabelScrollbar
java/awt/Focus/ModalDialogInFocusEventTest

-------------

Commit messages:
 - 8307078: Opensource and clean up five more AWT Focus related tests

Changes: https://git.openjdk.org/jdk/pull/13710/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307078
  Stats: 965 lines in 5 files changed: 965 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13710/head:pull/13710

PR: https://git.openjdk.org/jdk/pull/13710


From serb at openjdk.org  Fri Apr 28 05:36:23 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 05:36:23 GMT
Subject: RFR: 8307078: Opensource and clean up five more AWT Focus related
 tests
In-Reply-To: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
References: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
Message-ID: <7GfrLKtU3KFjDDShIHi63MAJMbeDlxpplzc7fozSJsM=.090e3d41-d264-40f9-8ca8-afd0ebc487de@github.com>

On Fri, 28 Apr 2023 05:12:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and ready to opensource:
> java/awt/Focus/FocusForRemovedComponentTest
> java/awt/Focus/FocusTraversalPolicyIAE
> java/awt/Focus/InitialFocusTest
> java/awt/Focus/LabelScrollbar
> java/awt/Focus/ModalDialogInFocusEventTest

Looks fine, please confirm that mach5 is green.

-------------

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13710#pullrequestreview-1405243117


From serb at openjdk.org  Fri Apr 28 05:37:25 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 05:37:25 GMT
Subject: RFR: 8307079: Update test java/awt/Choice/DragOffNoSelect.java
In-Reply-To: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
References: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
Message-ID: <m8DLInA9t4COi-E7C5XVCxQjK8_WEWI9rSOR_wPy00Q=.3dde27f7-5c2d-4f4c-a254-5d8a82aea4f1@github.com>

On Thu, 27 Apr 2023 22:46:41 GMT, Phil Race <prr at openjdk.org> wrote:

> Small update to a test

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13705#pullrequestreview-1405245552


From kizune at openjdk.org  Fri Apr 28 05:41:23 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 05:41:23 GMT
Subject: RFR: 8307078: Opensource and clean up five more AWT Focus related
 tests
In-Reply-To: <7GfrLKtU3KFjDDShIHi63MAJMbeDlxpplzc7fozSJsM=.090e3d41-d264-40f9-8ca8-afd0ebc487de@github.com>
References: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
 <7GfrLKtU3KFjDDShIHi63MAJMbeDlxpplzc7fozSJsM=.090e3d41-d264-40f9-8ca8-afd0ebc487de@github.com>
Message-ID: <9KKE49IKoV1zbY88S1Dy8fVcjIK3JJPf2uISawZz-x0=.ec190002-13b9-45b3-8cc1-679e8540510e@github.com>

On Fri, 28 Apr 2023 05:21:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, please confirm that mach5 is green.

Mach5 is green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13710#issuecomment-1527011667


From tr at openjdk.org  Fri Apr 28 09:54:26 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 28 Apr 2023 09:54:26 GMT
Subject: RFR: 8306137: Open source several AWT ScrollPane related tests
 [v5]
In-Reply-To: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
References: <C2Gsav4KO53Qexr7F8rqFMX0Bb14UeJA2-vvQRr8q-o=.8452e519-2c7e-4e4c-a210-e0f3f80a59c3@github.com>
Message-ID: <y6P-UflZ0PLwRIf7Dpuzm7HUtNiOKlZripoBNMU_VT0=.82eece65-49c9-445d-984c-a3bb6a42e111@github.com>

> Open source few AWT ScrollPane related tests.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13621/files
  - new: https://git.openjdk.org/jdk/pull/13621/files/99fb2c73..d9bfe956

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=03-04

  Stats: 42 lines in 5 files changed: 8 ins; 22 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621

PR: https://git.openjdk.org/jdk/pull/13621


From alanb at openjdk.org  Fri Apr 28 12:09:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Apr 2023 12:09:57 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

The JDK moved to modular run-time images in JDK 9 ([JEP 220](https://openjdk.org/jeps/220) that are created with the jlink tool. The eventual goal here is to make it possible to produce a statically linked image and I suspect there will need to be some figuring out as to where jlink fits. It might be that the JDK produces a set of packaged modules containing the .a files and jlink involves the native linker. I think some future JEP will need describe all this.

If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink. I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527460643


From jdowland at redhat.com  Fri Apr 28 12:23:51 2023
From: jdowland at redhat.com (Jonathan Dowland)
Date: Fri, 28 Apr 2023 13:23:51 +0100
Subject: requesting an AWT expert prior to backporting 8304350
 (Font.getStringBounds calculates wrong width for TextAttribute.TRACKING
 other than 0.0)
Message-ID: <20230428122351.v2hdbvmnr62szqbq@coil>

Hi folks,

We were made aware of a problem with java.awt.Font bounding box
calculations when custom font Tracking properties were specified and
raised a JBS bug (<https://bugs.openjdk.org/browse/JDK-8304350>). I am
not an expert on this area of the JDK, but upon investigation it seems
the routine java.awt.Font.getStringBounds uses a heuristic to determine
whether calculating the bounding box is "simple" or not. Our case was
falling into the simple branch. Our initial proposed fix was to adjust
the heuristic such that custom Tracking properties went down the
"complex" path, which is correct, but likely slower.

Our initial fix was merged into JDK21. Ultimately we plan to propose
backporting this to JDK 11 Updates (via 20 and 17 Updates). But before
we start that, we would really appreciate it if someone with better
familiarity with the AWT or Font code could indicate that they were
happy with this.

In particular, another approach could be to modify the "simple" path
delegate sun.font.FontDesignMetrics to account for the Tracking
property. My take, upon reading it, was this was probably not
appropriate, but I'm new to this code and would love to have the
opinion of someone more expert.


Many thanks for your time,

-- 
?? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat



From tr at openjdk.org  Fri Apr 28 14:53:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 28 Apr 2023 14:53:23 GMT
Subject: Integrated: 8306432: Open source several AWT Text Component related
 tests
In-Reply-To: <7GvB3Su_njyW24WYBbYZXlx9jtO98uTxNrRkLTX4DEQ=.518bbfca-17bd-4bef-bbc1-e01f6026c951@github.com>
References: <7GvB3Su_njyW24WYBbYZXlx9jtO98uTxNrRkLTX4DEQ=.518bbfca-17bd-4bef-bbc1-e01f6026c951@github.com>
Message-ID: <caNLeciMlzWMVW_kt1Mpkvtklzn-851IqAoQZNWmNvA=.c74262cc-d68a-4b69-a590-32b9e37438e9@github.com>

On Thu, 27 Apr 2023 16:50:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT Text Component related tests.

This pull request has now been integrated.

Changeset: 485a0691
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/485a0691f4a762e9673967b7873356fb65afc5bc
Stats:     394 lines in 5 files changed: 394 ins; 0 del; 0 mod

8306432: Open source several AWT Text Component related tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13695


From tr at openjdk.org  Fri Apr 28 14:53:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 28 Apr 2023 14:53:54 GMT
Subject: Integrated: 8306640: Open source several AWT TextArea related tests
In-Reply-To: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
References: <RqxBtuofpA5YL8DT_hEj4Tu4O5yjH5e2Jw99jEA2r1c=.fb898367-b8b2-449a-8d23-b5b226ffb38e@github.com>
Message-ID: <wDIdnJwbz3fUEpliom_C_7WZnY91tDiPneEXs-RSTgs=.cc546c4d-0a43-4bc5-acc3-e06d9cbf69c4@github.com>

On Wed, 26 Apr 2023 14:23:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> Open source few AWT TextArea related tests.

This pull request has now been integrated.

Changeset: 169a7c27
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/169a7c27a7c6521fbfb1e61fbe85e6d7b0470619
Stats:     437 lines in 4 files changed: 437 ins; 0 del; 0 mod

8306640: Open source several AWT TextArea related tests

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13670


From dnguyen at openjdk.org  Fri Apr 28 14:56:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 14:56:25 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v3]
In-Reply-To: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
Message-ID: <c_qkIiehPOxeRfKvLUmv6oEUgpkCnFD8cns-2tEkf34=.249e12d3-1d3f-4a4f-b887-57e71fee0ba3@github.com>

> This PR open sources a few more AWT DnD related tests

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13653/files
  - new: https://git.openjdk.org/jdk/pull/13653/files/5435c254..0e388731

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13653&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13653&range=01-02

  Stats: 35 lines in 6 files changed: 11 ins; 1 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13653/head:pull/13653

PR: https://git.openjdk.org/jdk/pull/13653


From dnguyen at openjdk.org  Fri Apr 28 14:56:53 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 14:56:53 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <2KY0-PsL5w8dkO-wqgbLmsgeUoIXNVcl5c74X1cyE6o=.fe04f009-81bc-45ed-951a-1cd11a50d0b2@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
 <zggaADImNXxfePbdzjP4MYr_WDKkJSHFwCX5JmJRWkc=.a5f9d859-3060-4fc4-8ffe-f3bea980de23@github.com>
 <grnv86W8h6axj20dwer6WIOpalOPiClaJFbOkJXgdnI=.3ac177a0-cc25-4bc5-a70b-701a60631f29@github.com>
 <2KY0-PsL5w8dkO-wqgbLmsgeUoIXNVcl5c74X1cyE6o=.fe04f009-81bc-45ed-951a-1cd11a50d0b2@github.com>
Message-ID: <nE9wJ7hkeImC4nFdK2kHggpiOrb9qDq2JEHIaKoH3rg=.b063ff80-99e1-4f7c-80bb-eaa263f6d2e0@github.com>

On Thu, 27 Apr 2023 07:19:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> meaning you are suggesting they need to be volatile ?
>
> or changed to be used on the same thread, in this case EDT. It seems different tests use different approaches.

I made this var volatile and put the frame blocks in the EDT. Should all be fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1180495245


From dnguyen at openjdk.org  Fri Apr 28 14:57:24 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 14:57:24 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v2]
In-Reply-To: <SoKoGsJ3pyNAGrSGLhPcmGyddWExV6HHuhE3HplpClA=.64d19946-e1f8-4f0f-8bbb-e4378fec2a4b@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <9Ng0Lf3Dx1A-xe4u7sLDBoBk8J3xO5st9Mbtqj_lz24=.f5c45f93-50a4-4752-b40d-a1df557f4cb4@github.com>
 <SoKoGsJ3pyNAGrSGLhPcmGyddWExV6HHuhE3HplpClA=.64d19946-e1f8-4f0f-8bbb-e4378fec2a4b@github.com>
Message-ID: <KPRigUcONq5KjbgJ9HqKKQDYFv9f-w4-Tux-eFAWvoY=.8bfb5952-7f1e-4c0f-a439-71bd3c5cedb7@github.com>

On Thu, 27 Apr 2023 10:44:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra folders
>
> test/jdk/java/awt/dnd/SkipDropCompleteTest/SkipDropCompleteTest.java line 56:
> 
>> 54:     public void init() {
>> 55:         sourceFrame = new SourceFrame();
>> 56:         targetFrame  = new TargetFrame();
> 
> Suggestion:
> 
>         targetFrame = new TargetFrame();

Fixed

> test/jdk/java/awt/dnd/SkipDropCompleteTest/SourceFrame.java line 82:
> 
>> 80:     public void dragDropEnd(DragSourceDropEvent dsde) { }
>> 81: 
>> 82:     public void dragGestureRecognized(DragGestureEvent dge)  {
> 
> Suggestion:
> 
>     public void dragGestureRecognized(DragGestureEvent dge) {

Fixed

> test/jdk/java/awt/dnd/SkipDropCompleteTest/TransferableObject.java line 52:
> 
>> 50:         super();
>> 51:         Vector v = new Vector();
>> 52:             if(data instanceof String) {
> 
> Strange indentation
> Suggestion:
> 
>         if (data instanceof String) {

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1180495371
PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1180495443
PR Review Comment: https://git.openjdk.org/jdk/pull/13653#discussion_r1180495554


From erikj at openjdk.org  Fri Apr 28 18:26:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 18:26:52 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

I pulled this PR and had a go at building it. For me it failed with errors like this:

/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
/home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'


I haven't dug any deeper to try to figure this out. Is this something you recognize?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527926323


From erikj at openjdk.org  Fri Apr 28 18:26:27 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 18:26:27 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
Message-ID: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>

On Fri, 28 Apr 2023 11:59:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink. I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1527925075


From prr at openjdk.org  Fri Apr 28 18:29:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 18:29:53 GMT
Subject: Integrated: 8307079: Update test java/awt/Choice/DragOffNoSelect.java
In-Reply-To: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
References: <CtM8DPbUwC-29nskojzGVCJn4CY0EgzNHhj_3zSaWMk=.2113bb84-14e6-4af4-86cc-ce2052e5af02@github.com>
Message-ID: <nk79uJytyQi5emtSH-W5uHSZLXUlBzxKECAyO7icmdA=.b6b331a2-ec54-4051-aca8-8ebc668539e2@github.com>

On Thu, 27 Apr 2023 22:46:41 GMT, Phil Race <prr at openjdk.org> wrote:

> Small update to a test

This pull request has now been integrated.

Changeset: 89711f37
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89711f376751d4cfa05758705867afedfafeb602
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8307079: Update test java/awt/Choice/DragOffNoSelect.java

Reviewed-by: azvegint, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13705


From prr at openjdk.org  Fri Apr 28 18:37:29 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 18:37:29 GMT
Subject: RFR: 8306954: Open source five Focus related tests
In-Reply-To: <WU9Saz8NCgA24hCjPOyy-8N_Tr3RwT_HCz950EsfKEU=.cfe407fc-49d8-4fb4-856e-fffe32f5bf86@github.com>
References: <WU9Saz8NCgA24hCjPOyy-8N_Tr3RwT_HCz950EsfKEU=.cfe407fc-49d8-4fb4-856e-fffe32f5bf86@github.com>
Message-ID: <M6qDdQDHFqI0_H4XCmaU8DvEv3YysIoTKbm6RSbbGO4=.c0b3a59f-6ce5-457b-92cb-35c62822bedb@github.com>

On Thu, 27 Apr 2023 23:39:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up tests:
> 
> AsyncUpFocusCycleTest.java
> ClearMostRecentFocusOwnerTest.java
> ConsumedTabKeyTest.java,
> EventRetargetTest.java
> ExtraPropChangeNotifVetoingTest.java

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13707#pullrequestreview-1406410712


From prr at openjdk.org  Fri Apr 28 18:38:23 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 18:38:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

make/autoconf/lib-freetype.m4 line 118:

> 116:       if test "x${STATIC_JAVA}" = "xtrue"; then
> 117:         AC_MSG_ERROR([--with-freetype=system does not work with --with-static-java=yes])
> 118:       fi

Why not ? Surely you aren't statically linking every library you find on the platform that's referenced by JDK  ?
I mean its fine to say that I'd prefer to statically link this library, but I don't understand the claim that this is the only thing that can work ?

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 229:

> 227:     LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \
> 228:       debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o
> 229: 

Umm. Does this mean you are linking both headless and xawt into the same image ?
You are on your own with that. Sounds like a mistake to me and I don't want to see any
proposed source code changes to fix up any issues you see later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180701495
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180704385


From prr at openjdk.org  Fri Apr 28 18:51:23 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 18:51:23 GMT
Subject: RFR: 8307078: Opensource and clean up five more AWT Focus related
 tests
In-Reply-To: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
References: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
Message-ID: <I9OFmJ-SfRd-ME_22P0rrEMcYp9cAcXidlBBOfvq5QQ=.43b8c153-1fda-4fac-a241-e8191f23d525@github.com>

On Fri, 28 Apr 2023 05:12:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and ready to opensource:
> java/awt/Focus/FocusForRemovedComponentTest
> java/awt/Focus/FocusTraversalPolicyIAE
> java/awt/Focus/InitialFocusTest
> java/awt/Focus/LabelScrollbar
> java/awt/Focus/ModalDialogInFocusEventTest

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13710#pullrequestreview-1406424323


From dnguyen at openjdk.org  Fri Apr 28 18:53:01 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 18:53:01 GMT
Subject: RFR: 8306871: Open source more AWT Drag & Drop tests
Message-ID: <KpzQtqe_f7MwMXAppBjN2t5BQk6FUq4yhSHj-W2JDzI=.55686680-b847-46fa-9119-6daa8ea9cf2f@github.com>

This PR open sources more AWT DnD & Event related tests

-------------

Commit messages:
 - Initial test add

Changes: https://git.openjdk.org/jdk/pull/13725/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13725&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306871
  Stats: 1916 lines in 6 files changed: 1916 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13725/head:pull/13725

PR: https://git.openjdk.org/jdk/pull/13725


From kizune at openjdk.org  Fri Apr 28 19:03:53 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 19:03:53 GMT
Subject: Integrated: 8307078: Opensource and clean up five more AWT Focus
 related tests
In-Reply-To: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
References: <mq-ggYNZ0Mavnt1EMmOQqqgUDUzV2HHmnMGTZctsuc4=.9b3587ae-82ed-4983-b20b-f12232ef1d08@github.com>
Message-ID: <Q2tjYIjAmuVjDWZVUuxT82K_1HKJp16Gww-s8W74fqU=.c871c270-f39c-4291-a3fd-5ab7bb67043a@github.com>

On Fri, 28 Apr 2023 05:12:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaned up and ready to opensource:
> java/awt/Focus/FocusForRemovedComponentTest
> java/awt/Focus/FocusTraversalPolicyIAE
> java/awt/Focus/InitialFocusTest
> java/awt/Focus/LabelScrollbar
> java/awt/Focus/ModalDialogInFocusEventTest

This pull request has now been integrated.

Changeset: 6d6f726b
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d6f726b74f7fcd3e7c37d50bd2476b3e921662b
Stats:     965 lines in 5 files changed: 965 ins; 0 del; 0 mod

8307078: Opensource and clean up five more AWT Focus related tests

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13710


From dnguyen at openjdk.org  Fri Apr 28 19:40:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 19:40:23 GMT
Subject: Integrated: 8306681: Open source more AWT DnD related tests
In-Reply-To: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
References: <42hmjs8tKmuNyq-mPkjeRISORD-cd2kn1UqK_ocVQ6I=.faa5b612-01df-4c0a-bdc5-1d964d66a109@github.com>
Message-ID: <o4ngfVHKuVdFOavQMNaCFu04X2CW2e_yfEPC7Gc7_MI=.d42de246-85cc-4d11-a20c-7cd7543f756b@github.com>

On Wed, 26 Apr 2023 18:00:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources more AWT DnD related tests

This pull request has now been integrated.

Changeset: 05af487a
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05af487a2d9b85b87d13ea23776d04e52c67bf49
Stats:     544 lines in 7 files changed: 544 ins; 0 del; 0 mod

8306681: Open source more AWT DnD related tests

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/13674


From dnguyen at openjdk.org  Fri Apr 28 19:41:26 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Apr 2023 19:41:26 GMT
Subject: Integrated: 8306133: Open source few AWT Drag & Drop related tests
In-Reply-To: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
References: <pRqVNKx8O0JKpEcDc323NzlTjfE0xCgPL1JKVk13s3o=.47fd80b0-fe2d-4b34-9762-546d5825a336@github.com>
Message-ID: <fs50oCQWK-9FcM-rvwRYACm4UGmshvCZdIt89AbOX4E=.d9a57527-ced1-476f-a1f7-78311dce0a09@github.com>

On Fri, 21 Apr 2023 21:07:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources few AWT DnD related tests

This pull request has now been integrated.

Changeset: ec5c7926
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec5c7926f3cea68bf0d0ceb460a8383f5e4ea278
Stats:     1061 lines in 5 files changed: 1061 ins; 0 del; 0 mod

8306133: Open source few AWT Drag & Drop related tests

Reviewed-by: prr, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/13591


From erikj at openjdk.org  Fri Apr 28 19:52:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 19:52:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

I agree with the other comments here saying that this looks like something that would need a JEP. Especially since this isn't the full feature, but just the first step, and is essentially putting in dead code. It also seems like a higher level discussion about the solution may be needed.

Independent of the above, I have done a brief review of the code as it is.

make/Main.gmk line 1067:

> 1065:   static-libs-image: $(STATIC_LIBS_TARGETS)
> 1066: 
> 1067:   static-java-image: jdk-image hotspot-server-static-libs static-libs-image

You shouldn't need to repeat this. The DEPS parameter to SetupTarget should have handled it.

make/StaticLink.gmk line 83:

> 81:         else
> 82: 	  $(error Not supported on non-linux platform currently)
> 83:         endif

I think it would be rather beneficial if this linking step could be performed by some variant of SetupNativeCompilation. We don't want to have to maintain logic for dealing with different platforms and linkers outside of the common files if it can be helped. SetupNativeCompilation would need to be tweaked to run without SRC and just a set of `.a` files. 

The error about platform support should be handled in configure. We shouldn't be able to get here unless the configuration is expected to be supported.

make/autoconf/static-java.m4 line 31:

> 29: AC_DEFUN_ONCE([STATIC_JAVA_SETUP],
> 30: [
> 31:   AC_ARG_WITH(static-java, [AS_HELP_STRING([--with-static-java],

If this is all the setup for static-java in configure, I don't think it warrants having its own file. I would put this in jdk-options.m4 for now.

make/modules/java.base/lib/CoreLibraries.gmk line 172:

> 170:   # errors due to duplicate symbols.
> 171:   LIBJLI_STATIC_EXCLUDE_OBJS := \
> 172:       inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o

This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid the duplication.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 228:

> 226:     # static libraries cause linking errors due to duplicate symbols.
> 227:     LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \
> 228:       debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o

Can this list be derived dynamically in some way? If they are all in the same directory, maybe we could base it on that instead of having to maintain an explicit list?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13709#pullrequestreview-1406410191
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180697547
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180755742
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180747567
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180750185
PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180751543


From jiangli at openjdk.org  Fri Apr 28 19:52:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 19:52:57 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <R5uvOG4uZQy7Licu6iZArbWYnfmjvqRu9QN8JjR-GF0=.62f82b60-e6f2-4af3-ad50-b8f1a861f0ab@github.com>
Message-ID: <tsnkSf4MXYmSpl1aK2WVgXsFMS_VtQvDUzYav4zc-vU=.fddd73ad-f56f-4375-bde3-74536af304dd@github.com>

On Fri, 28 Apr 2023 04:57:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @jianglizhou I thought this work was proposed to be done under the Project Leyden umbrella? The other static-build tweaks have been fine but this seems to be part of a bigger, yet unspecified, project that may need to be covered by a JEP.

Hi David, indeed the hermetic project was proposed under Project Leyden umbrella. The makefile changes are related to the static linking only, e.g.:

- make the existing static build support more complete for demonstrating static linking capability
- produce a needed libjvm.a 
- producing a testable statically linked launcher binary

That gives us a base for exposing/resolving needed runtime work for supporting static linking fully in JDK. Either covering the makefile work by a JEP or handling it as an incremental change without JEP sounds good. The later might fit the current purpose better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528007520


From serb at openjdk.org  Fri Apr 28 21:38:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 21:38:22 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env
In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
Message-ID: <AtakUYhXuWwWNYIh6dmjHSte3dCZc5d3xsFIXhPxdDY=.20b24c11-fe6a-4921-8de9-f7352d3444d4@github.com>

On Thu, 27 Apr 2023 19:25:55 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 685:

> 683:             Graphics2D g2d = (Graphics2D) g;
> 684:             AffineTransform  at = g2d.getTransform();
> 685:             int dpi = (int)(at.getScaleX() * 96);

I think this will not work if the image is not VolatileImage, the scale will be = 1 and as a result, the image could be twice smaller than expected on the HiDPI monitor since rescale operation in another place is deleted. Please double-check.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 90:

> 88: 
> 89:         if(dpiAwareWidgetToTheme.containsKey(dpi))
> 90:         {

It seems some changes use different types of formatting, please unify.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 280:

> 278:         readLock.lock();
> 279:         try {
> 280:             return getPoint(getTheme(widget, defaultDPI), part, state, property);

Why does everything else use defaultDPI, is it possible that some values depend on the DPI?

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 119:

> 117:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
> 118:         OpenThemeDataFuncForDpi = (PFNOPENTHEMEDATAFORDPI)GetProcAddress(
> 119:                                    hModThemes, "OpenThemeDataForDpi");

Do we plan to backport this change to the old versions of JDK? If yes will we plan to support old WIndows? If yes probably we should fallback to the "OpenThemeData" if "OpenThemeDataForDpi" is not available?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180834159
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180827790
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180831572
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180829485


From prr at openjdk.org  Fri Apr 28 21:39:25 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 21:39:25 GMT
Subject: RFR: 8306955: Open source several JComboBox jtreg tests
Message-ID: <1ZmI55RbDoXIU-L4xI5kPbj001iNWPD9mZdsa_pxYFc=.2cf3df18-7c71-44bf-80f0-5d79c78ace85@github.com>

Open source some JComboBox jtreg tests

-------------

Commit messages:
 - 8306955

Changes: https://git.openjdk.org/jdk/pull/13730/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306955
  Stats: 392 lines in 5 files changed: 392 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13730/head:pull/13730

PR: https://git.openjdk.org/jdk/pull/13730


From prr at openjdk.org  Fri Apr 28 21:48:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 21:48:53 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env
In-Reply-To: <AtakUYhXuWwWNYIh6dmjHSte3dCZc5d3xsFIXhPxdDY=.20b24c11-fe6a-4921-8de9-f7352d3444d4@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <AtakUYhXuWwWNYIh6dmjHSte3dCZc5d3xsFIXhPxdDY=.20b24c11-fe6a-4921-8de9-f7352d3444d4@github.com>
Message-ID: <jDKWvs3-SqBPy9sgOebDg5ZSPXnIw2qZ2fb3w274yk4=.ba7ad6e1-1a21-425c-9841-60b33ce00faf@github.com>

On Fri, 28 Apr 2023 21:23:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Problem:
>> 
>> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
>> 
>> - Scrawly ticks in checkboxes;
>> - Wrong circle relations in selected radio buttons.
>> 
>> Root-cause:
>> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
>> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
>> appear incorrectly rendered. 
>> Following is a list proposed changes to fix this issue.
>> 
>> 
>> Proposed Fix with Summary of changes:
>> 
>> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
>> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
>> window is.
>> 
>> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
>> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
>> 
>> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
>> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>>  
>> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
>> --> This helps make sure that for .25s scaling we get better rendering. 
>> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
>> 
>> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
>> 
>> 
>> Testing:
>> 
>> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
>> 
>> ___________________________________
>>  Monitor 1                |    Monitor 2
>> (Primary) 		         |
>> 				 |
>>         125%		 |    175%
>> 	150%		 |    175%
>> 	150%		 |    225%
>> 	175%		 |    175%
>> 	175%	         |    150%
>> 	175%	         |    225%
>> _____________________ |_____________	
>> 
>> Also tested on setup with scaling values of  up-to 350%.
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 119:
> 
>> 117:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
>> 118:         OpenThemeDataFuncForDpi = (PFNOPENTHEMEDATAFORDPI)GetProcAddress(
>> 119:                                    hModThemes, "OpenThemeDataForDpi");
> 
> Do we plan to backport this change to the old versions of JDK? If yes will we plan to support old WIndows? If yes probably we should fallback to the "OpenThemeData" if "OpenThemeDataForDpi" is not available?

I guess this could (should?) be backported but Windows 10 is the oldest supported OS no matter what the JDK version.
And only the more recent versions of Windows 10 at that ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180838420


From prr at openjdk.org  Fri Apr 28 21:51:24 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 21:51:24 GMT
Subject: RFR: 8307080: Open source some more JComboBox jtreg tests
Message-ID: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>

Open source another 5 JComboBox tests.

-------------

Commit messages:
 - 8307080
 - 8307080

Changes: https://git.openjdk.org/jdk/pull/13731/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307080
  Stats: 425 lines in 5 files changed: 425 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13731/head:pull/13731

PR: https://git.openjdk.org/jdk/pull/13731


From prr at openjdk.org  Fri Apr 28 22:09:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 22:09:53 GMT
Subject: RFR: 8306466: Open source more AWT Drag & Drop related tests [v3]
In-Reply-To: <c_qkIiehPOxeRfKvLUmv6oEUgpkCnFD8cns-2tEkf34=.249e12d3-1d3f-4a4f-b887-57e71fee0ba3@github.com>
References: <edzGvJ6IFMfeUxVCrmYKuJKG3bNufnqREcSY8wXpXzQ=.c922f648-0b3f-4469-b20b-865e1f4c81e3@github.com>
 <c_qkIiehPOxeRfKvLUmv6oEUgpkCnFD8cns-2tEkf34=.249e12d3-1d3f-4a4f-b887-57e71fee0ba3@github.com>
Message-ID: <7ASuPV2XgYQkNn9WPd1y5k3FzzTd46zXbyDbUx6ya2c=.3334256c-f23c-44df-849e-ff463c500819@github.com>

On Fri, 28 Apr 2023 14:56:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This PR open sources a few more AWT DnD related tests
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13653#pullrequestreview-1406642007


From prr at openjdk.org  Fri Apr 28 22:20:56 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 22:20:56 GMT
Subject: RFR: 8306871: Open source more AWT Drag & Drop tests
In-Reply-To: <KpzQtqe_f7MwMXAppBjN2t5BQk6FUq4yhSHj-W2JDzI=.55686680-b847-46fa-9119-6daa8ea9cf2f@github.com>
References: <KpzQtqe_f7MwMXAppBjN2t5BQk6FUq4yhSHj-W2JDzI=.55686680-b847-46fa-9119-6daa8ea9cf2f@github.com>
Message-ID: <lUc869VQQIi1INd7MrtMAQg9PmD_jjCzSDvMCOIpM0I=.bba8acb2-aed6-4689-b24f-c0bf1ef1c5d1@github.com>

On Fri, 28 Apr 2023 18:34:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This PR open sources more AWT DnD & Event related tests

Fix the comment before integration

test/jdk/java/awt/event/KeyEvent/AltGraphModifier.java line 28:

> 26:   @bug 4343344
> 27:   @summary Tests key modifiers when ALT_GRAPH key is pressed by Robot.
> 28:            This test is for UNIX only.

I think this comment is confusing and should be removed since
(1) the test is only being excluded on mac which is actually Unix
(2) it is being run on Windows which most definitely isn't Unix.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13725#pullrequestreview-1406647484
PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1180849298


From kizune at openjdk.org  Fri Apr 28 22:31:56 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 22:31:56 GMT
Subject: RFR: 8307080: Open source some more JComboBox jtreg tests
In-Reply-To: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
References: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
Message-ID: <j07III9fkmjFa0KPC44aclRvJsl0onkXimkC_G1usjA=.ab4cf6b3-97c4-4ebb-95d0-e73715746e92@github.com>

On Fri, 28 Apr 2023 21:25:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source another 5 JComboBox tests.

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13731#pullrequestreview-1406661733


From jiangli at openjdk.org  Fri Apr 28 22:43:26 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Apr 2023 22:43:26 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
Message-ID: <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>

On Fri, 28 Apr 2023 18:16:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I pulled this PR and had a go at building it. For me it failed with errors like this:
> 
> ```
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'
> ```
> 
> I haven't dug any deeper to try to figure this out. Is this something you recognize?

Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:


/usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o  -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a


`clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`.


$ ldd jdk/bin/javastatic
	linux-vdso.so.1 (0x00007fff8b17a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f084888d000)



$ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres
00000000000cf260 g    DF .text	0000000000000069  GLIBC_2.17  clock_getres
00000000000cf260 g    DF .text	0000000000000069 (GLIBC_2.2.5) clock_getres

$ nm jdk/bin/javastatic | grep clock_gettime
                 U clock_gettime at GLIBC_2.17
$ nm jdk/bin/javastatic | grep clock_getres
                 U clock_getres at GLIBC_2.17

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528158982


From kizune at openjdk.org  Fri Apr 28 22:43:26 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 28 Apr 2023 22:43:26 GMT
Subject: RFR: 8306955: Open source several JComboBox jtreg tests
In-Reply-To: <1ZmI55RbDoXIU-L4xI5kPbj001iNWPD9mZdsa_pxYFc=.2cf3df18-7c71-44bf-80f0-5d79c78ace85@github.com>
References: <1ZmI55RbDoXIU-L4xI5kPbj001iNWPD9mZdsa_pxYFc=.2cf3df18-7c71-44bf-80f0-5d79c78ace85@github.com>
Message-ID: <7WeI09HmKFS5p0RDtv7Lp4HuNsWQHqkJVnYHvy2q7EA=.93dc2e65-42bc-4ef8-8fa5-fdad6d7592f1@github.com>

On Fri, 28 Apr 2023 21:23:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source some JComboBox jtreg tests

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13730#pullrequestreview-1406663393


From prr at openjdk.org  Fri Apr 28 22:57:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 22:57:53 GMT
Subject: Integrated: 8306955: Open source several JComboBox jtreg tests
In-Reply-To: <1ZmI55RbDoXIU-L4xI5kPbj001iNWPD9mZdsa_pxYFc=.2cf3df18-7c71-44bf-80f0-5d79c78ace85@github.com>
References: <1ZmI55RbDoXIU-L4xI5kPbj001iNWPD9mZdsa_pxYFc=.2cf3df18-7c71-44bf-80f0-5d79c78ace85@github.com>
Message-ID: <t2OQ42jr9c4kgjOFQGy9sJhH_WRwi0x9SMhKqXPyorA=.9c62915a-e756-402c-8efd-e13d07f5d33f@github.com>

On Fri, 28 Apr 2023 21:23:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source some JComboBox jtreg tests

This pull request has now been integrated.

Changeset: 1f689241
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f689241cfcb4083cba283a2010b532948865283
Stats:     392 lines in 5 files changed: 392 ins; 0 del; 0 mod

8306955: Open source several JComboBox jtreg tests

Reviewed-by: kizune

-------------

PR: https://git.openjdk.org/jdk/pull/13730


From prr at openjdk.org  Fri Apr 28 22:57:27 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Apr 2023 22:57:27 GMT
Subject: Integrated: 8307080: Open source some more JComboBox jtreg tests
In-Reply-To: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
References: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
Message-ID: <O2JnKtkp37SLfeCwfKibTSFIZrL-xgmt_g8YFJmh9_g=.1921f90e-b465-4383-89fe-8972177b5d41@github.com>

On Fri, 28 Apr 2023 21:25:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source another 5 JComboBox tests.

This pull request has now been integrated.

Changeset: b8de3943
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8de39431dca90e63552968829a349a9b63e68ca
Stats:     425 lines in 5 files changed: 425 ins; 0 del; 0 mod

8307080: Open source some more JComboBox jtreg tests

Reviewed-by: kizune

-------------

PR: https://git.openjdk.org/jdk/pull/13731


From erikj at openjdk.org  Fri Apr 28 23:40:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Apr 2023 23:40:52 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
Message-ID: <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>

On Fri, 28 Apr 2023 22:32:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:

I can't see any significant difference. I'm using a devkit created using the devkit makefiles. 


.../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528188361


From serb at openjdk.org  Sat Apr 29 00:13:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Apr 2023 00:13:53 GMT
Subject: RFR: 8307135:
 java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed
Message-ID: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>

The test uses the `DragSource.getDefaultDragSource()` which throws HeadlessException. The test should be marked as headful.

-------------

Commit messages:
 - 8307135: java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed

Changes: https://git.openjdk.org/jdk/pull/13733/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307135
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13733/head:pull/13733

PR: https://git.openjdk.org/jdk/pull/13733


From jiangli at openjdk.org  Sat Apr 29 00:11:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:11:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
Message-ID: <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>

On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> 
> If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink.

For the testing/demo purpose (on static linking part) with this PR, the makefile changes in the PR only run the native linker step to perform static linking. The 'javastatic' is simply copied into the (regular) jlink'ed JDK image 'bin/' directory.  In our experiments/prototyping work, the 'javastatic' launcher binary is used along with the other artifacts from the regular JDK image (e.g. lib/modules)  for basic sanitary testing (running some of the jtreg tier 1 tests). The 'javastatic' is not used for creating the hermetic Java image. The post process building the hermetic image takes the .a files, lib/modules and other resources files as input.

>  I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

Agreed. 

Based the initial feedback from you and other reviewers in the thread, I'll repurpose this PR for handling the .a part only. I'll split the 'javastatic' static linking part into a separate branch for needed discussions (including the potential JEP part). That branch can be on the sideline and it can be to verify/test the other static linking related changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528259605


From jiefu at openjdk.org  Sat Apr 29 00:13:54 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 29 Apr 2023 00:13:54 GMT
Subject: RFR: 8307135:
 java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed
In-Reply-To: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
References: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
Message-ID: <mx_UCCJ5wbu2tgj0rgVeTeTAs1NjGqDXhGzMlR_uGNY=.af6e81f8-0e4c-4e90-9a9d-4a237da85d1a@github.com>

On Fri, 28 Apr 2023 23:59:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test uses the `DragSource.getDefaultDragSource()` which throws HeadlessException. The test should be marked as headful.

LGTM

-------------

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13733#pullrequestreview-1406730771


From prr at openjdk.org  Sat Apr 29 00:21:28 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Apr 2023 00:21:28 GMT
Subject: RFR: 8307135:
 java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed
In-Reply-To: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
References: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
Message-ID: <RaXrf4W6DUor-Ek0bspRLI6S0DejfCCeDAQY7UOUpkw=.035a2e23-2dbc-40b0-beaf-138df8bbc512@github.com>

On Fri, 28 Apr 2023 23:59:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test uses the `DragSource.getDefaultDragSource()` which throws HeadlessException. The test should be marked as headful.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13733#pullrequestreview-1406734071


From jiangli at openjdk.org  Sat Apr 29 00:33:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:33:54 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <rKa31Zl0W-a6fsxlwlH7bDuzAxNkQ1J7NMVY2y9jVmU=.7fc5de16-b500-47ed-93d0-6553181538be@github.com>
Message-ID: <LZQ9wEi-kFNfiRkJv-mY2NWm5x0rMJc54Z-o-mmb1MA=.198067e3-d9a3-449b-a748-70e49fa0962c@github.com>

On Sat, 29 Apr 2023 00:03:24 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Based the initial feedback from you and other reviewers in the thread, I'll repurpose this PR for handling the .a part only. I'll split the 'javastatic' static linking part into a separate branch for needed discussions (including the potential JEP part). That branch can be on the sideline and it can be to verify/test the other static linking related changes.

On the second thought, it might be cleaner to withdraw the current PR first and extract the .a part into a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528275134


From jiangli at openjdk.org  Sat Apr 29 00:35:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:35:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
Message-ID: <QROzLHb4osGh3Fi8wM74Yb1QfFIN-kV9KxYNHKXWI6c=.b39c7440-fd05-4a9b-966b-a6884533b969@github.com>

On Fri, 28 Apr 2023 19:40:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think it would be rather beneficial if this linking step could be performed by some variant of SetupNativeCompilation. We don't want to have to maintain logic for dealing with different platforms and linkers outside of the common files if it can be helped. SetupNativeCompilation would need to be tweaked to run without SRC and just a set of .a files.
>
> The error about platform support should be handled in configure. We shouldn't be able to get here unless the configuration is expected to be supported.

All sounds good, thanks. I plan to withdraw this PR and extract the .a handling part into a new PR for now (as mentioned in response to @AlanBateman's comments). For the linking part, it would be good to have your close/direct involvement and collaboration in branch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180891458


From jiangli at openjdk.org  Sat Apr 29 00:57:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 00:57:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
Message-ID: <CWhHDSitCkW1LIYi4ymEeje3IlScDJy_ym5gN7cgF8M=.f89c75d3-a80d-4317-9fa3-8768f64d00aa@github.com>

On Fri, 28 Apr 2023 18:25:14 GMT, Phil Race <prr at openjdk.org> wrote:

> Why not ? Surely you aren't statically linking every library you find on the platform that's referenced by JDK ?
> I mean its fine to say that I'd prefer to statically link this library, but I don't understand the claim that this is the only thing that can work ?

It's for providing libzip.a and libfreetype.a as part of the JDK 'static-libs' image. In our usages, I've learned that static linking is preferred whenever possible. We don't statically link libc.

Mine main reasoning/motivation for building and including the libzip.a and libfreetype.a in JDK 'static-libs' image is for ease of use. It reduces complications during the post hermetic image build process, if those libraries are need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180895872


From jiangli at openjdk.org  Sat Apr 29 01:29:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 01:29:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_e_12IxPPJcn-OlnVrDUHekCrPhY7LhMJDtdmIViSjw=.b7b9f5f1-716f-46ab-96d5-ce240ee36c59@github.com>
Message-ID: <10RC9v_ITMbLATGX8LJhg3WRQwZ-JNkxRCEuryBR1zM=.594db8fe-7264-4f84-b50f-3b09e4c3b6af@github.com>

On Fri, 28 Apr 2023 18:28:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Umm. Does this mean you are linking both headless and xawt into the same image ?

For the xawt case, we statically link with libawt.a and libawt_xawt.a in our early prototype. For headless case, we statically link with libawt.a and libawt_headless.a. We have been focusing on testing with the headless usages.

The libawt provides `AWT_OnLoad`, which handles the 'loading' of libawt_xawt or libawt_headless. By filtering out the duplicate .o files in the static linking case, it can work without larger refactoring the sources in the those libraries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1180900245


From serb at openjdk.org  Sat Apr 29 01:41:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Apr 2023 01:41:54 GMT
Subject: Integrated: 8307135:
 java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed
In-Reply-To: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
References: <MOQwB-Is7YZldbmTajMTNI6Wbv6wJmX0XJLaTkDBtHA=.2a2f3ef1-76f0-4ff8-9fbb-4e1d3f1d1f10@github.com>
Message-ID: <KO130kKYJyPFU_uYW94f9EgfczruBx90faWN8nwKNsQ=.91271566-89b6-4409-8c4d-f311af9a4cff@github.com>

On Fri, 28 Apr 2023 23:59:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test uses the `DragSource.getDefaultDragSource()` which throws HeadlessException. The test should be marked as headful.

This pull request has now been integrated.

Changeset: d43a5a28
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d43a5a289f4ac84480bf54ab304c1ce1dbc8e067
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8307135: java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed

Reviewed-by: jiefu, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13733


From jiangli at openjdk.org  Sat Apr 29 02:01:24 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 02:01:24 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
Message-ID: <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>

On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
> 
> I can't see any significant difference. I'm using a devkit created using the devkit makefiles.
> 
> ```
> .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
> ```

I did some search and found https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime/32649327#32649327. The clock_* functions moved from librt to libc (starting from glibc 2.17). That finding led me to the following in libraries.m4:


  # librt for legacy clock_gettime
  if test "x$OPENJDK_TARGET_OS" = xlinux; then
    # Hotspot needs to link librt to get the clock_* functions.
    # But once our supported minimum build and runtime platform
    # has glibc 2.17, this can be removed as the functions are
    # in libc.
    BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
  fi


Since I use `ldd (Debian GLIBC 2.36-8+gl1) 2.36`, I didn't notice that until now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528445381


From serb at openjdk.org  Sat Apr 29 02:58:27 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Apr 2023 02:58:27 GMT
Subject: RFR: 8307080: Open source some more JComboBox jtreg tests
In-Reply-To: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
References: <vYx2XKbFQy61Q3_Xggqa1vXXTLXp5vvZeL33DlyeluU=.9e5a6a9d-6c11-4cdb-93cd-20218d9ddf93@github.com>
Message-ID: <DO6NMWPQPHcGj2xELsoB-_jZ95AYC4FIJjo9tJVGuJQ=.fe8e4804-0f58-4755-a7c2-eb7ac3587c97@github.com>

On Fri, 28 Apr 2023 21:25:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Open source another 5 JComboBox tests.

test/jdk/javax/swing/JComboBox/bug5029504.java line 98:

> 96:         robot.delay(2000);
> 97:         Point p = comboBox.getLocationOnScreen();
> 98:         Dimension size = comboBox.getSize();

Note that JComboBox is accessed on non-EDT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13731#discussion_r1180940546


From jiangli at openjdk.org  Sat Apr 29 03:57:53 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 03:57:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
 [v2]
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <VwR0TLPzfG4luNZFUlvEzvlmMxgUEhp2rHnqvv2ad0A=.a617fcd6-4cc9-4c7c-9f2d-389ea05a62b3@github.com>

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
> 
> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
> 
> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
> 
> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Use $(JVM_LIBS), which includes -lrt on Linux currently.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13709/files
  - new: https://git.openjdk.org/jdk/pull/13709/files/85523095..4728b380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13709&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13709.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13709/head:pull/13709

PR: https://git.openjdk.org/jdk/pull/13709


From jiangli at openjdk.org  Sat Apr 29 04:03:58 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 29 Apr 2023 04:03:58 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
 <cHoSfMjHAHP6ju9S-RDkATMulY5tDBBvyWNM8T6LTfg=.8f01ce5a-97d3-4d41-adcb-0cf342786fe0@github.com>
Message-ID: <I-RZnBJsuozJqepXHanQGaGCD5pVcSxq82INwW9-jYo=.02742fc4-fd96-4d00-b766-b9c0f5dff6ec@github.com>

On Sat, 29 Apr 2023 01:44:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
> > 
> > 
> > I can't see any significant difference. I'm using a devkit created using the devkit makefiles.
> > ```
> > .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
> > ```
> 
> I did some search and found https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime/32649327#32649327. The clock_* functions moved from librt to libc (starting from glibc 2.17). That finding led me to the following in libraries.m4:
> 
> ```
>   # librt for legacy clock_gettime
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     # Hotspot needs to link librt to get the clock_* functions.
>     # But once our supported minimum build and runtime platform
>     # has glibc 2.17, this can be removed as the functions are
>     # in libc.
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
>   fi
> ```
> 
> Since I use `ldd (Debian GLIBC 2.36-8+gl1) 2.36`, I didn't notice that until now.

Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528637453


From kizune at openjdk.org  Sat Apr 29 08:47:23 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 29 Apr 2023 08:47:23 GMT
Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility
In-Reply-To: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
References: <V8w7880YtRFr5GOgXomwziQNDr28GJwk2g1QLUw1xLY=.04fb5646-893c-475e-ab6e-74f0e47eedbe@github.com>
Message-ID: <Kh4Ybh0h2Q68CgNGuBvX2PfBLxMGoofKbo07ciyCsuY=.3d0482a5-cdac-4e8c-918a-5d99bc6eb1ea@github.com>

On Wed, 8 Mar 2023 18:20:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the jdk.accessibility module.
> 
> Thanks,
> Xuelei

The problem with testing of this code is that a lot of it (if not all) is inside the debug and logging part, which means that not only library should be loaded (doable) and the debug is on (also doable) but some of that code is just an error report and in order to cause system to misbehave enough to cause such error is not trivial. Looking into it though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12929#issuecomment-1528717321


From kizune at openjdk.org  Sat Apr 29 18:30:55 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 29 Apr 2023 18:30:55 GMT
Subject: Integrated: 8306954: Open source five Focus related tests
In-Reply-To: <WU9Saz8NCgA24hCjPOyy-8N_Tr3RwT_HCz950EsfKEU=.cfe407fc-49d8-4fb4-856e-fffe32f5bf86@github.com>
References: <WU9Saz8NCgA24hCjPOyy-8N_Tr3RwT_HCz950EsfKEU=.cfe407fc-49d8-4fb4-856e-fffe32f5bf86@github.com>
Message-ID: <zVXNnjGLHr1aIpDDJXoIRkRcGt7_kwwVdkfYJiZv400=.50346ff7-d686-4b20-b7d4-f9e7df1ea13b@github.com>

On Thu, 27 Apr 2023 23:39:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Cleaning up tests:
> 
> AsyncUpFocusCycleTest.java
> ClearMostRecentFocusOwnerTest.java
> ConsumedTabKeyTest.java,
> EventRetargetTest.java
> ExtraPropChangeNotifVetoingTest.java

This pull request has now been integrated.

Changeset: 6d6d00b6
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d6d00b69cea47ccbe05a844db0fb6c384045caa
Stats:     962 lines in 5 files changed: 962 ins; 0 del; 0 mod

8306954: Open source five Focus related tests

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/13707


From jwaters at openjdk.org  Sat Apr 29 19:46:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Apr 2023 19:46:58 GMT
Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in
 its C API
Message-ID: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com>

In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge:

addJavaEventNotification
removeJavaEventNotification
addAccessibilityEventNotification
removeAccessibilityEventNotification


However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future

-------------

Commit messages:
 - Declare missing API in header as well
 - windowsaccessbridge.dll is missing 4 critical methods in its C API

Changes: https://git.openjdk.org/jdk/pull/13734/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307145
  Stats: 29 lines in 2 files changed: 29 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13734/head:pull/13734

PR: https://git.openjdk.org/jdk/pull/13734


From alanb at openjdk.org  Sun Apr 30 18:47:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Apr 2023 18:47:53 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
Message-ID: <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>

On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage.

Also builds on recent changes to remove duplicate symbol names. It's good that the PR demonstrates that these can be linked to create "javastatic" but having it copy into the run-time image created by jlink is probably not the eventual outcome.

A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529110628


From jvernee at openjdk.org  Sun Apr 30 19:09:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sun, 30 Apr 2023 19:09:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
Message-ID: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com>

On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules.

It seems that letting jlink do the linking is also a requirement for user provided modules (.jmods) that contain native libraries (as is the case for instance with jextract). We don't know about those libraries when building the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529114550


From rmahajan at openjdk.org  Sun Apr 30 21:34:53 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Sun, 30 Apr 2023 21:34:53 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v11]
In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
Message-ID: <Gj8gx-e5oG3rbaQdo4Cjm4PAjeJV-fQfqKLtW6XKhBs=.77c9780a-5607-42dc-81ba-549c510e7dbe@github.com>

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision:

 - Update ImageRepresentation.java
   
   code cleanup
 - Update ImageRepresentation.java
   
   code cleanup
 -  update fix to work for both cases where image is displayed and not displayed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13414/files
  - new: https://git.openjdk.org/jdk/pull/13414/files/79874ada..74c5c675

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=09-10

  Stats: 36 lines in 2 files changed: 25 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414

PR: https://git.openjdk.org/jdk/pull/13414


From rmahajan at openjdk.org  Sun Apr 30 21:36:22 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Sun, 30 Apr 2023 21:36:22 GMT
Subject: RFR: 6176679: Application freezes when copying an animated gif
 image to the system clipboard [v10]
In-Reply-To: <WGduTXodBNvaUdJJI1Ba-y9nK_oaa6E9SYqr9PtcnUo=.6841c81b-347e-4702-bb44-5a0fe46d62d3@github.com>
References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com>
 <WGduTXodBNvaUdJJI1Ba-y9nK_oaa6E9SYqr9PtcnUo=.6841c81b-347e-4702-bb44-5a0fe46d62d3@github.com>
Message-ID: <DMz-FmTLIH7bVpGQd6R4GrYhjSGr2_cvYkxuuQs2hec=.791bb738-8e4f-433d-9542-b684dee24e6e@github.com>

On Thu, 20 Apr 2023 19:26:52 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Problem:**
>> 
>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
>> Due to this infinite wait the application freezes.
>> 
>> **Proposed Fix:**
>> 
>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. 
>> After this change I see the GIF image being correctly copied and animated.
>> 
>> 
>> **Testing:**
>> 
>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CopyAnimatedGIFTest.java

> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.org):_
> 
> I was hoping to be able to run your test program, but I cannot because on macOS there is no support for transferring a native image.
> 
> It also appears that I cannot simulate the transfer code because that code depends upon the reconstruct method, which is not public.
> 
> Just looking at the code, I think it is not correct.
> 
> It looks to me that the ImageRepresentation.drawToBufImage method is called only once, and it will do nothing unless ALLBITS or FRAMEBITS is true. I do not see any loop that would call it multiple times. (If I am correct about this, then only the first frame is drawn into the buffered image, which makes much more sense than drawing every frame into the buffered image. One might ask, however, what a user is trying to accomplish by copying an animated image to the system clipboard?)
> 
> So, it works if reconstruct() waits until ALLBITS or FRAMEBITS is true. But your change does not test for FRAMEBITS in the loop, so it will only work if FRAMEBITS is already true when reconstruct() is called.
> 
> How can that happen?
> 
> I think it works because you are displaying the image on the screen, and the animation code is reading frames.
> 
> I suggest trying the test without displaying the image.

Thanks for your suggestions. I have modified the code so it works for both cases where image is and is not displayed on screen.
I have modified the test so it tests for both these cases.

> Also, your test would better if it retrieved the native image from the system clipboard to verify that it was successfully transferred. You would need to clear the system clipboard before running the test to be sure you are not retrieving something from a previous test run.

I am not sure what you mean by native image. Could you please clarify ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1529141085